7月2号10点后，刚好某个负责的服务发生大量的redis连接超时的异常(redis.clients.jedis.exceptions.JedisConnectionException)，由于本身的数据库查询缓存在redis中2分钟，并且未做降级措施，而且本身不能做限流处理，而且随着午高峰的时间流量在飙升，并且从10点开始的2000的QPS，在11点达到高峰的13000QPS。
好在只是redis超时导致的某个查询的失效，并不会导致整个主链路的流程不可用，所以接下来是怎么快速发现和解决问题。
1、首先和负责redis同学排查，先排除redis本身的问题
2、服务自查
异常分布
如果监控可以看到单机维度的话，切换到单机维度查看异常是否均匀分布，如果分布不均匀，只是少量的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做级缓存也是一个比较合理的方案。平时开发中要充分考虑数据的时效性来做对应的设计。
放松图
