QPS过万，redis大量链接超时怎么解决？

7月2号10点后，恰好某个负责的服务发生大量的redis链接超时的异常(redis.clients.jedis.exceptions.JedisConnectionException)，因为自己的数据库查询缓存在redis中2分钟，而且未作降级措施，并且自己不能作限流处理，并且随着午高峰的时间流量在飙升，而且从10点开始的2000的QPS，在11点达到高峰的13000QPS。

​ 好在只是redis超时致使的某个查询的失效，并不会致使整个主链路的流程不可用，因此接下来是怎么快速发现和解决问题。

一、首先和负责redis同窗排查，先排除redis自己的问题

二、服务自查

异常分布

若是监控能够看到单机维度的话，切换到单机维度查看异常是否均匀分布，若是分布不均匀，只是少许的host特别高，基本能够定位到出现问题的机器

Redis负载

查看redis集群是否有节点负载太高，好比以常规经验看来的80%。

• 若是有一个或少许节点超过，则说明存在「热key」问题。
• 若是大部分节点都超过，则说明存在「redis总体压力大」问题。

慢请求

查看监控，若是有慢请求的时间和发生问题的时间匹配，则可能存在「大key」问题

客户端缘由

常见的几个问题缘由有：

• CPU
• 进程GC
• 网络
• 容器宿主机

CPU

观察机器或容器的CPU：

• CPU （100%）是否接近或超过80%
• CPU限流是否存在密集的限流 或者长时间的限流

若是存在这些现象，应该是「计算资源不足」的问题

进程GC

频繁的GC或者GC耗时过长会让线程没法及时被调度到读取redis响应。

一般是用每分钟GC总时长/60s/每分钟GC个数，若是达到ms级了，对redis读写延迟的影响就会很明显。

而后也要对比和以前正常时是否存在明显上升。

网络

度量网络质量通常能够看TCP重传率的监控，这个比率越低越好。若是TCP重传率保持在0.02%（以本身的实际状况为准）以上，或者突增，能够定位到是不是「网络问题」。

个人问题定位到这里其实已经发现了，容器的TCP重传率很是高，有些甚至达到了0.6%，咨询容器的同事建议重启容器，重启以后马上解决问题。

继续说排查思路。

容器宿主机

经过监控查看容器宿主机的CPU状况，有一些可能机器是虚拟机的状况，CPU的监控指标可能不许确，特别是对于io密集型的状况会有较大差别。能够通用OPS提供的其余手段来查询。

因为保密性的问题，问题的截图是不能放的，可是这个事情其实也是敲响一个警钟，熔断限流降级措施在关键性的链路必定要保证有，重要的事情说3遍，要有X3！

并且原来的历史代码自己也有一点小问题，这些缓存的数据其实大半年都不会变分担分的，彻底不须要redis缓存，内存级别的缓存就足够了，或者说内存缓存+redis作级缓存也是一个比较合理的方案。平时开发中要充分考虑数据的时效性来作对应的设计。

放松图