关于Memcache长连接自动重连的问题

4月 122011

使用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中：

Memcach.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的实现了，有时间再看。。。

原文链接：https://phpor.net/blog/post/821

PHPor 的Blog

关于Memcache长连接自动重连的问题

Leave a Reply Cancel reply