QPS过万,Redis大量连接超时怎么解决?

网友投稿 1109 2023-05-28

QPS过万,Redis大量连接超时怎么解决?

QPS过万,Redis大量连接超时怎么解决?

之前负责的一个服务总是在高峰时刻和压测发生大量的redis连接超时的异常redis.clients.jedis.exceptions.JedisConnectionException,根据原有的业务规则,首先会从数据库查询,然后缓存到redis中,超时时间设置为3分钟。

并且由于业务的特性,本身未做降级、限流等处理措施,而在巅峰的QPS基本上快达到20000的样子,虽然这个现象只是单纯的一个异常,并不会导致整个主链路的流程不可用,但是我们还是要找出问题的原因并且解决。

首先我们找到负责Redis同学排查,他们告诉我Redis现在很稳定,没有问题,以前现在未来都不会出问题,出了问题肯定是你们自己的问题。

... ...

说的好有道理,我竟无力反驳,真是让人两个头一个大。

这样的话,我们就只能去找找自身的原因了。

排查思路

查看异常分布

首先根据经验,我们看看自己的服务器的情况,看下异常到底出现在哪些机器,通过监控切换到单机维度,看看异常是否均匀分布,如果分布不均匀,只是少量的host特别高,基本可以定位到出现问题的机器。

诶,这就很舒服了,这一下子就找到了问题,只有几台机器异常非常高。

不过不能这样,我们继续说排查思路......

Redis情况

再次按照经验,虽然负责redis的同学说redis贼稳定巴拉巴拉,但是我们本着怀疑的态度,不能太相信他们说的话,这点很重要,特别是工作中,同学们,不要别人说啥你就信啥,要本着柯南的精神,发生命案的时候每个人都是犯罪嫌疑人,当然你要排除自己,坚定不移的相信这肯定不是我的锅!

好了,我们看看redis集群是否有节点负载过高,比如以常规经验看来的80%可以作为一个临界值。

如果有一个或少量节点超过,则说明可能存在热key问题,如果大部分节点都超过,则说明存在redis整体压力大问题。

另外可以看看是否有慢请求的情况,如果有慢请求,并且时间发生问题的时间匹配,那么可能是存在大key的问题。

嗯... ...

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重传率保持在0.02%(以自己的实际情况为准)以上,或者突增,就可以怀疑是不是网络问题了。

比如这张图一样,要是和心电图一样,基本上网络问题就没跑了。

容器宿主机

有一些机器有可能是虚拟机,CPU的监控指标可能不准确,特别是对于IO密集型的情况会有较大差异。可以通用其他手段来查询宿主机的情况。

最后

根据一系列的骚操作,我们根据定位到的机器然后排查了一堆情况,最终定位到是网络问题,有单独的几台机器在高峰时期TCP重传率贼高,最后根据运维提供的解决方案:【重启有问题的机器】,我们很顺利的就解决了这个问题。

但是,这毕竟是治标不治本的办法,最终怎么解决的?

在我的另外一篇文章我有写到了,没人告诉过你更复杂的缓存穿透怎么解决

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:高并发之存储篇:关注下索引原理和优化吧!躲得过实践,躲不过面试官!
下一篇:分分钟致命的MySQL安全盲区
相关文章