速读摘要文章源自JAVA秀-https://www.javaxiu.com/10419.html
业务的特性，本身未做降级、限流等处理措施，而在巅峰的QPS基本上快达到20000的样子，虽然这个现象只是单纯的一个异常，并不会导致整个主链路的流程不可用，但是我们还是要找出问题的原因并且解决。这就很舒服了，这一下子就找到了问题，只有几台机器异常非常高。我们看看CPU使用率多高，是不是超过80%了，还是根据经验，我们之前的服务一般高峰能达到60%就不错了。我们可以这样计算，再次按照我们一塌糊涂的经验，每分钟GC总时长/60s/每分钟GC个数，如果达到ms级了，对redis读写延迟的影响就会很明显。文章源自JAVA秀-https://www.javaxiu.com/10419.html
原文约 1288 字 | 图片 2 张 | 建议阅读 3 分钟 | 评价反馈文章源自JAVA秀-https://www.javaxiu.com/10419.html
QPS过万，Redis大量连接超时怎么解决？
程序员小灰 文章源自JAVA秀-https://www.javaxiu.com/10419.html
以下文章来源于艾小仙，作者艾小仙文章源自JAVA秀-https://www.javaxiu.com/10419.html
文章源自JAVA秀-https://www.javaxiu.com/10419.html 文章源自JAVA秀-https://www.javaxiu.com/10419.html 艾小仙文章源自JAVA秀-https://www.javaxiu.com/10419.html 一个愤世嫉俗，脱离低级趣味的人文章源自JAVA秀-https://www.javaxiu.com/10419.html
之前负责的一个服务总是在高峰时刻和压测发生大量的redis连接超时的异常redis.clients.jedis.exceptions.JedisConnectionException，根据原有的业务规则，首先会从数据库查询，然后缓存到redis中，超时时间设置为3分钟。文章源自JAVA秀-https://www.javaxiu.com/10419.html
并且由于业务的特性，本身未做降级、限流等处理措施，而在巅峰的QPS基本上快达到20000的样子，虽然这个现象只是单纯的一个异常，并不会导致整个主链路的流程不可用，但是我们还是要找出问题的原因并且解决。文章源自JAVA秀-https://www.javaxiu.com/10419.html
首先我们找到负责Redis同学排查，他们告诉我Redis现在很稳定，没有问题，以前现在未来都不会出问题，出了问题肯定是你们自己的问题。文章源自JAVA秀-https://www.javaxiu.com/10419.html
... ...文章源自JAVA秀-https://www.javaxiu.com/10419.html
说的好有道理，我竟无力反驳，真是让人两个头一个大。文章源自JAVA秀-https://www.javaxiu.com/10419.html
这样的话，我们就只能去找找自身的原因了。文章源自JAVA秀-https://www.javaxiu.com/10419.html
排查思路
查看异常分布
首先根据经验，我们看看自己的服务器的情况，看下异常到底出现在哪些机器，通过监控切换到单机维度，看看异常是否均匀分布，如果分布不均匀，只是少量的host特别高，基本可以定位到出现问题的机器。文章源自JAVA秀-https://www.javaxiu.com/10419.html
诶，这就很舒服了，这一下子就找到了问题，只有几台机器异常非常高。文章源自JAVA秀-https://www.javaxiu.com/10419.html
不过不能这样，我们继续说排查思路......文章源自JAVA秀-https://www.javaxiu.com/10419.html
Redis情况
再次按照经验，虽然负责redis的同学说redis贼稳定巴拉巴拉，但是我们本着怀疑的态度，不能太相信他们说的话，这点很重要，特别是工作中，同学们，不要别人说啥你就信啥，要本着柯南的精神，发生命案的时候每个人都是犯罪嫌疑人，当然你要排除自己，坚定不移的相信这肯定不是我的锅！文章源自JAVA秀-https://www.javaxiu.com/10419.html
好了，我们看看redis集群是否有节点负载过高，比如以常规经验看来的80%可以作为一个临界值。文章源自JAVA秀-https://www.javaxiu.com/10419.html
如果有一个或少量节点超过，则说明可能存在热key问题，如果大部分节点都超过，则说明存在redis整体压力大问题。文章源自JAVA秀-https://www.javaxiu.com/10419.html
另外可以看看是否有慢请求的情况，如果有慢请求，并且时间发生问题的时间匹配，那么可能是存在大key的问题。文章源自JAVA秀-https://www.javaxiu.com/10419.html
嗯... ...文章源自JAVA秀-https://www.javaxiu.com/10419.html
redis同学说的没错，redis稳如老狗。文章源自JAVA秀-https://www.javaxiu.com/10419.html
CPU
我们假设自己还是很无助，还是没发现问题在哪儿，别急，接着找找别人的原因，看看CPU咋样，可能运维偷偷滴给我们把机器配置给整差了。文章源自JAVA秀-https://www.javaxiu.com/10419.html
我们看看CPU使用率多高，是不是超过80%了，还是根据经验，我们之前的服务一般高峰能达到60%就不错了。文章源自JAVA秀-https://www.javaxiu.com/10419.html
再看看CPU是不是存在限流，或者存在密集的限流、长时间的限流。文章源自JAVA秀-https://www.javaxiu.com/10419.html
如果存在这些现象，应该就是运维的锅，给我们机器资源不够啊。文章源自JAVA秀-https://www.javaxiu.com/10419.html
GC停顿
得嘞，运维这次没作死。文章源自JAVA秀-https://www.javaxiu.com/10419.html
再看看GC咋样。文章源自JAVA秀-https://www.javaxiu.com/10419.html
频繁的GC、GC耗时过长都会让线程无法及时读取redis响应。文章源自JAVA秀-https://www.javaxiu.com/10419.html
这个数字怎么判断呢？文章源自JAVA秀-https://www.javaxiu.com/10419.html
通常，我们可以这样计算，再次按照我们一塌糊涂的经验，每分钟GC总时长/60s/每分钟GC个数，如果达到ms级了，对redis读写延迟的影响就会很明显。文章源自JAVA秀-https://www.javaxiu.com/10419.html
为了稳一手，我们也要对比下和历史监控级别是否差不多一致。文章源自JAVA秀-https://www.javaxiu.com/10419.html
好了，打扰了，我们继续。文章源自JAVA秀-https://www.javaxiu.com/10419.html
网络
网络这块我们主要看TCP重传率，这个基本在大点的公司都有这块监控。文章源自JAVA秀-https://www.javaxiu.com/10419.html
TCP重传率=单位时间内TCP重传包数量/TCP发包总数文章源自JAVA秀-https://www.javaxiu.com/10419.html
我们可以把TCP重传率视为网络质量和服务器稳定性的一个只要衡量指标。文章源自JAVA秀-https://www.javaxiu.com/10419.html
还是根据我们的经验，这个TCP重传率越低越好，越低代表我们的网络越好，如果TCP重传率保持在0.02%（以自己的实际情况为准）以上，或者突增，就可以怀疑是不是网络问题了。文章源自JAVA秀-https://www.javaxiu.com/10419.html
文章源自JAVA秀-https://www.javaxiu.com/10419.html
比如这张图一样，要是和心电图一样，基本上网络问题就没跑了。文章源自JAVA秀-https://www.javaxiu.com/10419.html
容器宿主机
有一些机器有可能是虚拟机，CPU的监控指标可能不准确，特别是对于IO密集型的情况会有较大差异。可以通用其他手段来查询宿主机的情况。文章源自JAVA秀-https://www.javaxiu.com/10419.html
最后
根据一系列的骚操作，我们根据定位到的机器然后排查了一堆情况，最终定位到是网络问题，有单独的几台机器在高峰时期TCP重传率贼高，最后根据运维提供的解决方案：【重启有问题的机器】，我们很顺利的就解决了这个问题。文章源自JAVA秀-https://www.javaxiu.com/10419.html
文章源自JAVA秀-https://www.javaxiu.com/10419.html
评论