曾经负责一个服务，在高峰期和压力测试的时候总是出现大量的redis连接超时异常。在redis中，超时设置为3分钟。并且由于业务特点，没有采取降级、限流等处理措施，峰值QPS基本达到20000。这种现象虽然只是一个简单的异常，但不会导致整个主链接过程失败。使用，但还是要找出问题的原因并解决。首先，我们找到Redis的负责同学进行调查。他们跟我说Redis现在很稳定，没有问题。……有道理，但我无力反驳。真是让人两个头一个大。遇到这种情况，只能自己找原因了。排查思路查看异常分布情况首先，根据经验，我们看一下自己服务器的情况，看看异常发生在哪些机器上，通过监控切换到单机维度，看异常分布是否均匀。如果分布不均匀，只是主机数量少，频率很高，基本可以定位出问题的机器。哎，这个很舒服，一下子就发现了问题，只有几台机器异常高。但是不能这样，下面继续说一下排查思路……Redis的情况又是经验之谈了。虽然负责redis的同学说redis盗贼稳定，但是我们持怀疑态度，不敢相信他们说的话。这个非常重要。重要的是，尤其是在工作中，同学们，不要只相信别人说的话，要遵循柯南精神，一旦发生凶杀案，每个人都是犯罪嫌疑人，当然要排除自己，坚定不移地相信这个肯定不是我的错！那我们看看是不是redis集群有节点负载过高，比如按照常规经验80%可以作为临界值。如果一个或少数节点超过该值，则意味着可能存在热键问题。如果大部分节点超过该值，则说明redis的整体压力有问题。另外可以查看是否有慢请求。如果有缓慢的请求和时间问题匹配的时间，则可能是大密钥有问题。嗯……redis同学说的对，redis稳如老狗。对于CPU，假设我们还是束手无策，还是没有发现问题所在。不着急，再找找别人的原因，看看CPU怎么样。说不定运维会偷偷给我们降机器配置。我们看看CPU占用率有多高，看看有没有超过80%。根据经验，我们之前的业务一般峰值在60%左右，已经不错了。然后查看CPU是否有限流，或者有密集限流或者长期限流。如果存在这些现象，那应该是运维的锅，我们的机器资源不够用。GC暂停了，运维这次没死。让我们来看看GC。频繁的GC和GC时间过长会导致线程无法及时读取redis的响应。如何判断这个数字？通常，我们可以这样计算，再根据我们乱七八糟的经验，每分钟GC总时间/60s/每分钟GC次数，如果达到ms级别，对redis读写延迟的影响就是明显的。为了确定，我们还需要对比一下是否和历史监控水平相差无几。好吧，对不起，让我们继续。对于网络，我们主要看TCP重传率，大公司基本都是监控的。TCP重传率=单位时间内TCP重传包数/发送的TCP包总数。我们可以将TCP重传率视为网络质量和服务器稳定性的指标。根据我们的经验，TCP重传率越低越好。TCP重传率越低，我们的网络就越好。可能怀疑是网络问题。比如跟这张图一样，跟心电图一样的话，基本上网络问题跑不了。容器宿主机部分机器可能是虚拟机，CPU监控指标可能不准确，尤其是IO密集型的情况。可以使用其他方式查询主机。最后根据一系列的风骚操作，根据定位到的机器排查了一堆情况，最终定位到网络问题。高峰期有个别机器TCP重传率高。最后根据运维提供的信息解决方案：【重启有问题的机器】，我们很顺利的解决了这个问题。不过，这毕竟是治标不治本。你最后是怎么解决的？在我的另一篇文章中，我写到没有人告诉你如何解决更复杂的缓存穿透
