redis默认tcp-keepalive关闭（值为0），需主从双方redis.conf显式配置tcp-keepalive 300并重启生效，且须与repl-timeout≥300协同调整，否则连接假活导致复制卡死。

Redis主从复制时从节点突然断连，为什么tcp-keepalive没起作用？

根本原因是 Redis 默认的 tcp-keepalive 配置是关闭的（值为 0），即使你启用了系统级 TCP keepalive，Redis 自身不会主动发起探测包。主从之间长连接空闲时，中间网络设备（如 NAT、防火墙）可能静默丢弃连接，但从节点仍认为自己连着，导致复制中断后无法自动重连或上报错误。

• tcp-keepalive 是 Redis 进程内控制的 socket 级保活机制，和 Linux 内核的 net.ipv4.tcp_keepalive_* 参数无关
• 必须在主节点和从节点的 redis.conf 中都显式配置，仅配一端无效
• 典型误配：设成 tcp-keepalive 60，但没意识到这是“空闲多少秒后开始发第一个探测包”，不是“每 60 秒发一次”

如何正确配置tcp-keepalive参数并验证生效？

推荐配置值：tcp-keepalive 300（即空闲 5 分钟后开始探测，后续每 60 秒探一次，3 次失败断连）。这个值兼顾及时性与低开销，避免过短引发大量无谓探测包。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 修改主从双方的 redis.conf，添加或取消注释：

  tcp-keepalive 300

• 重启 Redis 实例（热重载不支持该配置，CONFIG SET 会报错）
• 验证是否生效：redis-cli CONFIG GET tcp-keepalive 返回 ["tcp-keepalive","300"]
• 确认 socket 层已启用：在 Redis 进程上执行 ss -tnp | grep :6379，看对应连接的 timer 列是否显示 keepalive

客户端断连后复制恢复失败？检查repl-timeout和repl-ping-replica-period

tcp-keepalive 只解决“连接是否存活”，不解决“复制是否卡住”。如果从节点因网络抖动短暂失联，但主节点还没触发超时判定，就会出现“TCP 连接还通，复制数据却停了”的假象。

• repl-timeout 60：主节点等待从节点 ACK 或 PING 的最大秒数，超时即断开复制连接（注意：此值应 ≥ tcp-keepalive 探测周期，否则可能被误杀）
• repl-ping-replica-period 10：主节点每 10 秒向从节点发一次 REPLCONF ACK，用于检测复制延迟；若从节点连续 repl-timeout 秒未响应，主节点才真正断开
• 从节点侧也要关注 repl-backlog-ttl，防止断连太久导致增量同步失败，被迫全量重同步

用redis-cli --stat和INFO replication定位真实断连点

别只盯着日志里的 “Connection refused” —— 很多时候连接是“软断”，TCP 状态还是 ESTABLISHED，但复制偏移量停滞不动。

• 在主节点运行：redis-cli INFO replication | grep -E "(role|master_repl_offset|connected_slaves)"，观察 master_repl_offset 是否持续增长
• 在从节点运行：redis-cli INFO replication | grep -E "(role|slave_repl_offset|master_host|master_link_status)"，重点看 master_link_status:up 是否为 down，以及 slave_repl_offset 是否追平 master_repl_offset
• 实时监控连接状态：redis-cli --stat 查看 clients、master_link_down_since_seconds 等指标变化

实际环境中，tcp-keepalive 和 repl-timeout 必须协同调整；单独开一个而忽略另一个，大概率会看到“连接看似正常，复制却卡死”的诡异现象。