keepalived 通过保障 vip 高可用间接提升 nginx 集群通信质量，核心是减少不可达时间与避免单点抖动；优化包括缩短 vrrp 检测周期、启用单播、绑定物理网卡、绑定 nginx 健康状态、精准 weight 降级、主动刷新 arp 表、规避云环境冲突、调大 arp 表项，并协同 nginx 预热连接池、同步限流与处理会话。
Keepalived 本身不直接优化通信质量（如延迟、丢包、吞吐），但它通过保障入口服务的连续性、稳定性与快速切换能力，间接大幅提升 Nginx 集群对外暴露的通信质量。关键在于“减少不可达时间”和“避免单点抖动”，而非提升单次请求的网络性能。
确保 VIP 漂移零感知
客户端访问的是虚拟 IP（VIP），Keepalived 的核心价值是让这个 VIP 始终绑定在健康节点上。优化要点：
-
缩短 VRRP 报文检测周期：将
advert_int设为1（秒），配合fall 2 rise 1，可使故障识别控制在 2–3 秒内；过长（如默认 3 秒）会导致用户连接超时重试。 -
启用单播替代组播：在多网卡或复杂网络中，组播易被交换机/防火墙拦截。使用
unicast_src_ip和unicast_peer显式指定对端地址，提升心跳可靠性。 -
绑定物理网卡而非逻辑接口：
interface eth0要指向实际承载流量的网卡，避免使用 bond0 或 vlan 子接口（除非明确支持 VRRP）。
让 Keepalived 真正反映 Nginx 状态
VIP 漂移必须与 Nginx 服务能力强绑定，否则会出现“VIP 在线但 Nginx 不响应”的假高可用。
-
用脚本做七层健康检查：仅靠
TCP_CHECK（四层端口通）不够。应编写check_nginx.sh，执行curl -s --connect-timeout 1 -m 2 http://127.0.0.1/healthz | grep "ok"，返回非 0 则触发降权。 -
weight 降级要足够显著：主节点优先级设为 100，检查失败后
weight -50，确保低于备机（如 90），避免因小偏差导致脑裂或反复切换。 -
避免检查脚本自身成为瓶颈：脚本内禁用耗时操作（如 DNS 解析），用
127.0.0.1直连，超时严格限制在 1–2 秒内。
降低网络层干扰，稳定入口链路
通信质量劣化常源于底层网络行为，Keepalived 配置可规避常见陷阱：
-
关闭 gratuitous ARP 抑制（若环境允许）：在
vrrp_instance块中添加notify_master "/etc/keepalived/notify.sh"，并在脚本中主动执行arping -U -c 3 -I eth0 192.168.x.14，强制刷新下游交换机/网关的 ARP 表，防止 VIP 切换后旧 MAC 缓存导致丢包。 - 避免与云厂商 SLB 冲突：公有云中禁用 Keepalived 的 VRRP 组播（会被拦截），改用单播 + 云平台提供的健康检查+弹性 IP 绑定方案；自建 IDC 才适用标准 VRRP。
-
预留足够 ARP 表项空间：Linux 默认
net.ipv4.neigh.default.gc_thresh*值偏低，高并发下可能清掉 VIP 的 ARP 条目，需调大以保稳定。
配合 Nginx 做协同收敛
Keepalived 切换只是第一步，Nginx 必须能承接住切换后的瞬时流量洪峰：
-
预热连接池：Nginx 启动后，Keepalived 的
notify_master脚本可触发curl预热关键 upstream，避免首次请求因连接建立慢而超时。 -
同步限流配置：若 Nginx 启用
limit_req，确保主备节点配置完全一致，防止切换后限流策略突变引发大量 503。 - 共享 session 或关闭 sticky：VIP 切换后客户端 TCP 连接会断开重连，若依赖 IP hash 或 cookie stickiness，需确认后端能容忍连接重建，或改用一致性哈希等无状态分发方式。
