Keepalived 故障转移依赖 VRRP 协议、健康检查与状态选举协同实现，非简单“一挂就切”；通过心跳检测、脚本探测服务真实状态、VIP 动态绑定及合理超时配置保障高可用。

Keepalived 实现 VIP 漂移完成故障转移，核心是靠 VRRP 协议 + 健康检查 + 状态选举三者协同，不是简单“一挂就切”，而是有节奏、可配置、防误判的自动接管过程。

基于 VRRP 的主备状态管理

VRRP 是 Keepalived 的底层通信机制。两台（或以上）服务器组成一个虚拟路由器，对外共用一个 VIP。其中一台被选为 MASTER，负责绑定并响应 VIP 的流量；其余为 BACKUP，持续监听 MASTER 发出的心跳报文。

• MASTER 定期发送 VRRP 通告（默认每 1 秒一次，由 advert_int 控制）
• BACKUP 若连续 fall 次未收到通告（例如 advert_int 1; fall 3 → 3 秒无响应），即触发角色切换
• 切换时，BACKUP 自动执行 arping 广播，宣告 VIP 归属变更，确保下游设备更新 ARP 表

叠加应用层健康检查防“假活”

VRRP 心跳只说明网络通、进程在，不等于服务真可用。比如 Nginx 进程没死但返回 502，或 MySQL 能连但查询卡住——这时必须靠自定义脚本做真实业务探测。

• 用 vrrp_script 定义检查逻辑，例如：curl -m 3 -f http://127.0.0.1/health 或 mysql -h127.0.0.1 -e "SELECT 1"
• 脚本返回非 0（如超时、连接拒绝、HTTP 非 2xx）才视为失败，不能漏写 exit 码判断
• 脚本总耗时必须小于 advert_int × fall，否则会被 Keepalived 当作“检查本身异常”而非“服务异常”

VIP 绑定与释放的原子操作

VIP 不是“配置好就一直挂着”，而是在角色变化瞬间动态增删：

• MASTER 启动时：调用 notify_master 脚本，执行 ip addr add $VIP dev $IFACE
• MASTER 故障或降级时：触发 notify_backup，执行 ip addr del $VIP dev $IFACE
• BACKUP 升为 MASTER 时：同样走 notify_master，完成 VIP 绑定和 ARP 刷新
• 整个过程毫秒级完成，客户端 TCP 连接通常能复用（尤其短连接场景几乎无感）

避免频繁切换的关键配置原则

稳比快重要。生产环境应主动引入容错窗口，而不是追求极致响应：

• 关闭抢占（nopreempt）：主节点恢复后不抢 VIP，避免来回切换抖动
• 设置 rise 参数：服务恢复需连续通过 N 次检查才重新启用，防止刚加载完就导流
• 跨机房部署时，fall 值建议设为 5～6，容忍网络瞬断；局域网可设为 2～3
• 所有超时值（脚本 -m、advert_int、fall）要形成逻辑闭环，不能孤立调优