互联网常识：关于redis在高并发下的性能分析

更新时间:2023-02-24 14:41:44 阅读：评论：0

导读跟大家讲解下有关关于redis在高并发下的性能分析，相信小伙伴们对这个话题应该也很关注吧，现在就为小伙伴们说说关于redis在高并发下的 2020高考大学录取分数线

跟大家讲解下有关关于redis在高并发下的性能分析，相信小伙伴们对心理问题有哪些这个话题应该也很关注吧，现在就为小伙伴们说说关于redis在高并发下的性能分析，小编也收集到了有关关于redis在高并发下的性能分析的相关资料，希望大家看到了会喜欢。

前言：

最近上手了一个项目我负责该项目的架构设计与实现。本来公司做了很多给公司以外的人使用的API但是在外人使用的时候接口的链接是怎样就给别人怎么样没有加密也没有做并发控制接口程序所在的机器在哪给别人的IP就在哪而且没有平台进行管理。因此我清楚地知道这些接口的价值很难被发现（哪个接口别人用的比较多哪个接口别人用的比较少）。

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

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

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

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

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

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

问题来了

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

出现很多FiN_WAIT_2的TCP链接。

（学习视频分享：redis视频教程）

分析

一、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->TIM努力的名人例子E_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_clo函数前面的帖子有介绍这个函数可能引起了这个问题（为什么我也不清楚）

　　解决办法：

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

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

2。不要用linger_clo编译

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

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

5。DISABLE KEEPALIVE

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

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

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

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

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

解决方案：

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