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 必须协同调整；单独开一个而忽略另一个，大概率会看到“连接看似正常，复制却卡死”的诡异现象。 
