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）要形成逻辑闭环，不能孤立调优
