如何通过分析 Keepalived 切换瞬间的 TCP 重传率调优双机热备链路-Nginx-PHP中文网

keepalived切换瞬间tcp重传率升高本质是vip漂移导致连接中断引发的客户端重试，需结合抓包、日志、arp验证及配置优化（如降低advert_int、启用preempt、禁用gratuitous arp延迟）协同定位与缓解。

如何通过分析 keepalived 切换瞬间的 tcp 重传率调优双机热备链路

Keepalived 切换瞬间的 TCP 重传率升高，本质是 VIP 漂移过程中连接中断导致的客户端重试行为。它不是孤立指标，而是链路层、网络层、传输层和应用层协同问题的外在表现。直接盯着重传率调参往往无效，必须结合切换全过程定位断点。

很多高重传被误判为“切换问题”，实则是底层网络或服务异常：

用 tcpdump 在客户端或负载均衡器侧抓包，过滤目标 VIP+端口，观察重传是否集中在 主节点停服 → 备节点接管完成 的时间窗口（通常 1–3 秒内）；若重传持续存在或分布均匀，大概率是后端服务响应慢、丢包、ARP 缓存未刷新或防火墙拦截所致
检查切换日志：journalctl -u keepalived -n 50 --since "1 minute ago"，确认是否出现 Transition to MASTER/BACKUP 记录，并比对时间戳与重传高峰是否吻合
执行 arping -I ens33 -c 3 192.168.100.107（VIP），验证切换后备机是否能立即响应 ARP 请求——若超时，说明 ARP 广播未生效，客户端仍向旧 MAC 发包，必然重传

重传率高，核心在于备机“接得慢”。默认配置下，从主节点宕机到备节点绑定 VIP 并响应流量，常需 3 秒以上。可通过以下三项收紧：

降低 advert_int：将 advert_int 1 改为 advert_int 0.5（单位秒），加快心跳检测频率；注意两节点必须一致，且不能低于 0.1，否则可能因网络抖动误切
启用 preemption：在 vrrp_instance 块中添加 preempt_delay 2（非必须）或明确设 preempt on，确保主恢复后快速抢回 VIP，避免长期由备机低效承载
禁用 gratuitous ARP 延迟：添加 notify_master "/bin/bash -c 'arping -U -c 3 -I ens33 192.168.100.107 >/dev/null 2>&1'"，让备机一升主就主动广播免费 ARP，强制刷新下游设备 ARP 表

即使 VIP 秒级漂移，TCP 连接仍会断。要降低感知，需两端协同：

客户端开启 TCP Fast Open（TFO）：Linux 客户端设 net.ipv4.tcp_fastopen = 3，减少首次握手耗时；服务端 Nginx 需配 listen 80 reuseport so_keepalive=on;
缩短 TCP TIME_WAIT 回收：备机上调整 net.ipv4.tcp_tw_reuse = 1 和 net.ipv4.tcp_fin_timeout = 30，加快端口复用，避免新连接因端口耗尽而阻塞
健康检查脚本必须真实反映服务可用性：例如 nginx_check.sh 不仅检测进程是否存在，更要 curl -s --connect-timeout 1 http://127.0.0.1/health | grep ok；否则 Nginx 已卡死但 Keepalived 仍认为正常，VIP 不漂移，重传持续发生

调优后必须量化验证，而非仅看“是否切换”：

用 ss -i 查看切换前后 ESTAB 连接的 retrans 字段变化；或用 tcpretrans（bpftrace 工具）实时统计每秒重传包数
建立基线：在无故障时运行 iperf3 -c VIP -t 60 -P 4，记录平均重传率（通常应 systemctl stop keepalived，重复测试，对比切换窗口内重传峰值是否下降 50% 以上
检查 /proc/net/snmp 中 Tcp: 行的 RetransSegs 累计值增幅，若单次切换增长超 500，说明链路仍有明显断点