超时参数要成对看
业务到 Redis 之间常隔着负载均衡器或四层代理，LB 有自己的空闲超时：连接在这段时间内没有数据往返就被静默断开，而两端不一定立刻察觉。如果连接池的保活间隔长于 LB 空闲超时，池里会攒下一批已被断开的连接，业务取到它们时才会失败。协同原则是保活或心跳间隔明显小于 LB 空闲超时，并留出余量应对抖动。
基本信息
| 主要风险 | 空闲连接被 LB 静默回收，池中留下死连接 |
|---|---|
| 协同原则 | 保活间隔小于 LB 空闲超时，通常取三分之一到一半 |
| 服务端参数 | tcp-keepalive 控制服务端对空闲对端的探测 |
| 客户端参数 | 连接池保活间隔与最大空闲时间 |
| 兜底手段 | 取用前健康检查 + 幂等请求重试 |
典型使用场景
- 接入四层 LB 或云负载均衡：空闲超时是平台默认值，业务侧常常不知情
- 低峰时段：夜间几乎无流量，最容易触发静默断连
- 故障恢复：切换后旧池连接全部失效，需要快速淘汰重建
- 偶发重置排查：把失败请求与空闲时长对照，验证是否与超时错配吻合
- 容量评估：连接被批量回收后集中重建，会形成二次压力
对齐与核查
对齐与核查
redis-cli CLIENT LIST # 看连接的空闲时长与年龄分布
redis-cli CONFIG GET tcp-keepalive # 服务端侧的空闲探测间隔
redis-cli INFO clients | grep connected_clients # 连接数是否出现规律性掉落
# 客户端侧示例：保活 30 秒，LB 空闲超时 120 秒，留出足够余量
# pool: keepalive=30s, idle_timeout=120s, acquire_timeout=200ms参数对齐表
| 参数 | 所处位置 | 设置思路 |
|---|---|---|
| LB 空闲超时 | 负载均衡器或四层代理 | 先查清平台默认值，不要假设无限 |
| 连接保活间隔 | 客户端连接池 | 取 LB 超时的三分之一到一半 |
| tcp-keepalive | Redis 服务端配置 | 负责服务端向空闲对端发起探测 |
| 获取连接超时 | 客户端连接池 | 短于业务总超时，便于快速失败 |
超时错配的典型症状是「日常正常，闲置一段时间后第一批请求报错，随后自行恢复」——因为只有空闲足够久的连接才会被回收，忙时根本看不出来。
参数分散在 LB、客户端池与服务端三处，改一处必须同步核查另外两处。只把客户端保活调好、LB 超时更短，问题依然照旧。