Redis 客户端连接池耗尽怎么定位：等待超时、连接复用与池参数验证

Redis 连接池耗尽时，最容易误判的是“Redis 连不上了”。实际上，客户端可能已经建立了两条连接，只是它们都被慢操作占用，新请求在池外排队，等到 PoolTimeout 到期才返回错误。定位这类问题要把客户端等待、服务端客户端列表和连接复用放在同一条证据链里。

先看 PoolStats 的等待次数和等待时长，再用 CLIENT LIST 确认服务端连接数；如果等待增长而 Redis 连接数没有异常，优先缩短连接占用时间或重新估算池大小。

先把“池满了”和“Redis 满了”分开

go-redis 会在客户端内部管理连接池。一个命令拿到连接后，连接在返回结果前不会被其他命令使用；当两个槽位都被占用，第三个请求只能等待。等待超时发生在客户端，Redis 服务端未必记录了一次新的业务命令。

这也是排查的第一道分叉：如果 PoolStats().WaitCount 上升、TimeoutCount 也上升，而 CLIENT LIST 中的连接数稳定，问题多半在池大小或命令占用时间；如果服务端已经接近 maxclients，则要先处理服务端连接上限。

用两个连接槽复现等待超时

下面的实验只使用两个连接槽。两个 goroutine 先执行阻塞命令，第三个 goroutine 调用 GET，它不会立刻访问 Redis，而是在客户端池中等待。PoolTimeout=120ms 到期后，程序把等待超时和池统计一起打印出来。

options := &redis.Options{
    Addr:        "127.0.0.1:6380",
    PoolSize:    2,
    PoolTimeout: 120 * time.Millisecond,
    ReadTimeout: 2 * time.Second,
    WriteTimeout: 2 * time.Second,
}
client := redis.NewClient(options)
defer client.Close()

for i := 0; i 

实验结果里的关键不是某个固定错误字符串，而是三件事同时出现：第三个请求耗时接近 120ms、返回连接池等待超时、WaitCount 增加。若只看到一个超时，却没有池统计变化，应该转去检查网络或 Redis 命令执行时间。

用 PoolStats 和 CLIENT LIST 判断占用链路

客户端指标回答“有没有人在等”，Redis 的 CLIENT LIST 回答“服务端看到了哪些连接”。在同一实验里执行 CLIENT LIST，可以看到连接数量与当前命令；两个阻塞连接存在时，第三个请求因为尚未取到连接，不会凭空增加一条业务连接。

stats := client.PoolStats()
fmt.Printf("hits=%d misses=%d timeouts=%d waits=%d\n",
    stats.Hits, stats.Misses, stats.Timeouts, stats.WaitCount)

// 另一个终端或 Redis 管理客户端执行：
// redis-cli -p 6380 CLIENT LIST

不要直接把 CLIENT LIST 的连接总数当作池大小。客户端还可能有订阅、哨兵或健康检查连接；更可靠的做法是给业务连接设置名称，结合命令字段和客户端统计观察一段完整请求。

调池大小前先确认连接为什么没有归还

增加 PoolSize 能提高并发上限，但会把更多并发压力推给 Redis。先确认是否存在长时间阻塞命令、事务没有结束、批量操作一次占用连接过久，或者应用在高峰期把大量慢查询同时送入池。

对短命令服务，可以用实际并发峰值、P95 命令耗时和可接受排队时间估算容量。例如高峰并发 40、命令 P95 为 8ms，不意味着配置 40 个连接就一定合理；还要给重试、阻塞命令和故障重连留下余量。配置改动后必须重新看 WaitDuration，而不是只看 Redis CPU。

三个容易踩坑的边界

PoolTimeout 不是 ReadTimeout

PoolTimeout 限制“等连接”的时间，ReadTimeout 限制“拿到连接后等响应”的时间。两者都设置得很小，会把慢命令误报成连接池问题；只调大 ReadTimeout，又可能让池槽长期被占用。

池复用不等于每次请求新建连接

命令完成后，连接回到池中继续复用。高峰时看到连接数上升，不代表每个 HTTP 请求都创建了 TCP 连接；要结合池命中、未命中和等待统计判断是否发生了真正的连接扩张。

不要用重试掩盖池耗尽

如果等待超时后立即重试，重试请求会再次进入同一个满池，甚至放大排队。更稳妥的处理是给调用方返回可识别的资源繁忙状态，并降低并发、缩短命令或分离阻塞操作。

一份可以落地的验收清单

• 压测前记录 PoolSize、PoolTimeout、命令 P95 和 Redis maxclients。
• 复现时同时保存 PoolStats 与 CLIENT LIST，确认等待发生在哪一层。
• 调整池大小后，重新验证 WaitCount、WaitDuration、Redis 连接数和业务延迟。
• 为阻塞命令、事务和普通缓存读写划分连接预算，避免一类长操作占满全部槽位。

相关问题

Redis maxclients 很大，为什么 Go 客户端仍然超时？

因为客户端连接池可能先达到自身上限。maxclients 只说明服务端最多接受多少客户端，不能替代客户端的池容量和等待策略。

把 PoolSize 调到很大就能解决吗？

不一定。慢命令、阻塞命令或下游故障会让更大的池同时堆积更多工作，应该先找出连接占用时间和调用并发的来源。

总结

连接池耗尽的判断顺序可以固定为：先看是否在池外等待，再看服务端连接和命令，最后决定是缩短占用、隔离阻塞操作还是调整池容量。只要把 PoolStats、CLIENT LIST 和一段可复现的并发实验放在一起，连接池问题就不会只剩下一条模糊的“超时”日志。