Redis网络丢包导致超时排查方法

Redis延迟飙升却CPU正常，往往并非服务端性能问题，而是网络链路中存在丢包或抖动——一次TCP丢包就会触发重传，导致redis-cli --latency毛刺突增、ping标准差超10ms或丢包率超0.1%；需结合ping/hping3快速定位网络异常，用tcpdump在客户端抓包聚焦retransmission与dup ack，重点排查云环境安全组双向策略、NAT网关会话老化（如ALB 60秒空闲超时）及内核TCP参数（如tcp_retries2过高放大超时感知），真正高效的诊断始于抓住第一个重传时间点，而非依赖表层监控。

redis-cli --latency 测出延迟高但服务端 CPU 正常

这往往不是 Redis 自身问题，而是网络路径存在丢包或抖动。Redis 协议是纯 TCP 同步请求响应，一次丢包就会触发 TCP 重传，直接拉长 redis-cli 的 RTT，表现为 redis-cli --latency 毛刺飙升（比如从 0.2ms 突然跳到 200ms+），但 INFO cpu 显示 used_cpu_sys 和 used_cpu_user 平稳。

实操建议：

• 用 redis-cli --latency -h -p 持续跑 60 秒，观察输出里是否频繁出现 >50ms 的样本——这不是 Redis 处理慢，是中间链路在重传
• 立刻在客户端机器上执行 ping -c 30 ，重点看 packet loss 和 time= 的标准差（std dev）。如果丢包率 >0.1% 或 std dev >10ms，基本可锁定网络层
• 避免只测通断：用 hping3 -S -c 30 -i 0.1 -p 6379 发 SYN 包模拟建连压力，比 ICMP 更贴近 Redis 实际流量特征

tcpdump 抓包发现大量 retransmission 和 dup ack

当 Redis 请求超时伴随 read timeout 或 Connection reset by peer，且 netstat -s | grep -i "retran" 显示重传数突增，说明 TCP 层已持续失败。此时抓包不是为了分析 Redis 协议，而是确认丢包发生位置。

实操建议：

• 在客户端侧抓包：tcpdump -i any host and port 6379 -w redis-loss.pcap，然后用 Wireshark 打开，过滤 tcp.analysis.retransmission || tcp.analysis.duplicate_ack
• 关键看重传间隔：如果重传 RTO 是 200ms 级别（而非毫秒级），说明初始 RTT 估算已被打乱，大概率是中间设备（如防火墙、云厂商 SLB）主动丢弃了部分 ACK 或设置了激进的连接空闲回收
• 不要只抓服务端：客户端抓包才能看到「发出请求后多久才收到响应」，服务端抓包看到的是「收到请求后多久发出响应」，二者差值就是网络耗时

云环境里安全组/ACL/NAT 网关导致连接中断

私有云或混合云中，Redis 超时经常不是物理链路问题，而是策略型丢包。典型现象是：redis-cli -h ping 偶尔成功，但 redis-benchmark -q -n 1000 必现 timeout，且 ss -i 显示连接处于 ESTABLISHED 但 retrans 字段持续增长。

实操建议：

• 检查安全组规则是否允许双向全端口通信：Redis 客户端使用随机高端口（如 42381）连接服务端 6379，服务端响应必须能原路返回，否则中间设备会丢弃“非预期”的回包
• 排查 NAT 网关会话老化时间：AWS ALB 默认空闲超时 60 秒，阿里云 SLB 是 900 秒。若客户端连接复用（如 Jedis 连接池）但长期无请求，连接会被静默中断，下一次请求就卡在 SYN_SENT
• 验证方法：在客户端执行 echo -e "PING\r\n" | nc 6379，连续发 5 次，间隔 70 秒——如果第 5 次失败，基本就是网关清会话

Linux 内核参数影响 TCP 重传行为

即使网络通畅，内核默认配置也可能放大丢包影响。比如 net.ipv4.tcp_retries2 设为 15（默认），意味着最后一次重传后要等约 15 分钟才彻底放弃连接，而应用层早已超时抛异常，造成误判。

实操建议：

• 调低重试次数：sysctl -w net.ipv4.tcp_retries2=6（对应约 1.5 分钟内放弃），避免让应用等待过久；同时配合客户端设置合理的 socketTimeout（如 3–5 秒）
• 启用快速重传：sysctl -w net.ipv4.tcp_sack=1 和 net.ipv4.tcp_fack=1，能让接收方更早通知丢包，减少盲目重传
• 注意容器场景：Docker/K8s Pod 共享宿主机网络命名空间时，sysctl 需在宿主机设置；若用 hostNetwork: true，则 Pod 内修改才生效

真正难定位的不是丢包本身，而是丢包发生在哪一层：可能是物理光纤微断、交换机 buffer 溢出、云厂商底层 vSwitch 限速、甚至 TLS 握手阶段的证书验证超时被误判为网络问题。盯住 tcpdump 里的第一个 retransmission 时间点，比任何监控图表都可靠。

到这里，我们也就讲完了《Redis网络丢包导致超时排查方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！