?生产环境有一个Redis会偶尔发生连接失败的报错，报错的时间点、客户端IP并没有特别明显的规律，过一会儿，报错会自动恢复。
?以下是客户端报错信息：

?从报错的信息来看，应该是连接不上Redis所致。Redis的版本是2.8.19。虽然版本有点老，但基本运行稳定。
?线上环境只有这个集群有偶尔报错。这个集群的一个比较明显的特征是客户端服务器比较多，有上百台。

?从报错的信息来看，客户端连接不到服务端。常见的原因有以下几点：

?从服务端的部署的监控来看，出问题的点上，连接数有一个突然飙升，从3500个连接突然飙升至4100个连接。如下图显示：

同时间，服务器端显示Redis服务端有丢包现象：345539 – 344683 = 856个包。

?客户端报错的原因基本确定，是因为建连速度太快，导致服务端backlog队列溢出，连接被server端reset。

?在高并发的短连接服务中，这是一种很常见的tcp报错类型。一个正常的tcp建连过程如下：

?1.client发送一个(SYN)给server

?2.server返回一个(SYN,ACK)给client

?3.client返回一个(ACK)

?三次握手结束，对client来说建连成功，client可以继续发送数据包给server，但是这个时候server端未必ready，如下图所示 ：

在BSD版本内核实现的tcp协议中，server端建连过程需要两个队列，一个是SYN queue，一个是accept queue。前者叫半开连接（或者半连接）队列，在接收到client发送的SYN时加入队列。（一种常见的网络攻击方式就是不断发送SYN但是不发送ACK从而导致server端的半开队列撑爆，server端拒绝服务。）后者叫全连接队列，server返回(SYN,ACK)，在接收到client发送ACK后（此时client会认为建连已经完成，会开始发送PSH包），如果accept queue没有满，那么server从SYN queue把连接信息移到accept queue；如果此时accept queue溢出的话，server的行为要看配置。如果tcp_abort_on_overflow为0（默认），那么直接drop掉client发送的PSH包，此时client会进入重发过程，一段时间后server端重新发送SYN,ACK，重新从建连的第二步开始；如果tcp_abort_on_overflow为1，那么server端发现accept queue满之后直接发送reset。

通过wireshark搜索发现在一秒内有超过2000次对Redis Server端发起建连请求。我们尝试修改tcp backlog大小，从511调整到2048, 问题并没有得到解决。所以此类微调，并不能彻底的解决问题。

我们用wireshark来识别网络拥塞的准确时间点和原因。我们已经有了准确的报错时间点，先用editcap把超大的tcp包裁剪一下，裁成30秒间隔，并通过wireshark I/O 100ms间隔分析网络阻塞的准确时间点：

?根据图标可以明显看到tcp的packets来往存在block。

?对该block前后的网络包进行明细分析，网络包来往情况如下：

12:01:54.6808480, Redis Server端向客户端发送了一个Push包，也就是对于查询请求的一个结果返回。后面的包都是在做连接处理，包括Ack包，Ack确认包，以及重置的RST包，紧接着下面一个Push包是在12:01:56.1181350发出的。中间的间隔是1.4372870秒。也就是说，在这1.4372870秒期间，Redis的服务器端，除了做一个查询，其他的操作都是在做建连，或拒绝连接。

客户端报错的前后逻辑已经清楚了，redis-server卡了1.43秒，client的connection pool被打满，疯狂新建连接，server的accept queue满，直接拒绝服务，client报错。开始怀疑client发送了特殊命令，这时需要确认一下client的最后几个命令是什么，找到redis-server卡死前的第一个包，装一个wireshark的redis插件，看到最后几个命令是简单的get，并且key-value都很小，不至于需要耗费1.43秒才能完成。服务端也没有slow log，此时排障再次陷入僵局。

为了了解这1.43秒之内，Redis Server在做什么事情，我们用pstack来抓取信息。Pstack本质上是gdb attach. 高频率的抓取会影响redis的吞吐。死循环0.5秒一次无脑抓，在redis-server卡死的时候抓到堆栈如下(过滤了没用的栈信息)：

重复多次抓取后，从堆栈中发现可疑堆栈clientsCronResizeQueryBuffer位置，属于serverCron()函数下，这个redis-server内部的定时调度，并不在用户线程下，这个解释了为什么卡死的时候没有出现慢查询。

查看redis源码，确认到底redis-server在做什么：

clientsCron首先判断当前client的数量，用于控制一次清理连接的数量，生产服务器单实例的连接数量在5000不到，也就是一次清理的连接数是50个。

如果redisClient对象的query buffer满足条件，那么就直接resize掉。满足条件的连接分成两种，一种是真的很大的，比该客户端一段时间内使用的峰值还大；还有一种是很闲（idle>2）的，这两种都要满足一个条件，就是buffer free的部分超过1k。那么redis-server卡住的原因就是正好有那么50个很大的或者空闲的并且free size超过了1k大小连接的同时循环做了resize，由于redis都属于单线程工作的程序，所以block了client。那么解决这个问题办法就很明朗了，让resize 的频率变低或者resize的执行速度变快。

既然问题出在query buffer上，我们先看一下这个东西被修改的位置：

由此可见c->querybuf在连接第一次读取命令后的大小就会被分配至少1024*32，所以回过头再去看resize的清理逻辑就明显存在问题，每个被使用到的query buffer的大小至少就是1024*32，但是清理的时候判断条件是>1024，也就是说，所有的idle>2的被使用过的连接都会被resize掉，下次接收到请求的时候再重新分配到1024*32，这个其实是没有必要的，在访问比较频繁的群集，内存会被频繁得回收重分配，所以我们尝试将清理的判断条件改造为如下，就可以避免大部分没有必要的resize操作：

这个改造的副作用是内存的开销，按照一个实例5k连接计算，5000*1024*32=160M，这点内存消耗对于上百G内存的服务器完全可以接受。

在使用修改过源码的Redis server后，问题仍然重现了，客户端还是会报同类型的错误，且报错的时候，服务器内存依然会出现抖动。抓取内存堆栈信息如下：