php 队列要memche,关于Memcache长连接自动重连的问题

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

2.  21:27:20.273757 IP 10.55.38.62.60953> 10.55.38.70.2004: P 20:142(122) ack 132 win 501

3.  21:27:20.273871 IP 10.55.38.70.2004 > 10.55.38.62.60953: . ack 142 win 255

4. 21:27:21.273955 IP 10.55.38.62.60953> 10.55.38.70.2004: F 142:142(0) ack 132 win 501

5. 21:27:21.274038 IP 10.55.38.62.37298 > 10.55.38.70.2004: S 3948732568:3948732568(0) win 5792

6. 21:27:21.274165 IP 10.55.38.70.2004 > 10.55.38.62.37298: S 34634952:34634952(0) ack 3948732569 win 5792

21:27:21.274185 IP 10.55.38.62.37298 > 10.55.38.70.2004: . ack 1 win 46

21:27:21.274196 IP 10.55.38.62.37298 > 10.55.38.70.2004: P 1:123(122) ack 1 win 46

21:27:21.274320 IP 10.55.38.70.2004 > 10.55.38.62.37298: . ack 123 win 46

21:27:21.313329 IP 10.55.38.70.2004 > 10.55.38.62.60953: . ack 143 win 255

21:27:21.533806 IP 10.55.38.70.2004 > 10.55.38.62.37298: P 1:9(8) ack 123 win 46

21:27:21.533822 IP 10.55.38.62.37298 > 10.55.38.70.2004: . ack 9 win 46

21:27:22.604843 IP 10.55.38.70.2004 > 10.55.38.62.60953: P 132:140(8) ack 143 win 255

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

============================================

我意外地发现有一个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的实现了，有时间再看。。。