使用PHP的memcache模块写了一个访问tokyotrant的long-live程序,因为是long-live的,所以我就connect一次之后一直使用了,理论上我connect之后就可以一直使用,中间不会出现重新连接的问题,为了确认我的推断,启动进程之后,我用strace跟踪了一些进程,令我意外的是,隔一段时间连接就会关闭,然后重新连接,怎么回事呢?
我怀疑两个方面:
1. 我的程序有问题
2. server端有问题,用一段时间会关掉我的连接
首先,我用了大约1个小时的时间,简直把我的程序拆的支离破碎了,结果没有发现哪里有问题。
其次,我使用tcpdump观察了一下,发现主动关闭连接的不是server端,而是我的程序。
百思不得其解。这件事简直成了我的一块心病。
隔了一段时间,当我再次使用tcpdump观察的时候,结果如下:
1. 21:27:20.273522 IP 10.55.38.62.60953 > 10.55.38.70.2004: . ack 132 win 501 <nop,nop,timestamp 3026990738 3683027032>
2. 21:27:20.273757 IP 10.55.38.62.60953 > 10.55.38.70.2004: P 20:142(122) ack 132 win 501 <nop,nop,timestamp 3026990738 3683027032>
3. 21:27:20.273871 IP 10.55.38.70.2004 > 10.55.38.62.60953: . ack 142 win 255 <nop,nop,timestamp 3683027032 3026990738>
4. 21:27:21.273955 IP 10.55.38.62.60953 > 10.55.38.70.2004: F 142:142(0) ack 132 win 501 <nop,nop,timestamp 3026991738 3683027032>
5. 21:27:21.274038 IP 10.55.38.62.37298 > 10.55.38.70.2004: S 3948732568:3948732568(0) win 5792 <mss 1460,sackOK,timestamp 3026991738 3683027542,nop,wscale 7>
6. 21:27:21.274165 IP 10.55.38.70.2004 > 10.55.38.62.37298: S 34634952:34634952(0) ack 3948732569 win 5792 <mss 1460,sackOK,timestamp 3683028032 3026991738,nop,wscale 7>
21:27:21.274185 IP 10.55.38.62.37298 > 10.55.38.70.2004: . ack 1 win 46 <nop,nop,timestamp 3026991738 3683028032>
21:27:21.274196 IP 10.55.38.62.37298 > 10.55.38.70.2004: P 1:123(122) ack 1 win 46 <nop,nop,timestamp 3026991738 3683028032>
21:27:21.274320 IP 10.55.38.70.2004 > 10.55.38.62.37298: . ack 123 win 46 <nop,nop,timestamp 3683028032 3026991738>
21:27:21.313329 IP 10.55.38.70.2004 > 10.55.38.62.60953: . ack 143 win 255 <nop,nop,timestamp 3683028072 3026991738>
21:27:21.533806 IP 10.55.38.70.2004 > 10.55.38.62.37298: P 1:9(8) ack 123 win 46 <nop,nop,timestamp 3683028292 3026991738>
21:27:21.533822 IP 10.55.38.62.37298 > 10.55.38.70.2004: . ack 9 win 46 <nop,nop,timestamp 3026991998 3683028292>
21:27:22.604843 IP 10.55.38.70.2004 > 10.55.38.62.60953: P 132:140(8) ack 143 win 255 <nop,nop,timestamp 3683029363 3026991738>
21:27:22.604859 IP 10.55.38.62.60953 > 10.55.38.70.2004: R 3898017016:3898017016(0) win 0
21:27:24.072995 IP 10.55.38.62.37298 > 10.55.38.70.2004: P 123:143(20) ack 9 win 46 <nop,nop,timestamp 3026994537 3683028292>
============================================
我意外地发现有一个reset包,感觉很奇怪,顺着 60953 端口网上查,发现:
第2个包: 向server端发送数据
第3个包: server端回复收到数据
第4个包: 按说应该server端返回响应数据,但是这里却是client端发了一个finish包
观察第3个包与第4个包之间的时间间隔,基本是1s, 这令我想起了memcache的默认超时时间也是1s,是巧合?显然不是。因为:
第5个包: client端重新发起了连接操作
显然是超时了, 于是重连有了答案。
当然,虽然client关闭了连接,server端却还没有关闭,直到 21:27:22.604859 的时候,服务器端给出了响应数据,但是client已经关闭了,所以出现了被reset的现象。
==========================================
还有一个问题:
我的程序里面是做了容错处理的,但是我的容错策略是,如果出错了,则sleep(2);之后重新连接; 显然不符合上面的表现,怀着万般不解的心情开始看php的memcache模块的源码;
在memcache.c中:
-
int mmc_pool_store(mmc_pool_t *pool, const char *command, int command_len, const char *key, int key_len, int flags, int
-
expire, const char *value, int value_len TSRMLS_DC) /* {{{ */
-
{
-
mmc_t *mmc;
-
char *request;
-
int request_len, result = –1;
-
char *key_copy = NULL, *data = NULL;
-
//…
-
while (result < 0 && (mmc = mmc_pool_find(pool, key, key_len TSRMLS_CC)) != NULL) {
-
if ((result = mmc_server_store(mmc, request, request_len TSRMLS_CC)) < 0) {
-
mmc_server_failure(mmc TSRMLS_CC);
-
}
-
}
-
// …
-
}
-
-
// ..
-
int mmc_server_failure(mmc_t *mmc TSRMLS_DC) /*
-
determines if a request should be retried or is a hard network failure {{{ */
-
{
-
switch (mmc->status) {
-
case MMC_STATUS_DISCONNECTED:
-
return 0;
-
-
/* attempt reconnect of sockets in unknown state */
-
case MMC_STATUS_UNKNOWN:
-
mmc->status = MMC_STATUS_DISCONNECTED;
-
return 0;
-
}
-
-
mmc_server_deactivate(mmc TSRMLS_CC);
-
return 1;
-
}
在这里,我们发现,如果store失败的话,下面会有一个容错处理,通过php -i | grep memcache 可以看到容错配置确实是打开的。
在容错的代码中明显发现做了断开连接的操作,但是在哪里重连的呢?
这要看mmc_hash_find_server的实现了,有时间再看。。。