HAProxy 与 LVS 四层负载均衡优缺点对比选型建议

如果你的业务只需要基于 IP 和端口的流量转发且追求极致性能，选 LVS；如果需要 HTTP 域名分流、健康检查或七层逻辑，选 HAProxy。

先说结论：LVS 适合内核级四层超高并发场景，HAProxy 适合需要七层解析与健康检查的通用代理场景。

适合：LVS 用于入口层流量分发，HAProxy 用于应用层负载均衡或数据库代理。
重点看：LVS 无后端健康检查需配合 Keepalived，HAProxy 自带健康检查但为用户态软件。
别忽略：LVS 配置维护成本较高，HAProxy 在超大规模场景下转发效率略低于 LVS。

核心区别与版本特性

两者核心区别在于工作层级和实现位置。LVS 是 Linux 内核模块，工作在四层传输层，仅根据 IP 和端口转发，不解析数据包内容，因此转发效率极高。HAProxy 是用户态软件，支持四层和七层，能解析 HTTP 头部、URL 等内容。

注意版本差异：HAProxy 早期版本为单线程事件驱动，2.0+ 版本支持多线程配置（global 段配置 nbthread），若遇到性能瓶颈可开启多核利用。LVS 依托内核网络栈，天然支持多队列。

实操配置示例

选型后需落地配置，以下是核心配置片段。

1. LVS 规则添加与 DR 模式配置

# 创建虚拟服务 (VIP: 80, 调度算法 rr)
ipvsadm -A -t 192.168.1.100:80 -s rr

# 添加真实服务器 (RIP: 80, DR 模式 -g)
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -g
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.102:80 -g

# 后端服务器 ARP 抑制 (DR 模式必需，防止 IP 冲突)
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

2. Keepalived 健康检查配置 (配合 LVS)

vrrp_script chk_http_port {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight -20
}

virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    real_server 192.168.1.101 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

3. HAProxy 基础配置 (开启多线程)

global
    log /dev/log local0
    nbthread 4  # 2.0+ 版本支持，根据 CPU 核数调整
    maxconn 4096

defaults
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    option httpchk GET /health
    server web1 192.168.1.101:8080 check
    server web2 192.168.1.102:8080 check

怎么验证是否生效

部署后需通过以下方法验证流量是否按预期分发。

1. 连接数观察

使用ipvsadm -ln查看 LVS 后端 RealServer 的活跃连接数是否均匀增长。对于 HAProxy，可开启 stats 页面查看后端服务器的请求分布。

2. 故障切换测试

手动停止一台后端服务器，观察 LVS 是否仍转发流量（LVS 默认无检查可能仍转发，需依赖 Keepalived 脚本），HAProxy 应能自动标记该节点为 down 状态并停止转发。

3. 日志检查

检查 HAProxy 日志位置（通常为/var/log/haproxy.log），确认是否有后端响应状态码记录，LVS 则需查看系统日志或配合 Keepalived 日志。

常见坑

实际生产中容易遇到以下问题，需提前规避。

1. LVS 回包问题

在 DR 模式下，回包不经过 LVS，保证了均衡器 IO 的性能受大流量的影响最小，但需要后端服务器配置 ARP 抑制，否则可能出现 IP 冲突。

2. 健康检查缺失

直接使用 LVS 而不配置健康检查，当后端节点故障时，LVS 仍会转发流量导致用户请求失败。务必搭配 Keepalived 使用。

3. 性能瓶颈误判

HAProxy 2.0+ 版本支持多线程，若遇到性能瓶颈，先确认配置中是否开启nbthread，再确认是 CPU 单核满载还是网络带宽限制。