Redis 连接池偶发超时怎么查：命令耗时、连接数与慢日志的对应关系

线上接口偶尔卡在 Redis 调用上，最容易出现的误判是“Redis 变慢了”，然后直接把连接超时从 500 毫秒改成 3 秒。这个动作可能只是把连接池排队、网络抖动或单条慢命令藏得更深。更稳的做法是把一次 Redis 调用拆成三段：客户端从池里拿连接、Redis 执行命令、客户端读回响应，分别找证据。

先把一次 Redis 超时拆成三段

连接池超时通常发生在客户端拿不到可用连接时；命令超时发生在 Redis 执行或排队过程中；读响应超时则更接近网络、代理或客户端事件循环问题。三者在应用日志里可能都只显示一个“timeout”，所以第一步不是改参数，而是补齐阶段信息。

如果应用只记录了总耗时，先在客户端埋点记录“借连接前、拿到连接、发出命令、收到响应、归还连接”五个时间点。没有这组时间，服务端命令慢和连接池排队很难区分。

第一轮先看 INFO clients 和连接池指标

Redis 的 INFO 可以按 section 查询，INFO clients 适合先看服务端当前连接概况。重点关注 connected_clients、blocked_clients 和 maxclients，并和应用连接池的 active、idle、waiters 对照。

redis-cli INFO clients
redis-cli INFO stats
redis-cli CONFIG GET maxclients

connected_clients 接近上限，说明连接资源紧张，但它不能直接证明某个应用池已经耗尽；如果 Redis 连接数平稳而应用 waiters 突然上升，优先查池大小、连接归还和单请求是否持有连接过久。

• 池等待时间上升、命令耗时正常：先查池容量、连接泄漏和并发突刺。
• 连接数上升、命令耗时也上升：继续看慢日志、CPU 和阻塞命令。
• 两者都正常但读响应慢：查网络路径、代理空闲连接策略和客户端线程调度。

用 CLIENT LIST 找出异常连接形态

CLIENT LIST 返回连接级明细，适合发现连接长期空闲、订阅连接混入普通池，或者某类客户端数量异常。不要把整段输出直接打进业务日志；排查时只保留 addr、age、idle、flags、db、cmd 等必要字段，并对地址做脱敏。

redis-cli CLIENT LIST
# 重点观察：age、idle、flags、cmd、db

某条连接的 idle 很大不一定是故障，连接池本来就会保留空闲连接。真正值得关注的是：空闲连接数持续增长、业务请求却在等待，或者 cmd 长时间停留在订阅/阻塞类操作。Pub/Sub 连接应使用独立连接，不要和普通命令池混用。

再用 SLOWLOG 对照命令执行时间

Redis Slow Log 记录超过 slowlog-log-slower-than 阈值的命令。它只计算命令执行阶段，不包括和客户端通信的 I/O，因此 SLOWLOG GET 没有记录时，仍可能存在网络慢或连接池等待。

redis-cli CONFIG GET slowlog-log-slower-than
redis-cli SLOWLOG GET 20

拿到慢日志后，先看命令类型、参数规模和持续时间，再回到业务请求找对应接口。不要在生产环境里为了“证明有慢命令”随意把阈值改得过低；阈值、日志长度和清理动作都应经过变更记录。对大范围 key 扫描、一次取回过多成员等场景，优先拆分请求和限制返回量。

一个可复用的判断顺序

1. 先查应用侧 pool wait、active、idle、总耗时和命令耗时，确认超时卡在哪一段。
2. 查 INFO clients，确认服务端连接数、阻塞客户端和上限关系。
3. 查 CLIENT LIST，识别长期空闲、订阅或阻塞连接是否误入普通池。
4. 查 SLOWLOG GET，把命令执行耗时与应用请求时间线对齐。
5. 按证据修复：调池配置、拆分命令、隔离连接类型或处理网络路径，最后再调整超时。

这里别急着把所有超时都重试。连接池耗尽时重试会继续争抢连接，慢命令重试还可能放大 Redis 的负载。只有明确是可恢复的网络瞬断，并且请求具备幂等性，才考虑有限次数的退避重试。

修复后怎样验收才算真的恢复

至少保留一段和故障前可比较的观察窗口，分别记录超时率、P95/P99 总耗时、pool wait P95、命令执行 P95、connected_clients 和慢日志新增量。平均耗时恢复并不代表尾延迟恢复，连接池等待也可能只在高峰出现。

• 连接池 wait 接近零，active 没有长期打满。
• Redis 命令耗时和慢日志新增量回到业务基线。
• 连接总数稳定，没有异常空闲连接持续累积。
• 超时率下降后，重试量没有把流量再次推高。

常见问题

慢日志为空，能说明 Redis 没有变慢吗？

不能。慢日志只覆盖命令执行阶段，不包含网络 I/O、客户端排队和连接池等待。还要对照应用分段耗时与连接指标。

connected_clients 很高就一定要增大 maxclients 吗？

不一定。先确认连接是否来自预期服务、是否有连接泄漏和错误复用。盲目提高上限可能把资源压力推迟到文件描述符或内存层。

连接池超时时，增加重试次数有用吗？

通常没有。池已耗尽时重试会继续排队，应该先确认池容量、连接归还和单请求持有时长，再决定是否对特定网络错误做有限重试。

CLIENT LIST 可以长期全量采集吗？

不建议。它是排查工具，输出包含地址和连接明细。按需采集脱敏字段，并控制频率与留存范围。

Redis 连接池偶发超时的定位重点，是把“总耗时”还原成连接、命令和响应三个阶段。INFO clients 看总量，CLIENT LIST 看连接形态，SLOWLOG 看命令执行证据，三者和客户端分段指标对齐后，再做配置或代码调整，误判会少很多。