Redis 连接池耗尽时怎么区分慢命令和连接泄漏

Redis 连接池耗尽时，报错位置通常是客户端的等待阶段，但根因不一定是“池太小”。慢命令会让已经拿到连接的请求迟迟不结束，业务代码未关闭 PubSub、事务或手工连接，也会让可用连接持续减少。排查时要同时看三件事：请求拿连接等了多久、命令发出后执行了多久、Redis 服务端是否真的把命令记进慢日志。

如果 go-redis 的 PoolStats().Timeouts 和等待指标上升，而 Redis SLOWLOG GET 没有对应命令，优先检查客户端等待和资源归还；只有慢日志、Redis CPU 或命令统计同时异常时，才把慢命令作为主因。

Redis 连接池耗尽时先看等待链路，不要急着改池大小

把一次请求画成一条数据链路：业务协程进入客户端，等待池分配连接，连接写入命令并读取响应，最后由客户端把连接放回池中。任何一段变长，接口都可能表现为“Redis 慢”。

最容易混淆的是两个超时：PoolTimeout 是所有连接忙时，客户端等待可用连接的上限；ReadTimeout 更接近拿到连接后等待 socket 响应的上限。在 go-redis 中，池统计是累计值，因此要保存前后两个快照，用增量判断当前窗口，而不能只看一次绝对数字。

用 PoolStats 把池等待和命令执行拆开

下面的探针不需要改 Redis 服务端，只记录一次命令前后的池统计和总耗时。生产环境可以把这些字段按接口、命令类型和实例标签上报，但不要把完整 key 或用户数据写进日志。

// 记录一次请求窗口，区分池等待增长和命令总耗时。
before := client.PoolStats()
started := time.Now()
err := client.Get(ctx, "profile:"+userID).Err()
elapsed := time.Since(started)
after := client.PoolStats()

// PoolStats 是累计快照，前后相减才代表本次观察窗口的变化。
fmt.Printf("redis_get elapsed=%s wait_delta=%d timeout_delta=%d total=%d idle=%d err=%v\n",
    elapsed,
    after.WaitCount-before.WaitCount,
    after.Timeouts-before.Timeouts,
    after.TotalConns,
    after.IdleConns,
    err,
)

如果 elapsed 变长、Timeouts 同步增加，且 IdleConns 长时间接近 0，说明请求可能在池门口排队。若流量下降后 TotalConns 仍接近上限、IdleConns 仍异常偏低，则要沿着长耗时 handler、阻塞命令、PubSub 和事务生命周期找“谁还占着连接”。这只是强信号，不是单凭一个快照就能证明泄漏。

用 Redis 慢日志确认服务端是否真的慢

Redis 官方说明中，慢日志记录的是命令执行时间，不包含和客户端通信的 I/O 时间。因此它特别适合和应用侧的总耗时对照。可以先读取最近记录，再根据权限和环境决定是否调整阈值：

# 只读取最近的慢命令，避免把诊断命令写成生产扫描。
redis-cli SLOWLOG GET 32

# 查看命令调用次数、失败次数和平均 CPU 时间。
redis-cli INFO commandstats

若应用一次 GET 记录了很长的总耗时，但慢日志没有相同时间段的记录，优先怀疑池等待、网络路径或客户端线程调度。若出现大集合上的 KEYS、HGETALL、SORT 等高成本操作，应该先改访问方式，例如使用分页或增量扫描，而不是单纯把 PoolTimeout 调大。

先修复归还连接，再调整超时和池容量

普通的 client.Get、Set 等高层调用由客户端管理连接；风险通常出现在更长生命周期的对象或自定义流程中。重点检查以下路径：

• 创建的 PubSub 是否在退出、取消或错误分支关闭。
• 事务、Pipeline 或阻塞命令是否有明确的上下文截止时间。
• 直接拿到的连接是否覆盖了成功、失败、超时和提前返回的归还路径。
• 是否在每个请求里重复创建 Redis client，导致连接数和池统计被多个实例分散。

确认生命周期没有问题后，再按业务并发设置 PoolSize，给 PoolTimeout 和 ReadTimeout 设置可解释的预算。池容量不是越大越好：连接更多会增加 Redis 服务端、客户端内存和调度压力；池太小则会让短时突发更早排队。每次调整都要同时观察超时次数、平均等待、Redis 命令耗时和错误率。

常见问题

PoolTimeout 增加是不是说明 Redis 已经挂了？

不是。它首先说明客户端在规定时间内没有拿到可用连接，可能是慢命令、并发突发、连接泄漏或池参数过小。要用 SLOWLOG 和 PoolStats 再分层判断。

把 PoolSize 调大能解决连接泄漏吗？

不能。它最多延后耗尽时刻，还可能把更多并发压力推给 Redis。只有在归还路径正常、监控显示确实是合法突发时，扩容才是合理的容量调整。

为什么应用很慢但 SLOWLOG 没有记录？

因为慢日志只覆盖 Redis 执行阶段，不覆盖客户端池等待、网络 I/O 和业务处理。此时应比较命令总耗时与池等待增量，并检查上下文和网络指标。

参考：Redis 连接池与多路复用文档、SLOWLOG 命令文档、go-redis Options 与连接池参数。