目录
一、案例分析
1.案例概述
Haproxy 是目前比较流行的一种群集调度工具，同类群集调度工具有很多如 LVS 和 Nginx。相比较而言，LVS 性能最好，但是搭建相对复杂;Nginx 的upstream 模块支持群集功能，但是对群集节点健康检查功能不强，高并发性能没有 Haproxy 好。Haproxy 官方网站是 http://www.haproxy.org/。
本案例介绍使用 Haproxy 及 Nginx 搭建一套 Web 群集。
2.案例前置知识点
2.1 HTTP请求
通过 URL 访问网站使用的协议是 HTTP 协议，此类请求一般称为 HTTP 请求。HTTP 请求的方式分为GET方式和 POST 方式。当使用浏览器访问某一个URL,会根据请求 URL 返回状态码,通常正常的状态码为 2xx、3xx(如 200、301)，如果出现异常会返回 4xx、5xx(如 400、500)。
例如，访问 http://www.test.com/a.php?Id=123，就是一个 GET 请求，如果访问正常，会从服务器的日志中获取 200状态码。假如此请求使用 POST 方式，那么传递给 a.php 的 Id 参数依旧是 123，但是浏览器的 URL 将不会显示后面的 Id=123 字样，因此表单类或者有用户名、密码等内容提交时建议使用POST 方式。不管使用哪种方式，最终 a.php 获取的值是一样的。
2.2 负载均衡常用调度算法
LVS、Haproxy、Nginx 最常用的调度算法有三种，如下所述。
- RR(Round Robin)。RR 算法是最简单最常用的一种算法，即轮询调度。例如，有三个节点 A、B、C，第一个用户访问会被指派到节点 A，第二个用户访问会被指派到节点 B，第三个用户访问会被指派到节点C，第四个用户访问继续指派到节点 A,轮询分配访问请求实现负载均衡效果。此算法还有一种加权轮询，即根据每个节点的权重轮询分配访问请求。
- LC(Least Connections)。LC 算法即最小连接数算法，根据后端的节点连接数大
小动态分配前端请求。例如，有三个节点 A、B、C，各节点的连接数分别为 A:4、B:5、C:
6，此时如果有第一个用户连接请求，会被指派到 A上，连接数变为 A:5、B:5、C:6;第二个用户请求会继续分配到 A 上，连接数变为 A:6、B∶5、C:6:再有新的请求会分配给 B，每次将新的请求指派给连接数最小的客户端。由于实际情况下 A、B、C的连接数会动态释放，很难会出现一样连接数的情况，因此此算法相比较 rr 算法有很大改进，是目前用到比较多的一种算法。 - SH(Source Hashing)。SH 即基于来源访问调度算法，此算法用于一些有Session 会话记录在服务器端的场景，可以基于来源的 IP、Cookie 等做群集调度。例如，使用基于源 IP 的群集调度算法，有三个节点 A、B、C，第一个用户第一次访问被指派到了 A，第二个用户第一次访问被指派到了 B，当第一个用户第二次访问时会被继续指派到 A，第二个用户第二次访问时依旧会被指派到B，只要负载均衡调度器不重启，第一个用户访问都会被指派到 A，第二个用户访问都会被指派到 B,实现群集的调度。此调度算法好处是实现会话保持，但某些IP访问量非常大时会引起负载不均衡，部分节点访问量超大，影响业务使用。
2.3常见的Web群集调度器
目前，常见的 Web 群集调度器分为软件和硬件。软件通常使用开源的 LVS、Haproxy、 Nginx，硬件一般使用比较多的是 F5。也有很多人使用国内的一些产品，如梭子鱼、绿盟等。
3.案例环境
3.1本案例环境
本案例使用三台服务器模拟搭建一套 Web 群集，具体的拓扑如图所示。案例环境如表所示
| 主机 | 操作系统 | IP 地址 | 应用 |
|---|---|---|---|
| nginx1 | openEuler 24.03 | 192.168.10.101 | apache |
| nginx2 | openEuler 24.03 | 192.168.10.102 | apache |
| haproxy | openEuler 24.03 | 192.168.10.103 | haproxy |
二、案例实施
1.搭建两台web服务器
为了方便实验，网站没有配置域名，直接使用IP地址。在客户端访问http://192.168.10.102/test.html 测试
2.安装Haproxy
3.haproxy服务器配置
修改haproxy的配置文件
Haproxy 配置项介绍:
Haproxy 配置文件通常分为三个部分，即 global、defaults 和 listen。
global 为全局配置，defaults 为默认配置，listen 为应用组件配置。
- global部分-全局配置
global
log 127.0.0.1 local2 # 日志输出到本地127.0.0.1的syslog的local2设施
chroot /var/lib/haproxy # 改变根目录到/var/lib/haproxy，增强安全性
pidfile /var/run/haproxy.pid # 指定pid文件位置
user haproxy # 以haproxy用户身份运行
group haproxy # 以haproxy组身份运行
daemon # 以守护进程方式运行
maxconn 4000 # 最大连接数4000- defaults 部分 - 默认参数
defaults 配置项配置默认参数，一般会被应用组件继承，如果在应用组件中没有特别声明，将按照默认配置参数设置。
defaults
mode http # 默认模式为HTTP(七层代理)
log global # 继承global部分的日志配置
option httplog # 启用HTTP日志格式
option dontlognull # 不记录空连接日志
retries 3 # 失败后重试3次
timeout http-request 5s # HTTP请求超时时间5秒
timeout queue 1m # 请求在队列中的最长等待时间1分钟
timeout connect 5s # 连接后端服务器的超时时间5秒
timeout client 1m # 客户端不活动超时时间1分钟
timeout server 1m # 服务器端不活动超时时间1分钟
timeout http-keep-alive 5s # HTTP keep-alive超时时间5秒
timeout check 5s # 健康检查超时时间5秒
maxconn 3000 # 默认最大连接数3000- listen 部分 - 定义前端和后端
listen myweb # 定义一个名为myweb的监听服务(同时包含前端和后端)
bind 0.0.0.0:80 # 监听所有IP的80端口
option httpchk GET /index.html # 使用HTTP GET /index.html进行健康检查
balance roundrobin # 使用轮询(round-robin)负载均衡算法
server inst1 192.168.10.102:80 check inter 2000 fall 3 # 后端服务器1，IP:192.168.10.102:80，启用健康检查，检查间隔2秒，3次失败标记为不可用
server inst2 192.168.10.103:80 check inter 2000 fall █ # 后端服务器2，IP:192.168.10.103:80，启用健康检查，检查间隔2秒，█处应为失败次数(如3)4.测试web群集
通过上面的步骤，已经搭建完成 Haproxy 的 Web 群集，接下来需要验证群集是否工作正常。一个群集一般需要具备两个特性，第一个是高性能，第二个是高可用。
- 测试高性能
在客户端访问网站显示信息 ：
- 测试高可用
现在将192.168.10.102的Nginx服务停用，在客户端使用浏 览器打开 http://192.168.10.103/test.html，浏览器显示信息仍然更之前一样。
从中可以看出，当一台节点故障，不会影响群集的使用，这样就满足了群集的高可用性。也可以将 192.168.10.102的 Nginx 服务恢复，再将192.168.10.103 的 Nginx 服务停用，测试高可用性。
5.haproxy的日志
Haproxy 的日志默认输出到系统的 syslog 中，查看起来不是非常方便，为了更好地管理 Haproxy 的日志，在生产环境中一般单独定义出来，定义的方法如下所述。
- 修改 haproxy 配置文件，将原有的配置更改为以下配置:
[root@localhost ~]# vim /etc/haproxy/haproxy.cfg global log /dev/log local0 info # 修改log配置，使用local0设备记录info级别日志 #chroot /var/lib/haproxy # 注释掉chroot项（取消chroot限制） - 配置 Rsyslog 服务
[root@localhost ~]# vim /etc/rsyslog.d/99-haproxy.conf # 捕获local0设备的日志，写入/var/log/haproxy.log local0.* /var/log/haproxy.log - 创建日志文件并设置权限
[root@localhost ~]# touch /var/log/haproxy.log [root@localhost ~]# chmod 640 /var/log/haproxy.log [root@localhost ~]# chown root:adm /var/log/haproxy.log - 重启Rsyslog和 HAProxy 服务
[root@localhost ~]# systemctl restart rsyslog [root@localhost ~]# systemctl restart haproxy - 测试日志信息。
在客户端访问 http://192.168.10.103/test.html 后，可以使用 tail -f/var/log/haproxy.log 即时査看 Haproxy 的访问请求日志信息。
[root@localhost ~]# tail -f /var/log/haproxy.log
Apr 11 22:06:20 localhost happyxy[2701]: 192.168.10.1:54483 [11/Apr/2025:22:06:20.941] webcluster webcluster/inst2 0/0/0/1/1 200 221 -- --- 2/2/0/0/0 0/0 "GET /test.html HTTP/1.1"
Apr 11 22:06:20 localhost happyxy[2701]: 192.168.10.1:54483 [11/Apr/2025:22:06:20.981] webcluster webcluster/inst1 0/0/0/1/1 404 3603 -- --- 2/2/0/0/0 0/0 "GET /favicon.ico HTTP/1.1"6.haproxy的参数优化
关于 Haproxy 的参数优化，以下列举了几个关键的参数，并对各参数的生产环境的优化 建议做了说明，如表下表所示。
| 分类 | 参数 | 说明 | 优化建议 | 注意事项 |
|---|---|---|---|---|
| 全局参数 | maxconn | 最大并发连接数 | - 推荐值：10240 - 根据服务器内存调整（每连接约占用10-20KB内存） |
defaults段的值必须 ≤ global段的值 |
| daemon | 守护进程模式 | 生产环境必须启用 | 非守护进程模式仅用于调试 | |
| nbproc | 工作进程数 | 等于CPU核数（如16核）或2倍（如32核） | 每个进程独立处理连接，需配合maxconn分配 | |
| 重试策略 | retries | 节点健康检查重试次数 | - 高并发集群：2-3次 - 小型集群：5-6次 |
过多重试会增加故障检测延迟 |
| HTTP优化 | option http-server-close | 主动关闭后端HTTP连接 | 生产环境建议启用 | 可减少服务端连接堆积，但会增加TCP握手开销 |
| timeout http-keep-alive | 长连接保持时间 | - 动态内容：10s - 静态资源：30-60s |
需与应用特性匹配 | |
| timeout http-request | HTTP请求超时 | 5-10s（敏感业务可延长至15s） | 过短会导致慢请求失败 | |
| timeout client | 客户端超时 | - 常规：1min - 高并发：30s |
影响文件上传等长耗时操作 | |
| 高级优化 | timeout connect | 后端连接超时 | 5-10s（跨机房部署可延长） | 需大于网络延迟 |
| timeout server | 后端响应超时 | 根据应用响应时间调整（建议≥平均响应时间的3倍） | 过短会导致正常响应被中断 |
总结
HAProxy作为一款高性能且功能强大的开源负载均衡与代理服务器软件，在运维领域发挥着至关重要的作用。它凭借高效的请求转发机制、灵活的负载均衡算法(如轮询、最少连接、源地址哈希等)，能够智能地将客户端请求分配到后端多台服务器，有效提升系统整体性能与可用性;支持TCP和HTTP(S)等多种协议，适配各类应用场景，无论是 Web 服务、数据库代理还是 API网关等都能轻松应对;具备完善的健康检查功能，可实时监测后端服务器状态，自动隔离故障节
点，确保服务连续性;同时，其丰富的配置选项与动态重载能力，让运维人员能够根据业务需求灵活调整策略，且无需中断服务。在实际运维工作中，熟练掌握HAProxy 的部署、配置、监控与优化技巧，对于构建稳定、高效、可扩展的系统架构具有不可忽视的意义。