Redis主从心跳验证及REPLCONF机制解析

Redis主从心跳并非依赖TCP底层保活，而是通过应用层的PING命令与REPLCONF ACK指令协同实现：主库每秒发送PING（可配置），从库必须立即响应ACK并携带当前复制偏移量；一旦主库在repl-timeout（默认60秒）内未收到ACK，便判定该从库为down——这并非网络中断所致，而是因从库忙于阻塞操作、RDB快照或处理延迟导致响应超时；通过INFO replication中slaveX:state、lag及master_last_io_seconds_ago等关键指标，可精准区分是心跳失联还是单纯同步滞后，帮助运维快速定位真实瓶颈。

Redis主从心跳靠什么维持

主从心跳不是靠TCP保活，而是靠应用层的 PING 和 REPLCONF ACK 两个命令来回完成。主库每秒向从库发一次 PING（可配置间隔），从库收到后必须立即回一个 REPLCONF ACK ，其中 offset 是它当前复制到的主库偏移量。

为什么从库没回ACK会导致主库标记为“down”

主库会记录每个从库最近一次收到 REPLCONF ACK 的时间。如果超过 repl-timeout（默认60秒）没收到，主库就把该从库状态设为 down，并在 INFO replication 中显示 slaveX:state=down。这不是网络断了才触发，而是“没按时回ACK”就判故障。

• repl-timeout 只控制主库对从库的超时判断，不影响 PING 发送频率（那是 repl-ping-replica-period，默认10秒）
• 从库即使网络通畅，但忙于执行阻塞命令（如 KEYS *、大 LRANGE）、或正在做RDB快照，也可能延迟回ACK
• 主库不会重试发 PING，只等下一轮定时发送；所以单次丢包不致命，持续延迟才危险

怎么确认是心跳问题而不是同步卡住

看 INFO replication 输出里关键字段比对：

• 主库上查从库条目：找 slaveX:offset= 对应的 lag= 值 —— 如果 lag 持续增长且 state=online，说明数据还在追，只是慢；如果 state=down，基本就是心跳断了
• 从库上查 master_link_status:up 且 master_last_io_seconds_ago: 才算心跳正常；这个值大于 repl-timeout 就已失联
• 注意 master_repl_offset（主库当前偏移）和从库的 slave_repl_offset 差值，不能只看这个差值大不大 —— 差值大但 lag 稳定，可能是网络带宽瓶颈；差值不变但 lag 持续涨，才是心跳异常信号

常见误判场景和调优建议