Redis 连接数突然打满怎么查：maxclients、连接池泄漏与分时恢复

线上接口突然开始报 Redis 连接失败，监控里最先冒出来的不是内存，而是 connected_clients 接近上限。这个时候直接把 maxclients 调大，往往只会把连接泄漏和内存压力往后推。更稳的顺序是先看总量，再抽样连接，确认是业务并发、长时间空闲，还是连接池没有归还。

Redis 连接数打满的排查核心是“总量—明细—来源”三步：用 INFO clients 看整体，用 CLIENT LIST 看连接状态，再回到应用的连接池生命周期。

先确认是 Redis 上限，还是应用自己把连接堆满

在故障节点执行下面两条只读命令，先记录原始输出。connected_clients 是当前客户端连接数，maxclients 是服务端允许的客户端数量；两者接近时才说明“连接上限”是当前瓶颈，不能只凭应用日志里的 timeout 下结论。

redis-cli INFO clients
redis-cli CONFIG GET maxclients

如果 connected_clients 只有几百，而应用连接池已经报满，问题更可能在客户端池的借还、等待队列或网络重连策略。反过来，如果 Redis 端连接数持续增长，才需要继续看连接来源。

用 CLIENT LIST 区分活跃请求和空闲堆积

CLIENT LIST 会列出每条连接的地址、空闲时间和连接类型。不要把一眼看见的某个 IP 当成根因，先按地址和 name 做统计，再抽查 idle 较大的连接。

redis-cli CLIENT LIST

重点看三类迹象：同一应用实例的连接数是否远高于其他实例；大量连接是否长期 idle；连接的 cmd 是否长期为空。正常的连接池也会保留少量空闲连接，所以“有 idle”不是泄漏证据，持续增长和回收不发生才是。

如果应用给连接设置了名字，可以用 CLIENT SETNAME 或客户端库的连接名功能，把服务名和实例编号写进列表，后续故障会比只看 IP 快很多。

连接池泄漏通常发生在归还路径

连接数上涨而请求量没有同步上涨时，优先检查一次借出、一次归还是否成对出现。常见问题是异常分支提前返回，或超时后把连接对象丢掉却没有调用池的 release；重试逻辑还可能在每次失败时新建连接。

conn := pool.Get(ctx)
defer pool.Release(conn)

if err := doQuery(conn); err != nil {
    return err
}
return nil

这里的关键不是照抄 defer，而是确认池实现允许这样归还：有些客户端在获取失败时返回空对象，有些连接发生协议错误后必须先关闭再归还。需要把“借出成功、归还成功、主动关闭、等待超时”分别打指标，单看池大小不够。

恢复时不要把 maxclients 当成止痛药

现场处理可以按风险分三段。第一段限制应用扩容和重连风暴，避免更多实例同时创建连接；第二段只对已经确认来源的异常连接做分时回收，避免误杀正常长连接；第三段再修正连接池最大连接数、空闲回收时间和借还超时。

临时提高 maxclients 只有在文件描述符、内存和应用并发预算都核对过之后才有意义。Redis 官方客户端文档也提醒，连接会消耗查询缓冲、输出缓冲等内存；上限变大不等于系统能承受更多连接。

复查要看“能回落”，不是只看“曾经恢复”

修复后连续观察三个窗口：业务流量回到正常水平时，connected_clients 是否回落；同一实例的连接增长是否停止；连接池等待时间和 Redis 拒绝连接错误是否恢复。若只重启一个实例就暂时正常，不能证明问题已经解决，下一轮流量仍可能重新触发。

常见问题：Redis 连接数排查的几个边界

connected_clients 等于 maxclients 就一定已经拒绝连接吗？

不一定，但已经进入高风险区。还要结合连接创建错误、文件描述符和连接增长趋势判断。

CLIENT LIST 能直接看出哪个连接泄漏吗？

它能提供地址、空闲时间和命令等证据，最终仍需和应用实例、连接池借还指标关联，不能只凭一条记录定性。

重启应用为什么能暂时解决？

重启会关闭该实例持有的连接，所以总量可能回落；如果归还路径或重连策略没修，流量恢复后仍会再次堆积。

什么时候才适合调大 maxclients？

只有在连接确实代表合理并发，并且文件描述符、内存和客户端池预算都已验证时，调大上限才是容量调整，而不是掩盖泄漏。

最后的验收清单

• 保存 INFO clients、CONFIG GET maxclients 和抽样后的 CLIENT LIST。
• 把连接按实例、地址、类型和 idle 时长分组，确认增长来源。
• 修复连接池归还与回收后，验证连接数能随流量下降。