Redis如何诊断网络丢包引发的请求超时-Redis-PHP中文网

Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli --latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。

redis如何诊断网络丢包引发的请求超时

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 时间点，比任何监控图表都可靠。