高并发下redis的瓶颈分析

背景

最近接到一个项目，负责架构设计与实现，原本单位做了很多给外边的人使用的api，但是对外给别人用的时候，接口的链接是怎样就给别人怎样的，没有加密也没有做并发控制，接口程序所在的机器在哪儿，给别人的ip就是哪儿，而且没有一个平台来管理它们，我们很难知道这些接口的价值（哪个别人用得比较多，哪个比较少），这就是这个项目的由来

仅仅针对”监控“的这一需求，我们引入了redis作为中间层，首先我们完善了用户使用接口的注册流程，通过用户信息和地址，hash出一个key，这个key是对应着一个地址的，把这个（key - 地址）对存在了redis里面。其次是nginx，nginx在我们的项目里面的流程大概是这样：

1、用户注册之后获取到他的key，通过包含了key的跟原本的url完全不同的url来访问

2、nginx捕获到用户特殊的key，然后程序根据这个key从redis中取出目标地址，再由nginx代替用户访问真正的地址，继而返回。

（这个过程好处是很多的）

（1）、隐藏了真实的地址，程序可以在上游服务器之外的地方干预用户的访问，提高安全性，干预过程可以很复杂

（2）、获取用户的信息，并将其存回redis，上游服务器通过定时程序将存在redis中的日志持久化进oracle并删除，然后进一步分析和可视化

问题来了

这个项目还处于测试阶段，资源是一台window server 服务器，和centos6.5服务器，测试阶段10秒内大概有10万的并发量，刚部署上去的一两天还是没有问题的，接下来却出现了redis连接不上的情况。查看进程访问，会出现下面的情况。（window server 下）

出现很多FiN_WAIT_2的TCP链接。

分析

一、redis是使用单线程处理连接的，意味着它绝对会出现下面二所说的情况。

二、很明显这是由于nginx和redis之间有很多没有释放的资源造成的，查看这个TCP的状态FIN_WAIT_2，解释一下：

在HTTP应用中，存在一个问题，SERVER由于某种原因关闭连接，如KEEPALIVE的超时，这样，作为主动关闭的SERVER一方就会进入 FIN_WAIT2状态，但TCP/IP协议栈有个问题，FIN_WAIT2状态是没有超时的（不象TIME_WAIT状态），所以如果CLIENT不关闭，这个FIN_WAIT_2状态将保持到系统重新启动，越来越多的FIN_WAIT_2状态会致使内核crash。 

好吧，大学没有好好念书，下面是http连接的状态变化

客户端状态迁移

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSEDb.

服务器状态迁移

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的优化大部分不适用，这个问题有待分析解决。