keepalived的priority是主从角色的刚性判决依据，数值大者必为master，小者为backup；相同则易引发脑裂，必须与state、virtual_router_id、authentication严格匹配才能生效。
Keepalived 的 priority 值不是“建议值”，而是主从角色的刚性判决依据——同一 virtual_router_id 下，数值大的节点必定成为 MASTER，小的为 BACKUP；相同则大概率引发脑裂。配置时不能只写 priority，必须与 state、virtual_router_id、authentication 三者严格对齐，否则再高的数值也无效。
priority 数值设定的基本原则
主节点优先级应显著高于备节点，不靠“差不多”，而靠“留余量”：
- 推荐主节点设为 100～150（如 110），备节点设为 80～99（如 90）
- 主备之间至少保留 10 点以上差值，避免因微小配置偏差或脚本临时波动导致误切换
- 不要用 255 或 0 这类边界值——255 是 Keepalived 内部保留（如主动释放 VIP 时使用），0 表示立即退为 BACKUP，易引发非预期漂移
- 若需长期维持主节点不抢回（例如维护期间），可临时关闭 preemption，但不要依赖 nopreempt 代替 priority 设计
动态衰减：让 priority “活起来”的关键配置
静态 priority 只能应对宕机，而真实故障常是服务僵死、端口响应慢、磁盘满等“假活着”状态。这时要靠 vrrp_script + weight 实现按条件降权：
- 定义健康检查脚本（如检测 Nginx 进程、端口连通性或自定义健康接口），返回非 0 即触发衰减
- weight 推荐设为负值（如 -20、-30），表示“失败一次扣多少分”
- 通过 fall 和 rise 控制灵敏度：fall 2 表示连续失败 2 次才生效，rise 3 表示连续成功 3 次才恢复原值
- 实际生效优先级 = 配置 priority + 所有已触发 weight 之和（多个脚本可叠加，但最终被截断在 1～255 区间）
常见失效场景与避坑要点
priority 设对了，不代表一定生效。以下配置错误会让 priority 形同虚设：
- interface 名称不一致：一端写 eth0，另一端写 ens33 → VIP 绑定失败，日志报“invalid interface”
- virtual_router_id 不同：哪怕只差 1（如 51 vs 52），两节点完全无法感知对方，各自当 MASTER
- auth_pass 不匹配或 auth_type 混用（如一端 PASS，一端 AH）→ 心跳包被直接丢弃，BACKUP 误判为主宕机
- vrrp_strict 开启但 global_defs 缺少必要项（如 smtp_server、router_id）→ keepalived 启动失败，VIP 根本不出现
- 防火墙拦截 VRRP 组播（协议号 112，目的地址 224.0.0.18）→ 日志中反复出现“recv buffer is empty”，VIP 漂移无规律
验证 priority 是否真正起效的实操方法
别只看配置文件，要观察运行态行为：
- 启动后立刻执行
ip -br a show，确认 VIP 仅出现在 priority 更高的一端网卡上 - 两端同时执行
tail -f /var/log/messages | grep "VRRP"，观察是否出现 “Becoming MASTER” 或 “Entering BACKUP STATE” - 手动停掉高 priority 节点的 keepalived：
systemctl stop keepalived，1 秒内 VIP 应完成漂移；恢复后，VIP 应自动切回（preemption 默认开启） - 模拟服务异常：如 kill -9 Nginx 进程，观察日志中是否触发 track_script、weight 是否生效、实际优先级是否下降并触发切换
