Linux服务器高可用集群方案对比：Keepalived与LVS、HAProxy的选型与实践

服务器高可用集群是线上服务稳定性的基础保障。Linux环境下，Keepalived、LVS、HAProxy是使用频率最高的三套方案，但三者解决的问题并不相同：Keepalived负责虚拟IP漂移，LVS工作在四层转发，HAProxy偏重七层负载。选型时先搞清楚高可用集群各层的职责，再按业务流量特征做组合，才不会把方案做复杂。

Linux高可用集群的分层模型

一套完整的高可用集群通常分三层：接入层负责虚拟IP（VIP）管理，转发层负责流量分发，业务层跑实际应用。Keepalived跑在接入层，LVS和HAProxy跑在转发层。三层解耦后，任意一层故障都能独立切换，不需要重启整套系统。

以两台主备服务器为例，Keepalived通过VRRP协议在节点间同步VIP，主节点宕机后，备用节点在秒级内接管VIP，客户端感知不到IP变化。转发层用LVS做四层分发，或HAProxy做七层分发，把请求打到多台后端业务机上。

Keepalived虚拟IP漂移配置

Keepalived的核心配置是VRRP实例，指定虚拟IP和节点优先级。主备节点的配置基本对称，优先级不同即可：

global_defs {
    router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER            # 备节点改为BACKUP
    interface eth0
    virtual_router_id 51
    priority 100            # 备节点改为90
    advert_int 1
    virtual_ipaddress {
        192.168.1.100/24
    }
}

state只在启动时生效，真正决定主备的是priority。两台机器都启动后，priority高的成为主节点。配置好之后，在主节点停掉Keepalived，VIP会自动切到备节点，用ip addr命令即可验证漂移结果。

LVS四层负载与Keepalived联动

LVS支持NAT、DR、TUN三种模式，实际部署用DR模式最多，原因是后端不用改网关。DR模式下，Keepalived负责VIP漂移，LVS负责分发，后端服务器配置Loopback接口绑定VIP。Keepalived和LVS在官方脚本里是联动配置的，Keepalived包内自带lvs-sync-daemon，通过notify脚本同步LVS规则：

vrrp_instance VI_1 {
    notify_master "/etc/keepalived/lvs-master.sh"
    notify_backup "/etc/keepalived/lvs-backup.sh"
}

# lvs-master.sh 内容
#!/bin/bash
ipvsadm -C
ipvsadm -A -t 192.168.1.100:80 -s rr
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g

主节点接管VIP时，ipvsadm -C清空并重建规则，备节点只清空不重建，保证只有主节点在分发。

HAProxy七层负载与健康检查

需要HTTP协议级能力（Cookie保持、路径路由、内容改写）时用HAProxy。健康检查支持TCP和HTTP两种，HTTP检查更贴近真实请求：

frontend web_front    bind *:80    default_backend web_back
backend web_back    balance roundrobin    server web1 192.168.1.11:8080 check inter 3s fall 3 rise 2    server web2 192.168.1.12:8080 check inter 3s fall 3 rise 2

check参数开启健康检查，interp控制检查间隔，fall连续失败次数超过阀值自动摘除节点，rise恢复阈值。HAProxy和Keepalived配合，Keepalived管VIP，HAProxy管分发，两者不冲突，也是生产中最常见的组合。

选型与故障切换验证

选型没有绝对最优，只有匹配业务。四层入口（数据库、Redis）、简单分发用LVS+Keepalived；需要七层特性（会话保持、按路径路由）用HAProxy+Keepalived；单个应用服务器本身用Keepalived做VIP漂移就够。

集群搭好后要做一次完整的故障演练：依次杀掉主Keepalived、后端业务进程，用curl持续请求VIP，记录切换时间和恢复时间，把演练结果固化为文档，定期重跑。