关于redis在高并发下的性能分析(2)-木庄网络博客

服务器状态迁移

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

有缺陷的客户端与持久连接

有一些客户端在处理持久连接(akakeepalives)时存在问题。当连接空闲下来服务器关闭连接时(基于KeepAliveTimeout指令)，

客户端的程序编制使它不发送FIN和ACK回服务器。这样就意味着这个连接将停留在FIN_WAIT_2状态直到以下之一发生：

客户端为同一个或者不同的站点打开新的连接，这样会使它在该个套接字上完全关闭以前的连接。

用户退出客户端程序，这样在一些(也许是大多数？)客户端上会使操作系统完全关闭连接。

FIN_WAIT_2超时，在那些具有FIN_WAIT_2状态超时设置的服务器上。

如果你够幸运，这样意味着那些有缺陷的客户端会完全关闭连接并释放你服务器的资源。

然而，有一些情况下套接字永远不会完全关闭，比如一个拨号客户端在关闭客户端程序之前从ISP断开。

此外，有的客户端有可能空置好几天不创建新连接，并且这样在好几天里保持着套接字的有效即使已经不再使用。这是浏览器或者操作系统的TCP实现的Bug。

　　产生原因有：

1、长连接并且当连接一直处于IDLE状态导致SERVERCLOSE时，CLIENT编程缺陷，没有向SERVER 发出FIN和ACK包

2、APACHE1.1和APACHE1.2增加了linger_close()函数，前面的帖子有介绍，这个函数可能引起了这个问题（为什么我也不清楚）

　　解决办法：

1。对FIN_WAIT_2状态增加超时机制，这个特性在协议里没有体现，但在一些OS中已经实现

如：LINUX、SOLARIS、FREEBSD、HP-UNIX、IRIX等

2。不要用linger_close()编译

3。用SO_LINGER代替，这个在某些系统中还能很好地处理

4。增加用于存储网络连接状态的内存mbuf，以防止内核crash

5。DISABLE KEEPALIVE

针对这种情况，我们做了几次讨论，有些结论，分别是：

1、设置nginx与redis的连接池，keepalive的时间，分别设为10秒，5秒，但是结果还是一样

2、不用keepalive，即不使用连接池，即每次用完就close()掉，你可以看到连接少了，但是不使用连接池，意味着10秒内要打开关闭10万次，开销太大

3、redis集群，在原本集群的体系上添加redis的集群，这或许能解决问题，但是10秒内10万实际上并不多，这样做了或许是取巧，并没有找到问题

4、设置redis的idle（空闲）时间限制，结果一样。

解决方案：

实际上不算解决方案，因为放弃了redis的内存机制，而是使用nginx本身的内存技术。网上关于redis的优化大部分不适用，这个问题有待分析解决。

数据库系统概念第6版

￥41.1元 机械工业出版社

本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。