必须从TCP层面验证丢包：用redis-cli --intrinsic-latency 5检测真实抖动，结合tcpdump抓包分析重传与SACK，再用mtr定位链路丢包点，三者缺一不可。
Redis主从复制丢包不能只看 ping，必须从 TCP 层面验证。 ICMP 的 ping 延迟稳定不代表 Redis 复制流量（TCP 6379）不丢包——很多生产环境的丢包就藏在防火墙限速、交换机微突发或中间 QoS 策略里。
用 redis-cli --intrinsic-latency 验证真实复制链路抖动
这是最贴近 Redis 复制行为的检测方式：它模拟主从间的心跳包走的是同一 TCP 连接、同一端口、同一路径。
- 在从节点执行：
redis-cli -h <master-ip> --intrinsic-latency 5，观察是否出现timeout或抖动 > 50ms - 如果持续 timeout，但
ping -c 10 <master-ip>延迟稳定在 1~2ms，基本可断定是 6379 端口被限速或中间设备丢包 - 注意：该命令需在从节点机器上运行，且主节点 Redis 必须处于可连通状态；若返回
Could not connect to Redis at...，先排查网络连通性或防火墙
抓包分析重传与 SACK 行为
TCP 层的重传、重复 ACK、SACK 缺失是丢包的直接证据，比任何监控指标都可靠。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在主、从节点**同时**执行：
tcpdump -i any port 6379 -w redis-repl.pcap，复现一次延迟升高或同步卡顿 - 用 Wireshark 打开 pcap 文件，过滤
tcp.analysis.retransmission || tcp.analysis.duplicate_ack - 重点关注：
TCP Retransmission出现频率、SACK是否被频繁使用、TCP Window Full是否持续触发——三者任一频繁出现，都是丢包或接收方处理不过来的信号
检查系统级 TCP 重传统计与网卡丢包
内核层面的统计能绕过应用层干扰，快速定位是否真有丢包发生。
- 查重传段数是否上升：
cat /proc/net/snmp | grep Tcp | awk '{print $12}'（对应TcpRetransSegs），连续两次采样差值 > 100 就值得警惕 - 查网卡收发丢包：
ethtool -S eth0 | grep -i "drop\|over\|error"，特别关注rx_dropped和tx_dropped，非零即风险 - 查当前连接缓冲区状态：
ss -i | grep :6379，看rcv_space是否长期接近 0（说明从节点 TCP 接收窗口已满，主节点发不出去）
用 mtr 定位链路中哪一跳丢包
当确认丢包存在，但不确定发生在哪一环时，mtr 比 traceroute 更有效——它基于 ICMP 或 TCP，能暴露每一跳的丢包率和延迟跳变。
- 在主节点执行：
mtr --tcp -P 6379 <slave-ip>（务必加--tcp -P 6379，否则默认走 ICMP） - 重点看哪一跳的 Loss% > 0.5%，或 Avg 延迟突然跳升 > 20ms；云环境尤其注意宿主机网卡、VPC 网关、安全组限速策略
- 若最后一跳（即从节点所在机器）丢包率高，但本机
ss -i显示正常，则问题大概率出在从节点内核 net.core.rmem_max 设置过小，或 CPU 被打满导致协议栈来不及处理
真正难排查的丢包，往往不是全链路中断，而是间歇性、低概率、只影响大包或特定时间窗口的微突发。这类问题不会让 INFO replication 明显报错，却会让 lag 慢慢爬升、master_last_io_seconds_ago 偶尔超 1 秒——必须用 tcpdump + mtr + /proc/net/snmp 三角印证，缺一不可。
