Redis主从心跳由应用层PING和REPLCONF ACK命令维持，主库每秒发PING，从库需立即回ACK；若超repl-timeout（默认60秒）未收到ACK，主库即标记该从库为down。
Redis主从心跳靠什么维持
主从心跳不是靠TCP保活，而是靠应用层的 PING 和 REPLCONF ACK 两个命令来回完成。主库每秒向从库发一次 PING（可配置间隔），从库收到后必须立即回一个 REPLCONF ACK <offset></offset>，其中 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> 才算心跳正常；这个值大于 <code>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晚几秒——而这几秒，足够主库判定从库“不可用”。
