应通过TCP层面检测主从延迟与丢包，而非仅依赖ping；需结合tcpdump/Wireshark分析重传、SACK等，用mtr定位链路问题，限制复制带宽并排查磁盘I/O瓶颈，合理设置repl-timeout与repl-ping-slave-period避免误判。
怎么看主从节点间真实网络延迟和丢包
别只信 ping，它用的是 ICMP，而 Redis 复制走的是 TCP，两者路径、QoS 策略、中间设备处理方式都可能不同。真正影响同步的是主从之间 TCP 连接的 RTT 和重传行为。
- 用
redis-cli -h <master-ip> -p 6379 --slaveof <slave-ip> 6379</slave-ip></master-ip>启动临时从节点，再观察INFO replication中的master_last_io_seconds_ago是否持续 > 1 —— 这说明心跳或数据包卡在链路上 - 在主从节点上同时跑
tcpdump -i any port 6379 -w redis-repl.pcap，用 Wireshark 检查是否存在大量重复 ACK、SACK、重传（Retransmission）或 TCP Window Full - 运行
mtr --tcp -P 6379 <slave-ip></slave-ip>（主节点执行），看哪一跳出现明显延迟跳变或丢包率 > 0.5%
带宽打满时复制怎么不被挤爆
Redis 复制是单线程 TCP 流，一旦网卡或交换机队列拥塞，所有复制数据都会排队，repl-backlog 很快被冲掉，触发全量重同步 —— 这才是延迟飙升的真正拐点。
- 检查网卡实际吞吐：
iftop -P 6379或ss -i | grep :6379查看ts sack字段是否频繁变化，以及rcv_space是否长期接近 0 - 限制复制流量：在主节点所在宿主机启用 tc 限速，例如
tc qdisc add dev eth0 root tbf rate 80mbit burst 32kbit latency 400ms，避免复制流吃光带宽导致其他业务抖动 - 确认交换机无微突发（microburst）：某些白牌交换机 buffer 小，短时突发就丢包，用
ethtool -S eth0 | grep -i "drop\|over"查 rx/tx_dropped，非零即风险
repl-timeout 和 repl-ping-slave-period 怎么设才不翻车
这两个参数看着简单，但设错会直接导致“假断连”——从节点明明活着，主节点却误判为失联，反复发起全量同步。
-
repl-ping-slave-period不建议低于 5 秒：太小会增加主节点 CPU 和网络开销；高于 10 秒则故障发现慢。生产环境推荐8 -
repl-timeout必须 >repl-ping-slave-period × 2 + 网络 P99 RTT：比如 ping 间隔 8 秒、P99 RTT 是 120ms，那至少设为15（单位秒），否则一次瞬时抖动就触发 failover - 切记：修改后需
CONFIG REWRITE持久化，且重启前先CONFIG GET核对，避免配置热加载失败却以为生效了
磁盘 I/O 慢也会拖累复制进度
很多人只盯着网络，忽略了从节点本地磁盘写入速度 —— 特别是开启 AOF + appendfsync everysec 时，如果磁盘响应慢，从节点应用复制命令的速度就会卡住，master_repl_offset 和 slave_repl_offset 差值越拉越大。
- 检查从节点磁盘延迟：
iostat -x 1关注%util> 90 或await> 20ms - 临时验证：停掉从节点 AOF（
CONFIG SET appendonly no），观察lag是否快速收敛；若明显改善，说明是磁盘瓶颈 - 长期方案：AOF 放 SSD，RDB 文件路径与 AOF 分离（避免同一磁盘争抢），或改用
no-appendfsync-on-rewrite yes配合appendfsync no（接受最多 30 秒数据丢失）
repl-timeout 设低了 2 秒，加上某次磁盘 fsync 延迟突增，就可能让集群在凌晨三点自动切主 —— 而你根本没收到告警。 
