技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统运维 --> 关于Memcache长连接自动重连的问题

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

浏览:3682次  出处信息
使用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的现象。

建议继续学习:

  1. 关于memcache分布式一致性hash    (阅读:10714)
  2. 长连接(KeepAlive)在 http 连接中的性能影响    (阅读:7157)
  3. 一种基于长连接的社交游戏服务器程序构架    (阅读:6580)
  4. Memcache分布式部署方案    (阅读:5507)
  5. 关于session和memcache的若干问题    (阅读:4299)
  6. Memcache源代码分析之数据存储    (阅读:3954)
  7. Memcache mutex设计模式    (阅读:3775)
  8. Memcache源代码分析之网络处理    (阅读:3657)
  9. Memcache协议的学习    (阅读:3629)
  10. memcache的几点注意    (阅读:3478)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1