高可用集群的核心目标是消除单点故障，让任意一台服务器宕机时业务仍然可以正常对外提供服务。相比单机部署，集群架构通过冗余节点加自动故障转移机制，把服务的不可用时间压缩到分钟级甚至秒级。本文将以最常见的Web服务场景为例，讲解如何用几台普通服务器搭建一套可落地的高可用集群，涵盖虚拟IP漂移、负载均衡、健康检查和脑裂预防等关键环节。
一、高可用集群的整体架构设计
搭建集群之前，先要明确架构分层。一套典型的高可用Web集群由三层组成：最前面是入口层，负责接收用户请求，通常由两台负载均衡器组成主备结构，通过虚拟IP对外提供服务；中间是应用层，由多台Web服务器组成，实际处理业务逻辑；最底层是数据层，数据库主从复制或分布式存储保障数据不丢。
入口层是整个方案的关键。用户的DNS解析只指向一个虚拟IP，这个IP并不固定绑定在某台机器上，而是由Keepalived这样的软件动态持有。当主负载均衡器正常时，虚拟IP在主节点上；主节点一旦故障，备节点会在几秒内把虚拟IP接管过来，用户完全无感知。这种机制叫IP漂移，是实现高可用最基础也最可靠的手段。
应用层建议至少部署两台Web服务器，前面由Nginx做七层负载均衡，把请求按权重或轮询策略分发下去。任何一台Web服务器出问题，Nginx通过健康检查自动把它摘除，流量全部打到健康节点上。假设你有三台应用服务器，挂掉一台理论上还剩三分之二的处理能力，对中小流量业务来说足够扛住故障窗口期。
二、用Keepalived实现主备与虚拟IP漂移
Keepalived基于VRRP协议工作，VRRP即虚拟路由冗余协议，它允许多台服务器共享一个虚拟IP，其中一台作为MASTER持有该IP，其余作为BACKUP待命。节点之间通过组播发送心跳报文，默认每1秒一次。BACKUP如果连续三个周期收不到MASTER的心跳，就认为主节点失效，立即提升自己为新的MASTER并接管虚拟IP，整个切换过程通常在3到4秒内完成。
先准备两台负载均衡服务器，假设主节点IP为192.168.10.11，备节点为192.168.10.12，虚拟IP为192.168.10.100。在两台机器上分别安装Keepalived和Nginx：
# CentOS/RHEL 系统安装 yum install -y keepalived nginx # Debian/Ubuntu 系统安装 apt-get install -y keepalived nginx
主节点的Keepalived配置如下，配置文件路径为/etc/keepalived/keepalived.conf：
vrrp_instance VI_1 {
state MASTER # 初始角色为主节点
interface eth0 # 绑定的网卡名称
virtual_router_id 51 # 同一组主备必须一致
priority 100 # 优先级，越大越可能成为MASTER
advert_int 1 # 心跳间隔，单位秒
authentication {
auth_type PASS
auth_pass MyPass123 # 主备节点密码必须相同
}
virtual_ipaddress {
192.168.10.100 # 对外提供的虚拟IP
}
}备节点的配置只需改动两处：state改为BACKUP，priority改为90，其余保持一致。配置完成后启动服务并设置开机自启，然后用ip addr命令验证，主节点网卡上应该能看到192.168.10.100这个地址。此时可以做一个简单的切换测试：在主节点上执行systemctl stop keepalived，再到备节点上查看，虚拟IP会自动漂移过去，重新启动主节点的Keepalived后，由于优先级更高，虚拟IP又会抢占回来。
三、Nginx负载均衡与健康检查配置
负载均衡层由两台Nginx承担，它们的配置完全相同，这样无论虚拟IP漂移到哪台机器，流量转发规则都一致。假设后端有三台应用服务器，地址分别是192.168.10.21、192.168.10.22和192.168.10.23，Nginx的配置可以这样写：
upstream backend {
server 192.168.10.21:8080 weight=1 max_fails=2 fail_timeout=10s;
server 192.168.10.22:8080 weight=1 max_fails=2 fail_timeout=10s;
server 192.168.10.23:8080 weight=1 max_fails=2 fail_timeout=10s;
}
server {
listen 80;
server_name www.ipipp.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_connect_timeout 3s; # 连接后端超时时间
proxy_read_timeout 10s; # 读取响应超时时间
}
}上面配置中max_fails和fail_timeout组合实现了被动健康检查：某台后端在10秒内失败2次，就会被临时摘除10秒。这种方式配置简单，但只能发现连接层面的故障。如果后端进程活着但接口已经卡死，需要更主动的检测手段。开源社区常用的方案是给Nginx加装第三方健康检查模块，或者直接在Keepalived里配置TCP_CHECK与HTTP_GET检测：
# 在keepalived.conf中增加后端检测
virtual_server 192.168.10.100 80 {
delay_loop 6
lb_algo rr # 轮询调度算法
lb_kind DR # 转发模式
protocol TCP
real_server 192.168.10.21 8080 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 2
delay_before_retry 2
connect_port 8080
}
}
}需要注意的是，Keepalived的virtual_server功能走的是LVS四层转发，性能比Nginx七层代理高很多，适合大流量场景；而Nginx的优点是可以基于URL、Header做精细分流，两者可以按业务规模选择甚至叠加使用。
四、脑裂问题的预防与故障演练
脑裂是高可用集群最危险的故障形态：主备之间的心跳网络断了，但两台机器本身都活着，双方都认为对方挂了，于是都抢占虚拟IP，造成IP冲突、请求乱飞，数据层还可能出现双写。产生脑裂的常见原因包括交换机故障、网线松动、防火墙误拦截了VRRP报文、iptables规则丢弃112端口组播包等。
预防脑裂可以从几个方面入手。第一，心跳链路冗余，有条件的话给主备节点配置双网卡双链路，Keepalived支持配置多个vrrp_instance分别走不同网卡。第二，关闭或正确配置防火墙，确保VRRP协议的组播流量畅通，比如放行协议号112：
# 放行VRRP协议报文 firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept' firewall-cmd --reload
第三，引入第三方仲裁。可以增加一台独立的监控节点，定期通过脚本同时探测主备两台机器的状态，一旦发现双方都持有虚拟IP，就主动降级其中一台，比如直接kill掉优先级较低那台的Keepalived进程。下面是一段简单的仲裁检测脚本思路：
#!/bin/bash
# 检测两台负载均衡器是否同时持有虚拟IP
VIP=192.168.10.100
MASTER=192.168.10.11
BACKUP=192.168.10.12
# 分别通过SSH探测虚拟IP归属
CHECK1=$(ssh root@${MASTER} "ip addr | grep ${VIP} | wc -l")
CHECK2=$(ssh root@${BACKUP} "ip addr | grep ${VIP} | wc -l")
if [ "$CHECK1" -ge 1 ] && [ "$CHECK2" -ge 1 ]; then
echo "$(date) 检测到脑裂，正在降级备节点" >> /var/log/split_brain.log
ssh root@${BACKUP} "systemctl stop keepalived"
fi集群搭建完成后，故障演练是必不可少的环节。建议模拟以下几类场景并逐一验证：停掉主节点Keepalived进程观察虚拟IP切换耗时；直接关闭主节点电源测试极端情况；杀掉某台后端应用进程验证流量是否自动摘除；恢复故障节点确认它能否自动回归集群。每次演练记录切换时间，如果超过10秒就要排查心跳参数和优先级配置。日常运维中还要关注/var/log/messages里的VRRP日志，出现频繁的MASTER/BACKUP状态抖动，往往意味着网络质量不佳或检测阈值设置得过于敏感，可以适当调大advert_int或降低检测频率来平衡切换速度与稳定性。
五、总结与后续优化方向
这套Keepalived加Nginx的组合方案，用纯开源软件就实现了入口层秒级故障转移和应用层的负载均衡与健康检查，硬件成本只是多几台服务器。对于绝大多数中等规模的在线业务，它已经足够可靠。如果后续业务继续增长，可以从几个方向演进：一是把Nginx替换为LVS四层转发提升吞吐量；二是数据层引入MySQL主从加MHA自动切换，或者直接上分布式数据库；三是结合Prometheus和Grafana对集群各节点的状态做可视化监控，让故障在用户感知之前就被发现和处理。高可用不是一次性的工程，而是随业务持续演进的过程，定期演练和复盘才是集群长期稳定的根本保障。
高可用集群Keepalived负载均衡修改时间：2026-09-11 15:10:50