记一次华为云ECS下Redis连接池耗尽报Could not get a resource from the pool排查与调优

昨天线上系统在业务高峰期突然收到报警，华为云 ECS 上运行的 Java 后端服务频繁抛出 redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool 异常。由于连接池获取连接超时，部分高并发接口响应延迟飙升，最终触发了限流。

一开始以为是 ECS 机器网络波动或者 Redis 实例 CPU 满了，但在华为云云监控控制台上查看 ECS 的 CPU、内存和网络带宽一切正常。于是我决定直接登录到对应的 ECS 弹性云服务器上进行详细排查。

第一步：登录机器排查连接数与慢查询
登录到 ECS 后，首先通过终端连接 Redis 实例，执行命令：
redis-cli info clients
观察发现 connected_clients 已经达到了设置的最大连接上限，blocked_clients 也在持续增加。
随后运行 netstat -antp | grep 6379 检查 TCP 链接状态，发现大量的 ESTABLISHED 连接处于空闲状态，且长时间没有被客户端主动释放或复用。

接着我通过 Redis 命令排查是否有长耗时的慢命令阻塞了 Redis 的单线程事件循环：
SLOWLOG GET 10
结果慢日志里赫然打印出了几条执行时间长达几百毫秒甚至上秒的 keys user_token:* 和 keys order_cache:* 模糊查询命令！
定位源码后发现，是早期历史遗留的一段批处理逻辑，在每次用户请求时都会去调用 keys 命令遍历匹配大 Key。Redis 是单线程架构，全局 keys 模糊匹配直接卡住了后续所有命令的响应，导致 Jedis 连接池中的连接无法被及时归还，后续请求不断积压，最终抛出 Could not get a resource from the pool。

第二步：代码重构与连接池参数调优
针对排查出的问题，我主要做了两方面的优化改造：

1. 优化大 Key 遍历逻辑：
   将原先导致阻塞的 keys 模糊匹配彻底废弃，重构为基于 SCAN 游标的分批迭代方式。SCAN 命令是非阻塞的，每次只返回少量匹配结果，避免了单次操作长时间占用单线程。

2. 重构 Jedis 连接池配置：
   检查原先的连接池配置发现参数设置过于保守，且没有开启空闲连接检测。重新调整连接池核心参数如下：

JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(128);
poolConfig.setMaxIdle(32);
poolConfig.setMinIdle(8);
poolConfig.setMaxWaitMillis(2000);
poolConfig.setTestWhileIdle(true);
poolConfig.setTimeBetweenEvictionRunsMillis(30000);

上线部署与复盘：
修复代码提交并重新部署到华为云 ECS 节点后，再次压测并观察了当晚的高峰期表现。Redis 的连接池等待队列始终维持在平稳状态，慢日志中不再有 keys 阻塞记录，Could not get a resource from the pool 异常彻底消失。这次排查也提醒我们，对于 Redis 的使用必须严格规避 keys 等大 Key 遍历命令，同时连接池参数一定要结合真实并发量合理配置并开启健康检查。