选抢占还是非抢占取决于业务对切换抖动的容忍度：抢占模式适合秒级不可断场景，需配健康检查和weight动态降权；非抢占模式适合宁可延迟也不愿频繁切换的系统，所有节点state设BACKUP并加nopreempt参数。
选抢占还是非抢占，关键看你的业务能不能“忍”切换抖动——不是配置越高级越好，而是谁更贴合实际运行节奏。
抢占模式适合“秒级不能断”的场景
主节点一恢复就抢回 VIP，响应快、控制强。但前提是：你得确保它不是“假活”。比如金融支付系统要求服务永远由最强节点承载，那就必须用抢占模式，同时配好健康检查和 weight 动态降权。
- 主节点 priority 设为 100，备节点设为 90，靠差值触发初始选举
- 必须写 vrrp_script 检查 Nginx 进程或端口，失败时 weight -50 或更低，让 priority 实时跌破备节点
- state 可设 MASTER/BACKUP（抢占模式下 MASTER 更直观），但核心靠 priority + weight 联动判断
非抢占模式适合“宁可多等几秒，也不能来回切”
VIP 一旦交出去，就不抢回来。适用于 Web 服务、API 网关、带长连接或会话保持的系统。避免因主节点短暂卡顿（如 GC、网络闪断）引发无谓漂移。
- 所有节点 state 必须统一设为 BACKUP，不能有 MASTER
- 只在希望“稳住不反抢”的节点上加 nopreempt 参数（通常加在原主节点配置里）
- priority 仍要错开（如 100 和 80），否则启动顺序决定谁先接管，weight 依然要配，决定首次接管资格
weight 不是可选项，是业务感知的唯一通道
无论哪种模式，只要没配 weight，Keepalived 就只认操作系统是否存活，完全感知不到 Nginx 是否挂了。脚本返回失败 → weight 生效 → priority 变化 → 切换触发，这是整套逻辑的闭环。
- 检查脚本建议用 ss -lnt | grep 端口，比 ps 更可靠；避免用含 grep 的管道链，容易误判
- weight 值建议按 priority 差距设置：差值是 10，weight 至少 -15 才能确保故障时必切
- 非抢占模式中 weight 不影响“是否反抢”，只影响“第一次谁该上”，别省掉
硬件与网络条件决定模式起点
如果两台机器性能接近、网络延迟低、运维能快速响应，抢占模式更主动；如果主备服务器型号差异大（比如旧机器跑备机）、上游有大量 TCP 长连接、或 SLA 允许 30 秒内恢复，非抢占模式反而更稳。
- 测试时务必模拟真实故障：kill -9 nginx 进程，而不是 stop 服务，才能验证 weight 是否生效
- 切换后检查 ip a 输出，确认 VIP 归属；再 curl -I 测试服务可达性，别只看 Keepalived 日志
- 生产环境上线前，在测试集群反复启停 Nginx + 模拟网络中断，观察 VIP 行为是否符合预期
