调优 preempt_delay 是解决双机启动 vip 抢占冲突的关键手段，通过为备节点设置抢占许可倒计时（如5秒），确保其服务就绪后再参与选举，避免脑裂与vip反复漂移。
调优 vrrp_prio_delay（实际配置中对应 Keepalived 的 preempt_delay 参数）是解决双机同时启动时 VIP 抢占冲突的关键手段。这种冲突常发生在主备节点几乎同步上电或服务重启后——两者都处于初始状态，优先级相同或接近，又几乎同时发送 VRRP 通告，导致选举紊乱、VIP 反复漂移甚至短暂双主。
为什么双机启动容易触发 VIP 冲突
默认情况下，Keepalived 启动后立即进入 VRRP 状态机，若配置为抢占模式（preempt on），且未设延迟，高优先级节点一旦完成初始化就会立刻尝试抢占。但此时对端可能尚未完成健康检查脚本加载、Nginx 启动、ARP 刷新等依赖动作，造成：
- VIP 虽已绑定，但后端服务未就绪，客户端请求失败
- 两节点在毫秒级窗口内都宣称自己是 Master，触发脑裂（如 ARP 响应混乱、流量被丢弃）
- 系统日志频繁打印
Entering MASTER STATE/Entering BACKUP STATE循环
preempt_delay 的作用机制
preempt_delay 不是等待时间，而是“抢占许可倒计时”：节点进入 BACKUP 状态后，先等待该时长，再允许参与抢占决策。它确保节点在真正具备服务能力后再竞争 VIP。
- 仅对 BACKUP 节点生效；Master 节点不受影响
- 延迟期间，节点仍持续接收 VRRP 通告，能感知当前 Master 状态
- 延迟结束后，若检测到当前 Master 优先级更低，才发起抢占
推荐配置策略与实操要点
以典型 Nginx + Keepalived 双机为例（主节点 priority 100，备节点 priority 90）：
- 主节点不配
preempt_delay
- 备节点必须配置
preempt_delay 5 -
配套启用健康检查脚本：确保
vrrp_script检测 Nginx 进程与端口，失败时自动降权（如weight -20），避免服务未启就抢 VIP -
启动顺序建议：先启主节点，待其稳定进入 MASTER 状态（
ip a确认 VIP 已绑定、systemctl status keepalived显示正常）后再启备节点
验证是否生效
启动后观察日志和网络状态：
- 执行
tail -f /var/log/messages | grep Keepalived，备节点应出现类似Starting VRRP preemption delay (5s)日志 - 用
ip a查看 VIP 是否只出现在主节点，且备节点在 5 秒后才开始尝试协商 - 模拟主节点宕机（
systemctl stop keepalived），观察备节点是否在约 5 秒后平稳接管 VIP（而非瞬间切换）
