概述

---

最近不知道咋回事，老是在线上遇到偶发的故障，它突然出现，又很快消失了。

在2023年3月11下午差不多六点左右，我正在工位上喝着香味扑鼻的金骏眉红茶，突然接到了一个电话，拿起手机一看，是阿里云告警电话，马上接通，听到的是下面这么一句话：

Dubbo调用超时故障。

噗，已流入喉咙的红茶差点喷出来，赶紧打开阿里云的SLS日志平台，搜索了一下，发现A服务的RPC接口部分超时了，马上进入熟悉的线上定位套路。

• 看流量是否陡增；
• 看是否发版导致的；

还是用SLS日志平台查看流量，发现流量是平滑的，这一步花了10秒钟，然后再看最近A服务是否有发版，发现也没有，这一步花了我10秒。

20秒钟后，正当我想让运维重启A服务的时候，团队的一个同事过来跟说，没有报错了。我重新查了一下日志，确实没有继续报错了，就让同事继续盯着，我自己开始定位原因。

注意，这里由于故障时间非常短，且是一个A服务的读接口有问题，可以暂时不用去考虑影响面，肯定是非常小的。

然后就开始漫长且辛苦的定位之路了。通过查看错误日志，发现是A服务获取Redis连接超时了。

redis.clients.jedis.exceptions.JedisConnectionException : Failed connecting to xxxxxx.redis.rds.aliyuncs.com:kkkk
Caused by: java.net.SocketTimeoutException : connect timed out

而且报错的都是同一个业务接口，细看一下代码后，发现只是一个普通的get命令，就报错了。

在流量没怎么变化的情况下，只能从下面两个方面入手：

• 当时A服务到底占用了Redis多少个连接；
• A服务的Redis连接配置。

想看A服务的Redis连接情况，可以在阿里云的Redis监控平台上看。

从上图可以看到A服务(包含所有的Pod实例)在56分左右，最高占用了211个Redis连接，并不多，难道是A服务的Redis连接配置的不合理?

maxIdle:100
maxTotal:300

从配置上看是正常的，每一个A服务的Pod实例，当有100个Redis连接正在处理请求的时候，如果还忙不过来，会继续创建新的Redis连接，一直到300个。

才占用了211连接，不可能导致A服务拿不到Redis连接的，不会是211这个数字有什么玄乎的吧? 真的只能承受这么多?
于是去找了一下A服务在历史上，最高占用了多少个Redis连接，发现是：

是390个，这就有点搞不懂了，占用390个连接没问题，211个反而有问题? 没办法了，只能让运维去看一下是否有网络抖动情况，但是运维很快回复说：

一切正常,且当时整个Redis实例，运行状况是非常稳定的。

😂😂😂😂😂😂😂😂，那到底啥情况? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

我有点想甩锅给阿里云了，便让运维提了一个工单，去问一下阿里云的售后，但得到的回复是：

当时无HA切换，无闪断，RT也没有异常变高的情况。

到此，我也没啥的好的办法了，只能跟老板说明一下情况，然后把这个问题先放一放，持续观察。

期间其实我还看了很多东西，只是没什么收获，大概看了如下几个方面：

• 在56分的时候，这个Redis实例上的所有操作命令，是否有什么异常；
• 为什么当当是那个业务接口触发了这个问题；
• 对比了各个时间段，A服务和Redis实例的状态；