Redis tcp-keepalive 和 timeout 有什么区别

如果 Redis 连接偶尔“看起来还在”，但中间的负载均衡器、NAT 或防火墙已经把它清掉，优先关注的是 tcp-keepalive；如果 Redis 进程里积累了大量长期不用的普通客户端，才需要评估 timeout。两者都和连接有关，但一个工作在 TCP socket 层，另一个是 Redis 服务对客户端空闲状态的回收策略。

简单记忆：tcp-keepalive 用探测流量发现或维持网络对端，timeout 用 Redis 的空闲计时关闭普通客户端。它们不是同一个“连接超时”，也不能互相替代。

官方地址：https://redis.io/docs/latest/develop/reference/clients/

本文只比较 TCP 保活探测与 Redis 空闲客户端超时，不讨论连接池实现，也不把客户端库自己的读写超时混进来。Redis 官方文档说明，timeout 默认可以不关闭长期空闲的普通连接，而 TCP keepalive 从 Redis 3.2 起默认启用，约为 300 秒。

两个参数分别处在哪一层

tcp-keepalive 对应 TCP 的 SO_KEEPALIVE。当连接长时间没有业务数据时，操作系统会根据这个参数安排保活探测，用来发现已经不可达的对端，也让路径中的网络设备看到连接仍有流量。它解决的是“连接在网络层是否仍然可达”以及“中间设备是否把完全空闲的连接回收”的问题。

timeout 则是 Redis 服务器侧的客户端空闲策略：普通客户端超过指定秒数没有活动，Redis 可以主动关闭它。它解决的是“Redis 是否要继续保留一个长期不用的普通客户端”，并不负责证明远端网络一定可达。

tcp-keepalive 适合处理哪些症状

典型场景是客户端进程已经退出、主机断电、链路中断，或者连接经过的网络设备只允许连接空闲一段时间。应用侧可能仍然保存着一个 socket 对象，但这个对象并不能说明对端还活着。启用 TCP 保活后，系统会在无业务通信时发起探测；如果对端持续没有响应，连接最终会被判定为失败。

这里的时间不是“设置多少秒就一定关闭”。Redis 官方示例配置指出，在 Linux 上该值是发送 ACK 探测的周期，真正关闭连接通常还需要更长时间；其他内核的具体行为还会受系统 TCP 配置影响。因此不要把 tcp-keepalive 300 理解成精确的 300 秒断开开关。

# 非零值启用 TCP 保活探测，单位为秒；实际判死时间还受操作系统影响。
tcp-keepalive 300

# 0 表示不启用 Redis 的普通客户端空闲关闭策略。
timeout 0

如果问题是“连接穿过云负载均衡器后长时间无请求，下一次复用时报连接已断开”，应先确认客户端 socket 是否启用了 keepalive、网络设备的空闲回收时间以及操作系统的探测参数。只把 Redis 的 timeout 调大，并不能让中间设备保留这条 TCP 连接。

timeout 适合处理哪些症状

Redis 官方文档把 timeout 定义为客户端空闲超过指定秒数后关闭连接，而且它只适用于普通客户端，不适用于 Pub/Sub 客户端。Pub/Sub 的空闲是正常状态：客户端可能正在等待服务端推送消息，不能因为没有普通命令就把它当成泄漏连接。

另一个容易忽略的边界是精度。Redis 不会为每个客户端都设置精确的独立定时器，也不会每次检查都遍历全部连接，所以空闲达到配置值后不一定立刻断开。例如设置为 10 秒，实际关闭可能略晚于 10 秒。它适合控制连接堆积，不适合当作毫秒级业务计时器。

# 查看当前 Redis 服务端的两个配置值。
redis-cli CONFIG GET tcp-keepalive timeout

# 只对普通客户端设置 600 秒空闲回收；Pub/Sub 不受该参数直接关闭。
redis-cli CONFIG SET timeout 600

如果你的应用使用普通请求连接，并且连接泄漏会把 maxclients 或文件描述符耗尽，timeout 可以作为保护措施。但它可能关闭那些只是暂时没有命令、之后还会复用的长连接，所以应结合客户端重连策略和业务空闲窗口来设定。

用 CLIENT LIST 区分 idle 和客户端类型

调整参数前，先看 Redis 眼中的连接状态。CLIENT LIST 会返回每条连接的 age、idle、flags 和最近执行的 cmd 等字段。idle 很大只能说明这条连接近期没有命令活动，不能单独证明网络已经半开；需要把它和客户端类型、应用日志以及网络设备策略一起判断。

# 查看连接类型、空闲秒数和最近命令，先定位是否是普通客户端堆积。
redis-cli CLIENT LIST

# 只筛选普通客户端的示例输出；真实字段会随 Redis 版本和连接状态变化。
redis-cli CLIENT LIST | grep 'flags=N'

通常可以按下面的方式做判断：

运行时修改后为什么还要处理配置文件

CONFIG SET 可以在 Redis 运行中改变支持动态修改的配置，但这种改变只在当前进程内生效，并不会自动修改 redis.conf。Redis 重启后，如果没有同步持久化文件，旧值仍可能被重新加载。

# 运行时先调整配置，便于观察当前实例的行为。
redis-cli CONFIG SET tcp-keepalive 120
redis-cli CONFIG SET timeout 600

# 将当前与默认值不同的配置写回配置文件；生产环境先确认文件权限和挂载方式。
redis-cli CONFIG REWRITE

# 重新读取两个值，确认当前进程看到的配置。
redis-cli CONFIG GET tcp-keepalive timeout

如果实例使用容器只读配置、托管 Redis 或外部配置管理系统，不要把 CONFIG REWRITE 当作唯一落盘方案。应按部署方式修改真正的配置源；同时记录修改前后的值，避免临时试验值被误当成长期基线。

云上部署的选择清单

普通请求连接和 Pub/Sub 长连接最好分开考虑。普通请求连接可以使用 TCP keepalive 来减少网络路径上的“静默失联”，再根据连接泄漏风险评估 Redis timeout；Pub/Sub 需要保持等待推送，不能仅因为 idle 较大就按普通客户端清理。

落地时可以按这份清单检查：

• 先确认问题发生在网络设备空闲回收、对端失联，还是 Redis 客户端数量失控。
• 半开连接优先检查 TCP keepalive、操作系统参数和网络设备空闲策略。
• 普通客户端长期堆积时，再结合 CLIENT LIST 的 idle 与应用释放逻辑设置 timeout。
• 不要用 Redis timeout 清理 Pub/Sub 等待连接。
• 用 CONFIG SET 做临时调整后，按部署方式更新配置文件或执行 CONFIG REWRITE。

常见问题

tcp-keepalive 设置为 300，300 秒后一定断开吗？ 不一定。它是 TCP 保活探测周期，最终判死还取决于操作系统和探测失败次数，Linux 与其他内核的行为也可能不同。

timeout 能检测半开连接吗？ 它主要看 Redis 记录的客户端空闲时间，不能替代 TCP 层探测。半开连接应先从 socket、系统和网络路径排查。

为什么设置了 timeout，Pub/Sub 连接仍然不被关闭？ 这是预期行为。Redis 文档明确说明该配置只适用于普通客户端，Pub/Sub 的空闲等待本身就是正常状态。

只运行 CONFIG SET 可以吗？ 可以用于当前进程的临时调整，但重启后不一定保留；需要按部署方式修改配置源，或在适用时执行 CONFIG REWRITE。