Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli --latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。
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 <host> -p <port></port></host>持续跑 60 秒，观察输出里是否频繁出现 >50ms 的样本——这不是 Redis 处理慢，是中间链路在重传 - 立刻在客户端机器上执行
ping -c 30 <redis-server-ip></redis-server-ip>，重点看packet loss和time=的标准差（std dev）。如果丢包率 >0.1% 或 std dev >10ms，基本可锁定网络层 - 避免只测通断：用
hping3 -S -c 30 -i 0.1 <redis-server-ip> -p 6379</redis-server-ip>发 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 <redis-server-ip> and port 6379 -w redis-loss.pcap</redis-server-ip>，然后用 Wireshark 打开，过滤tcp.analysis.retransmission || tcp.analysis.duplicate_ack - 关键看重传间隔：如果重传 RTO 是 200ms 级别（而非毫秒级），说明初始 RTT 估算已被打乱，大概率是中间设备（如防火墙、云厂商 SLB）主动丢弃了部分 ACK 或设置了激进的连接空闲回收
- 不要只抓服务端：客户端抓包才能看到「发出请求后多久才收到响应」，服务端抓包看到的是「收到请求后多久发出响应」，二者差值就是网络耗时
云环境里安全组/ACL/NAT 网关导致连接中断
私有云或混合云中，Redis 超时经常不是物理链路问题，而是策略型丢包。典型现象是：redis-cli -h <ip> ping</ip> 偶尔成功，但 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 <redis-ip> 6379</redis-ip>，连续发 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 时间点，比任何监控图表都可靠。
