关于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 <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
  1.     
    int mmc_pool_store(mmc_pool_t *pool, const char *command, int command_len, const char *key, int key_len, int flags, int

        

  2.     
     expire, const char *value, int value_len TSRMLS_DC) /* {{{ */

        

  3.     
    {

        

  4.     
        mmc_t *mmc;

        

  5.     
        char *request;

        

  6.     
        int request_len, result = 1;

        

  7.     
        char *key_copy = NULL, *data = NULL;

        

  8.     
    //…

        

  9.     
        while (result < 0 && (mmc = mmc_pool_find(pool, key, key_len TSRMLS_CC)) != NULL) {

        

  10.     
            if ((result = mmc_server_store(mmc, request, request_len TSRMLS_CC)) < 0) {

        

  11.     
                mmc_server_failure(mmc TSRMLS_CC);

        

  12.     
            }    

        

  13.     
        }

        

  14.     
      // …

        

  15.     
    }

        

  16.     
     

        

  17.     
    // ..

        

  18.     
    int mmc_server_failure(mmc_t *mmc TSRMLS_DC) /*

        

  19.     
        determines if a request should be retried or is a hard network failure {{{ */

        

  20.     
    {

        

  21.     
        switch (mmc->status) {

        

  22.     
            case MMC_STATUS_DISCONNECTED:

        

  23.     
                return 0;

        

  24.     
     

        

  25.     
            /* attempt reconnect of sockets in unknown state */

        

  26.     
            case MMC_STATUS_UNKNOWN:

        

  27.     
                mmc->status = MMC_STATUS_DISCONNECTED;

        

  28.     
                return 0;

        

  29.     
        }

        

  30.     
     

        

  31.     
        mmc_server_deactivate(mmc TSRMLS_CC);

        

  32.     
        return 1;

        

  33.     
    }

        

在这里,我们发现,如果store失败的话,下面会有一个容错处理,通过php -i | grep memcache 可以看到容错配置确实是打开的。
在容错的代码中明显发现做了断开连接的操作,但是在哪里重连的呢? 

这要看mmc_hash_find_server的实现了,有时间再看。。。

留下评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据