Redis主从心跳由应用层PING和REPLCONF ACK命令维持，主库每秒发PING，从库需立即回ACK；若超repl-timeout（默认60秒）未收到ACK，主库即标记该从库为down。

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 持续涨，才是心跳异常信号

常见误判场景和调优建议

运维常把 timeout 调太大来“避免误报”，结果掩盖真实问题。真正该做的是定位为什么ACK回得慢：

• 检查从库 redis-cli --latency 是否有毛刺；高延迟往往伴随ACK延迟
• 确认从库没在做 SAVE 或 BGSAVE —— RDB fork期间可能卡住事件循环，导致ACK积压
• 避免在从库执行 SLOWLOG GET、DEBUG SLEEP 这类阻塞操作；它们会让整个事件循环停顿
• 若从库负载长期偏高，考虑降低 repl-ping-replica-period（比如设为5秒），让主库更早感知异常，但别小于2秒，否则增加无效流量

心跳机制本身很简单，但它的表现高度依赖从库的响应及时性。网络通 ≠ 心跳健康，CPU跑满、磁盘IO堵住、甚至一次大key遍历，都可能让ACK晚几秒——而这几秒，足够主库判定从库“不可用”。