当前位置：首页 > 文章列表 > 文章 > linux > Linux负载均衡教程：LVS与HAProxy实战解析

Linux负载均衡教程：LVS与HAProxy实战解析

2025-08-13 10:39:31 0浏览收藏

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《Linux负载均衡配置教程：LVS与HAProxy实战指南》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

LVS和HAProxy是Linux服务器负载均衡的两种主流方案。1.LVS在内核层面提供高性能四层负载均衡，适用于高并发、大流量场景，其DR模式通过直接路由实现高效转发；2.HAProxy在用户空间提供灵活的四层和七层负载均衡，支持HTTP路由、SSL卸载等功能，适合Web服务等需智能流量管理的场景；3.两者可通过Keepalived实现高可用，避免单点故障；4.LVS有NAT、DR、TUN三种工作模式，分别适用于不同网络环境与性能需求。选择时应根据性能要求、协议层级及功能需求进行权衡。

Linux服务器负载均衡实现_Linux LVS与HAProxy配置教程

Linux服务器的负载均衡，通常我们会考虑LVS（Linux Virtual Server）和HAProxy这两种主流方案。它们各有侧重，LVS在内核层面提供高性能的四层负载均衡，而HAProxy则在用户空间提供更灵活的四层和七层负载均衡能力。选择哪一个，往往取决于你的应用场景对性能、功能和复杂度的具体需求。

解决方案

实现Linux服务器负载均衡，我们通常会结合LVS或HAProxy来构建。

LVS的实现与配置

LVS作为内核级别的负载均衡器，其性能优势在于直接在IP层转发数据包，开销极低。我个人在处理高并发、纯粹的TCP/UDP转发场景时，LVS的Direct Routing（DR）模式几乎是首选。

环境准备：
- Director Server (负载均衡器)：安装ipvsadm工具。
- Real Servers (后端服务器)：配置回环接口（lo）上的虚拟IP（VIP），并抑制ARP广播。

LVS-DR模式配置：

Director端：

# 启用IP转发
echo 1 > /proc/sys/net/ipv4/ip_forward

# 清空现有规则
ipvsadm -C

# 添加虚拟服务：-A 添加服务，-t TCP协议和VIP:端口，-s 调度算法（rr: 轮询，lc: 最少连接）
ipvsadm -A -t 192.168.1.100:80 -s rr

# 添加真实服务器：-a 添加真实服务器，-t 虚拟服务，-r 真实服务器IP:端口，-g DR模式
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

# 保存规则（可选，系统重启后需要重新加载）
# ipvsadm -S > /etc/sysconfig/ipvsadm
# systemctl enable ipvsadm (如果使用systemd)

Real Server端：为了解决DR模式下的ARP问题，需要配置每个真实服务器，让它知道VIP是它自己的，但不对外广播ARP。

# 配置回环接口上的VIP，掩码为255.255.255.255
# 假设VIP是192.168.1.100
ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 broadcast 192.168.1.100 up

# 抑制ARP广播
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

这些配置通常会写入/etc/sysctl.conf或启动脚本中以实现持久化。

HAProxy的实现与配置

HAProxy则是一款非常强大的用户空间负载均衡器，尤其在HTTP/HTTPS等应用层协议处理上表现出色。它的配置相对灵活，功能也更丰富，比如SSL卸载、会话保持、内容路由等。

安装HAProxy：

yum install haproxy -y # CentOS/RHEL
apt-get install haproxy -y # Debian/Ubuntu

配置HAProxy (/etc/haproxy/haproxy.cfg)：以下是一个典型的HTTP负载均衡配置示例：

global
    log /dev/log    local0 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    # maxconn 20000 # 最大并发连接数，根据服务器性能调整

defaults
    mode http # 默认模式为HTTP，也可以是tcp
    log global
    option httplog
    option dontlognull
    timeout connect 5000ms # 连接超时
    timeout client 50000ms # 客户端超时
    timeout server 50000ms # 服务器超时
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend http_front
    bind *:80 # 监听80端口
    mode http
    default_backend http_back

backend http_back
    mode http
    balance roundrobin # 负载均衡算法：roundrobin（轮询）、leastconn（最少连接）、source（源IP哈希）
    option httpchk GET /healthz # 健康检查，请求/healthz路径
    server web1 192.168.1.101:80 check inter 2000 rise 2 fall 3 # 后端服务器1，2秒检查一次，2次成功上线，3次失败下线
    server web2 192.168.1.102:80 check inter 2000 rise 2 fall 3 # 后端服务器2
    # server web3 192.168.1.103:80 check backup # 备份服务器
    # server web4 192.168.1.104:80 check disabled # 禁用服务器

listen stats
    bind *:8080 # 监听统计页面端口
    mode http
    stats enable
    stats uri /haproxy_stats # 统计页面URI
    stats realm Haproxy\ Statistics
    stats auth admin:password # 认证信息
    stats refresh 10s # 刷新间隔

启动HAProxy：

systemctl start haproxy
systemctl enable haproxy

LVS与HAProxy的主要区别和适用场景是什么？

在选择LVS还是HAProxy时，我通常会先问自己一个问题：我需要的是高性能的纯粹转发，还是更智能的应用层路由？

LVS (Linux Virtual Server)

工作层面：主要工作在OSI模型的第四层（传输层），即IP层和TCP/UDP层。
特点：
- 高性能：内核级实现，数据包转发效率极高，几乎没有额外的延迟。特别是在DR模式下，数据包只经过Director一次（入站），出站流量直接由Real Server返回给客户端，避免了Director成为瓶颈。
- 低开销：对CPU和内存的消耗非常小。
- 透明性：对后端服务器来说，客户端的源IP是可见的。
适用场景：
- 高并发、大流量：例如大型网站的静态资源、CDN节点、数据库连接等场景。
- 纯TCP/UDP负载均衡：对应用层协议不敏感，只做简单的端口转发。
- 对性能要求极致：需要处理每秒数万甚至数十万的并发连接。
缺点：
- 功能相对单一，不具备HTTP头部检查、URL路由、SSL卸载等应用层特性。
- 配置相对复杂，特别是DR模式下的ARP问题需要额外处理。

HAProxy

工作层面：可以工作在第四层（TCP模式）和第七层（HTTP模式）。
特点：
- 功能丰富：支持HTTP头部修改、URL路由、内容切换、SSL卸载、会话保持（cookie、source IP等）、高级健康检查、ACL规则等。
- 灵活性高：配置简单直观，易于管理和扩展。
- 可观测性好：自带强大的统计页面，方便监控后端服务器状态和流量。
适用场景：
- Web应用负载均衡：特别适合HTTP/HTTPS服务，如Web服务器、API网关、微服务入口。
- 需要高级路由策略：根据URL、Cookie、Header等进行流量分发。
- 会话保持：对需要保持用户会话的应用至关重要。
- 中小型到大型规模：在大多数场景下，HAProxy的性能足以满足需求。
缺点：
- 用户空间实现，相比LVS在极端高并发下会有一定的性能开销。
- 作为代理，会改变客户端源IP（除非使用PROX Y协议或TPROXY模式）。

我的选择偏好：如果我只是想把流量均匀地分发到一组服务器，并且对性能要求极高，我会倾向于LVS。但如果我的应用是Web服务，需要更智能的流量管理，比如根据URL路径分发到不同的后端服务，或者需要SSL卸载来减轻后端服务器的压力，那HAProxy无疑是更好的选择。很多时候，LVS和HAProxy也会结合使用，LVS作为第一层负载均衡，将流量分发到HAProxy集群，再由HAProxy进行更细粒度的应用层分发。

如何解决LVS和HAProxy的单点故障问题？

负载均衡器本身如果挂了，那所有的后端服务器就都无法访问了，这显然是不能接受的。解决LVS和HAProxy的单点故障（SPOF）问题，最常见且有效的方法是引入Keepalived。

Keepalived的工作原理

Keepalived通过VRRP（Virtual Router Redundancy Protocol）协议实现高可用性。它会在一组服务器上配置一个虚拟IP（VIP），并通过心跳机制监控主服务器的状态。当主服务器发生故障时，Keepalived会自动将VIP漂移到备份服务器上，从而实现服务的无缝切换。

结合LVS实现高可用

在LVS集群中，通常会有两台或多台Director服务器。Keepalived会运行在这些Director上：

VIP管理：Keepalived会配置一个共享的VIP。正常情况下，主Director会持有这个VIP。
健康检查：Keepalived会持续监控主Director的运行状态（例如，通过检查LVS进程、网络接口等）。
故障切换：一旦主Director检测到故障，Keepalived会触发VRRP协议，让备份Director接管VIP，继续提供LVS负载均衡服务。
Real Server健康检查：Keepalived还可以配置对后端Real Server的健康检查。如果某个Real Server宕机，Keepalived可以通知LVS将其从服务列表中移除，避免流量发送到故障服务器。

Keepalived配置示例（LVS Director高可用）

# /etc/keepalived/keepalived.conf

global_defs {
    router_id lb01 # 路由器ID，唯一标识
}

vrrp_instance VI_1 {
    state MASTER # MASTER表示主服务器，BACKUP表示备份服务器
    interface eth0 # 绑定Keepalived的网卡
    virtual_router_id 51 # VRRP实例ID，同一组Keepalived必须相同
    priority 100 # 优先级，MASTER要高于BACKUP
    advert_int 1 # 广播间隔，秒

    authentication {
        auth_type PASS
        auth_pass 1111 # 认证密码
    }

    virtual_ipaddress {
        192.168.1.100/24 dev eth0 label eth0:0 # LVS的VIP
    }

    # 监控LVS进程，如果进程不存在，则切换
    track_script {
        chk_lvs
    }
}

# 定义一个脚本，用于检查LVS状态
vrrp_script chk_lvs {
    script "/usr/bin/killall -0 ipvsadm" # 检查ipvsadm进程是否存在
    interval 2 # 每2秒执行一次
    weight -20 # 如果脚本执行失败，优先级降低20
}

# LVS虚拟服务器定义（可选，Keepalived也可以直接管理LVS规则）
# 实际生产中，更推荐通过脚本或ipvsadm命令来管理LVS规则，Keepalived只负责VIP和Director切换
# virtual_server 192.168.1.100 80 {
#     delay_loop 6
#     lb_algo rr
#     lb_kind DR
#     persistence_timeout 0
#     protocol TCP

#     real_server 192.168.1.101 80 {
#         weight 100
#         TCP_CHECK {
#             connect_timeout 3
#             nb_get_retry 3
#             delay_before_retry 3
#         }
#     }
#     real_server 192.168.1.102 80 {
#         weight 100
#         TCP_CHECK {
#             connect_timeout 3
#             nb_get_retry 3
#             delay_before_retry 3
#         }
#     }
# }

结合HAProxy实现高可用

对于HAProxy，高可用的思路与LVS类似，也是通过Keepalived来管理HAProxy实例的VIP：

VIP管理：Keepalived在两台HAProxy服务器之间管理一个VIP。
健康检查：Keepalived会监控HAProxy进程是否正常运行。
故障切换：当主HAProxy服务器出现故障时，Keepalived会将VIP漂移到备份HAProxy服务器，确保服务不中断。

Keepalived配置示例（HAProxy高可用）

# /etc/keepalived/keepalived.conf

global_defs {
    router_id lb01
}

vrrp_instance VI_1 {
    state MASTER # MASTER或BACKUP
    interface eth0
    virtual_router_id 52
    priority 100 # MASTER优先级高于BACKUP
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 2222
    }

    virtual_ipaddress {
        192.168.1.200/24 dev eth0 label eth0:0 # HAProxy的VIP
    }

    track_script {
        chk_haproxy
    }
}

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy" # 检查haproxy进程是否存在
    interval 2
    weight -20
}

配置完Keepalived后，记得在两台服务器上都启动Keepalived服务。通过这种方式，即使一台负载均衡器宕机，服务也能快速恢复，大大提升了系统的可用性。

LVS的几种工作模式及其特点是什么？

LVS提供了三种主要的工作模式，每种模式都有其独特的优点和适用场景。在我看来，理解这些模式对于优化你的负载均衡方案至关重要。

NAT模式（Network Address Translation）
- 原理：LVS Director作为所有请求的入口和出口。客户端请求到达Director，Director修改数据包的目标IP地址为Real Server的IP，然后转发给Real Server。Real Server处理完请求后，将响应发回给Director，Director再将响应的源IP地址修改为自己的IP，最后发回给客户端。
- 特点：
  - 简单易用：配置相对简单，Real Server可以是任何操作系统，无需特殊配置。
  - Real Server可位于私有网络：Real Server可以与Director不在同一子网，甚至可以位于NAT后面的私有IP地址空间。
  - Director可能成为瓶颈：所有请求和响应流量都必须经过Director，当流量较大时，Director的带宽和处理能力可能成为瓶颈。
- 适用场景：流量不是特别大，或者Real Server分布在不同网络环境中的情况。
DR模式（Direct Routing）
- 原理：这是我最常用也是最推荐的LVS模式，尤其是在Web服务场景。客户端请求到达Director，Director只修改数据包的目标MAC地址为选定的Real Server的MAC地址，然后将数据包直接发送给Real Server。Real Server处理完请求后，直接将响应发回给客户端，不再经过Director。
- 特点：
  - 高性能、高吞吐：Director只处理入站请求，响应流量不经过Director，极大地减轻了Director的负担，提高了整体吞吐量。
  - Real Server必须与Director在同一物理网络（或二层可达）：因为是基于MAC地址转发。
  - 需要解决ARP问题：Real Server需要配置VIP在回