这篇指南帮助你理解 Keepalived VRRP 健康检查的工作原理，掌握主备切换与脑裂防护的配置方法。对运行在 [VPS](https://cn.hostease.com/vps/)（Virtual Private Server，[虚拟专用服务器](https://cn.hostease.com/vps/)）或[独立服务器](https://cn.hostease.com/dedicated-server/)上的业务来说，单点故障（single point of failure，指系统中某个组件一旦失效会导致整个服务不可用）是最常见的可用性风险，Keepalived 正是解决这类问题最常用的工具。
Keepalived 基于 VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）实现高可用。两台主机组成一个虚拟路由组，对外共享一个虚拟 IP（Virtual IP，VIP），正常情况下只有主节点响应请求，备节点通过心跳随时准备接管。和 MySQL 云服务器（在云端提供弹性计算资源的虚拟机实例）数据库部署这类强调单机可靠性的方案不同，Keepalived 解决的是”这台机器挂了怎么办”的问题。本文不展开 VRRP 全部参数，只聚焦健康检查怎么配、主备切换怎么发生、脑裂（split-brain，指两个节点同时认为自己是主节点）怎么防。
一、Keepalived 主备切换是如何发生的
Keepalived 由两个核心组件构成：VRRP 栈负责节点之间的主备协商，健康检查脚本负责探测业务是否真的健康。默认情况下，Keepalived 的 MASTER（主节点）以固定间隔向 BACKUP（备节点）发送 VRRP 通告包，备节点连续若干次收不到通告后，会认定主节点已失效，进入 MASTER 状态接管虚拟 IP。这个过程就是主备切换。
健康检查脚本是判断”服务是否健康”的入口。仅靠 VRRP 通告只能判断节点进程是否存活，无法判断业务进程是否正常。比如 Nginx 进程还活着，但后端的数据库连接已经断掉，此时如果只做进程级检查，主节点依然不会让出虚拟 IP，用户访问就会持续报错。正确做法是把业务关键路径写进检查脚本，由脚本结果决定 Keepalived 是否让出主节点。
二、健康检查脚本的写法
健康检查脚本通常放在 /etc/keepalived/check_service.sh，判断结果通过退出码返回：返回 0 表示健康，返回非 0 表示不健康。Keepalived 根据连续失败次数触发降级。
#!/bin/bash
curl -sf http://127.0.0.1:8080/health >/dev/null 2>&1 || exit 1
check=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health)
if [ "$check" != "200" ]; then
exit 1
fi
exit 0
检查脚本默认位于 /etc/keepalived/check_service.sh，并赋予可执行权限。脚本里建议包含两层判断：第一层用 curl 确认 HTTP 服务返回 200；第二层可以检查依赖的本地端口是否监听。注意脚本的退出码是 Keepalived 判断健康的唯一依据，任何未捕获的错误都可能导致误判，建议把逻辑写成”全通过才返回 0″。
三、Keepalived 主备配置示例
下面是一个典型的两节点主备配置。主节点和备节点除了 state 与 priority 不同，其余保持一致。这里以端口 8080 的应用服务为例。
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
virtual_ipaddress {
10.0.0.100/24
}
track_script {
chk_service
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
}
vrrp_script chk_service {
script "/etc/keepalived/check_service.sh"
interval 2
timeout 3
fall 3
rise 2
}
备节点的 state 改为 BACKUP，priority 改为 100，其余配置保持一致。priority 决定谁优先成为主节点，同一虚拟路由组内 priority 越高的节点在健康时越有机会成为 MASTER。这里给的是典型区间示例，实际优先级请按组内节点数量调整。备节点配置中不要设置 mcast_src_ip 或使用不同网卡地址，否则会影响 VRRP 组播通信。
四、脑裂防护
脑裂是 Keepalived 高可用里最危险的故障，指两个节点同时认为自己是主节点，同时绑定虚拟 IP，导致同一时间有两个节点处理写请求，数据一致性和服务可用性都被破坏。脑裂的常见诱因有网络抖动导致 VRRP 通告丢失、防火墙阻挡了 VRRP 组播（组播地址 224.0.0.18，端口 112）、两个节点配置了不同的 virtual_router_id。
基础防护包括：advert_int 保持一致的默认间隔，避免主节点通告过慢；在云厂商安全组放行 VRRP 协议（协议号 112），否则心跳被拦截；配置 notify_fault 脚本，当节点进入 fault 状态时主动降级并释放虚拟 IP，而不是继续抢主。此外可以在 notify_fault 里调用仲裁逻辑，结合数据库锁或第三方案例来确认是否真的需要接管。
排查脑裂时，先在主备节点分别执行 ip addr 查看虚拟 IP 是否同时存在。如果同时存在，说明已经脑裂。更多网络层面问题的定位思路，可参考 Nginx 限流配置中关于流量入口层做防护的对照理解。数据库场景下，若健康检查依赖 MySQL 状态，建议同时参考 MySQL 慢查询分析，先排除慢 SQL 拖垮检查脚本超时的可能。
五、切换验证与回滚
配置完成后不能只靠”看起来正常”就上线，必须做一次受控的主备切换演练。演练前先记录当前主节点是谁，用 ip addr 确认虚拟 IP 挂在哪个节点。然后在主节点上停掉关键服务，观察虚拟 IP 是否在 fail 周期内迁移到备节点，同时确认用户请求没有长时间中断。
验证命令如下：
# 查看当前虚拟 IP 归属 ip addr | grep 10.20.0.10 # 模拟主节点故障 systemctl stop keepalived # 备节点观察 tail -f /var/log/keepalived.log
演练通过后，把主节点服务恢复并重启 Keepalived。观察它是否按 priority 差异重新夺回主节点，还是保持在备节点状态——这取决于你是否配置了抢占（nopreempt）选项。若切换过程中用户请求中断超过预期，回滚到单节点运行即可：把备用节点关闭 Keepalived，让虚拟 IP 回到原主节点。对依赖关系复杂、检查脚本有误判风险的服务，建议先在备用节点上单独跑脚本验证退出码再接入 Keepalived。
如果服务端口经常变化，健康检查脚本建议用轻量只读端口代替具体业务端口，避免脚本误报。若担心 HTTP 端口校验与端口占用冲突，可参考 Redis 持久化与恢复的思路，先定位服务本身的资源基线再决定检查粒度。
六、监控与告警收口
仅靠 Keepalived 自身日志不够，建议把主备切换事件接入监控系统。Keepalived 的 notify 脚本会把事件写进日志，可将日志内容转发到监控面板。这里以常见的指标采集为例：记录最后一次 MASTER/BACKUP 切换时间、当前节点角色、虚拟 IP 是否就绪。把这些指标交给监控平台集中展示，可以第一时间发现频繁切换等异常，而不需要每次切换都登录服务器排查。相关方案可参考 Grafana 服务器部署实战做一套完整的可视化监控，把切换事件与业务指标对照起来看。
如果站点启用了 HTTPS（Hypertext Transfer Protocol Secure，超文本传输安全协议），证书续期失败也会让健康检查误判服务异常，建议一并接入证书到期监控，思路与 Certbot SSL（Secure Sockets Layer，安全套接层）证书排查一致。把这些监控串联起来，主备切换就不再是”黑盒操作”。
总结
Keepalived VRRP 健康检查配置的核心是：脚本退出码决定业务健康、priority 决定主备角色、notify 脚本负责故障后释放资源。主备切换与脑裂防护的要点是——优先级、路由 ID、通告间隔、VRRP 协议号这四项在集群节点之间必须保持一致，缺一个都可能引发误切换。建议先做主备切换演练，用 ip addr 和日志验证虚拟 IP 迁移与恢复，再投入生产。对 Hostease 环境上的高可用部署，把健康检查脚本写稳、把脑裂防护配全，比单纯堆叠 Keepalived 配置更能保证业务连续。