Redis连接池耗尽排查实战_Redis

一、先别急着重启：是"池空"不是"宕机"

看到 could not get a resource from the pool 这行报错，多数人的本能反应是：redis 挂了，重启 redis，重连一波，看着恢复了——结果过会儿又超时。

讲真的，连接池耗尽和 redis 宕机不是一回事。宕机是 redis 进程不在了；连接池耗尽是连接都被应用借走没还，池子空了，新请求拿不到连接，只能干等或失败。重启只是把连接释放了一次，根因（应用不还连接）没动，所以还会再来。

防汛防台巡检期，机房恰恰怕这种慢慢耗尽的连接池，它比硬件坏更隐蔽，监控上 redis 进程一直是绿的。

二、诊断3板斧：报错、连接数、慢日志

① 看报错定性质

应用抛 could not get a resource from the pool，先确认是应用层报的错，不是 redis 自己拒绝。这说明池子空了、借不到连接。

为什么这么查：这句报错来自 jedis/lettuce 连接池，含义是"从池里拿资源失败"。它直接告诉你问题在连接池，不在 redis 服务本身，避免你白重启 redis。

② 看 redis 连接数

用下面两条看当前连接情况：

redis-cli info clients
# 重点看 connected_clients 和 blocked_clients
redis-cli client list
# 逐条看 idle（空闲秒数）、cmd（卡在哪个命令）、addr（来自哪个应用）

为什么这么查：如果 connected_clients 一直顶着不放、一堆 client 的 idle 很大却没释放，说明应用拿连接不归还；如果连接数忽高忽低，那是峰值配置太小、并发一上来就借光。两种根因，治法完全不同。

③ 看慢日志与大 key

redis-cli slowlog get 20
# 看执行时间长的命令

redis-cli --bigkeys
# 扫描找出占用内存大的 key

为什么这么查：慢命令（比如大范围 keys *、大 key 的删除）会长时间占着一条连接，把池子拖满。这类问题你调大池子也没用，因为连接是被慢操作卡住的，不是不够借。

步骤	看什么	指向的根因
① 看报错	是不是应用层 pool 报错	池空，不是 redis 宕机
② 看连接数	connected_clients / idle	应用不还 or 峰值配置小
③ 看慢日志	slowlog / --bigkeys	慢命令、大 key 占坑

三、查泄漏与根治：第四步第五步怎么走

④ 查代码哪里漏

连接池耗尽的底层几乎都是"借了不还"。常见泄漏点：

异常路径没在 finally 里 close()，连接抛异常就永久泄漏；
连接池 maxtotal 设太小，并发一上来就被借光；
借了连接去做耗时外部调用，连接长时间不归还；
事务/管道用了一半没释放。

为什么查代码：调大池子只是把"借光"推后，泄漏点不补，加多大都挡不住。原因就一句——借了不还，池子早晚被借光。

⑤ 止血与根治

# 临时止血：调大上限 + 加获取超时，避免无限等待
maxtotal = 200
maxwaitmillis = 3000   # 拿不到连接就快速失败，不卡线程

# 根治：补 close + 限流 + 拆大 key
try { jedis = pool.getresource(); ... }
finally { if (jedis != null) jedis.close(); }

为什么分两步：临时调大 maxtotal、加获取超时，能先止血让接口恢复；根治是补 close、做限流、把大 key 拆小，再给连接数设监控阈值。临时方案只是拖时间，根因不除第二天还来。

当然也有人不这么想，觉得加机器堆配置就行。可连接泄漏是代码层面的"借了不还"，加机器只是让每个机器都漏，白搭。