Keepalived抢占模式主节点恢复即抢回VIP，需weight动态降权实现业务感知；非抢占模式启用nopreempt后VIP不反抢，但所有节点state必须为BACKUP且仍需weight决定首次接管。

Keepalived 的抢占与非抢占模式不是简单“开或关”的开关，而是决定 VIP 切换节奏和稳定性的核心逻辑。选对模式、配好 weight、设准 state，三者协同才能让双机切换既及时又不抖动。

抢占模式：适合强一致性场景，但必须配 weight

默认即为抢占模式，主节点恢复后会立即抢回 VIP。这在金融、支付等要求“谁强谁上”的系统中很实用，但风险也很明显：若主节点只是短暂卡顿（比如 GC 停顿、网络抖动），就可能触发无谓漂移。

关键点在于：仅靠静态 priority 无法感知业务层故障。例如 Nginx 进程挂了，但系统还在运行，Keepalived 不会自动切换。

必须配合健康检查脚本和 weight 动态降权：

• 在 vrrp_script 中定义检查逻辑，如检测 Nginx 进程是否存在
• 设置 weight -40，使检查失败时 priority 实时下降
• 主节点原 priority 100 → 故障后变为 60，低于备节点的 90，触发接管
• 主节点恢复后，priority 回升至 100，立刻抢回 VIP

非抢占模式：适合服务稳定性优先的场景

启用 nopreempt 后，VIP 一旦由备节点接管，就不会被原主节点反抢。这对 Web 服务、API 网关等容忍短时故障、但忌讳频繁切换的系统更友好。

配置要点很明确：

• 所有节点的 state 都必须设为 BACKUP（不能有 MASTER）
• 至少一个节点配置 nopreempt（只在 BACKUP 节点生效）
• 优先级仍需错开（如 100 和 90），否则启动顺序决定谁先成为 MASTER
• weight 依然要配——它决定的是“首次谁该接管”，而不是“后续要不要抢”

两种模式下 weight 的作用差异

很多人误以为非抢占模式可以省掉 weight，其实不然。weight 在两类模式中承担不同职责：

• 抢占模式中，weight 是实现“服务挂即切”的必要条件；没它，VIP 永远不会因应用崩溃而漂移
• 非抢占模式中，weight 决定的是“谁有资格在首次故障时接管 VIP”；它不参与后续反抢判断，但缺了它，第一次切换也可能失效
• 无论哪种模式，只要 health check 脚本返回失败，weight 就会实时调整 priority，这是 Keepalived 感知业务状态的唯一可靠方式

实际部署建议

不要凭感觉选模式，而要看你的服务特性和运维习惯：

• 若集群节点性能接近、网络质量高，且业务能承受秒级中断，用抢占模式 + weight 更主动
• 若存在主备硬件差异（如旧服务器跑备机）、或上游有长连接/会话保持，优先选非抢占模式
• 生产环境上线前，务必模拟三次故障：服务进程 kill、keepalived stop、主机断电，验证 VIP 行为是否符合预期
• 避免混用 state：MASTER/BACKUP 搭配 nopreempt 无效；两个 MASTER 会导致脑裂；两个 BACKUP 却没配 nopreempt，则退化为抢占逻辑