HAProxy 安装与介绍

袁勤 · 2025-5-31 23:16:59

HAProxy（High Availability Proxy）是一款使用C语言编写的，高性能的开源负载均衡器和代理服务器软件，专为TCP（L4）和HTTP（L7）应用而设计。它可以将客户端的请求分发到多台后端服务器，从而提高应用的可用性和性能。HAProxy支持多种负载均衡算法和健康检查机制，是构建高可用性系统的理想选择。

LB（Load Balance，负载均衡）：是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均衡将特定的业务（web服务、网络流量等）分担给指定的一个或多个后端特定的服务器或设备，从而提高了公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展。
OSI 网络七层模型（OSI：Open System Interconnection, 开放系统互联）

根据 OSI模型可将负载均衡分为：

二层负载均衡（mac）：一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应；
三层负载均衡（ip）：一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应；
四层负载均衡（tcp）：在三层负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器；（如：F5，lvs，nginx，haproxy）
七层负载均衡（http）：根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器。（如：haproxy，nginx，apache）

负载均衡模型介绍

无负载平衡：没有负载平衡的简单Web应用程序环境，如下所示

示例中，用户直接连接到您的Web服务器，在 yourdomain.com 上，并且没有负载平衡。可能遇到的问题：
- 如果单个Web服务器出现故障，用户将无法再访问您的Web服务器。
- 如果许多用户试图同时访问您的服务器，并且无法处理负载，他们可能会遇到缓慢的体验，或者可能根本无法连接。
四层负载平衡：根据IP范围和端口转发用户流量
将网络流量负载平衡到多个服务器的最简单方法是使用第4层（传输层）负载平衡。

示例中，用户访问负载均衡器，负载均衡器将用户的请求转发给后端服务器的Web后端组。
- 无论选择哪个后端服务器，都将直接响应用户的请求。
- 通常，Web后端中的所有服务器应该提供相同的内容（否则用户可能会收到不一致的内容）。
七层负载平衡：根据用户请求的内容将请求转发到不同的后端服务器
七层负载平衡是更复杂的负载均衡，这种模式是使用第7层（应用层）负载均衡。它允许您在同一域和端口下运行多个Web应用程序服务器。

示例中，如果用户请求 yourdomain.com/blog，则会将其转发到博客后端，后端是一组运行博客应用程序的服务器。其他请求被转发到web-backend，后端可能正在运行另一个应用程序。

四层和七层负载均衡的区别：

四层的负载均衡：通过发布三层的IP地址(VIP)，然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
七层的负载均衡：在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡

一、介绍

HAProxy 是一款 TCP/HTTP 反向代理负载均衡服务器软件，可工作在OSI模型中的 "四层传输层" 以及 "七层应用层"。
HAProxy特别适用于那些负载压力大的web站点，这些站点通常需要 "会话保持" 或 "七层处理"。
HAproxy允许用户定义多组服务代理，代理由前端和后端组成，前端定义了服务监听的IP及端口，后端则定义了一组服务器及负载均衡的算法。通过服务代理将流量由前端负载均衡至后端服务器节点上。
HAProxy的工作流程如下：

客户端发送请求到HAProxy的前端（frontend）。
前端根据配置的规则，选择合适的后端（backend）。
后端将请求分发到具体的服务器进行处理。
服务器处理请求并返回结果，通过后端和前端返回给客户端。

1.1 核心

负载均衡：拥有 L4 和 L7 两种负载均衡模式，支持多种负载均衡算法（如：RR/静态RR/LC/IP Hash/URI Hash/URL_PARAM Hash/HTTP_HEADER Hash等）。
会话保持：确保同一客户端的所有请求都分配到同一台服务器处理。对于未实现会话共享的应用集群，可根据 Hash 或者 cookies 方式实现会话保持。（如：source、Insert Cookie和Prefix Cookie等）
健康检查：通过定期检测服务器状态，动态调整服务器的可用性。支持 TCP、HTTP 两种后端服务器健康检查模式。
统计监控：接受访问特定端口实现服务监控（提供了基于Web的，并带有用户认证机制的统计信息页面，展现服务健康状态和流量数据）。
SSL卸载：可以解析 HTTPS 报文，并将请求解密为 HTTP 向后端服务器传输。
其他功能：
- 在 HTTP 请求或响应报文中添加、修改、删除头部信息；
- HTTP 请求重写与重定向；
- 根据访问控制路由或阻断请求。

1.2 优势

高性能: 采用异步事件驱动架构，能够高效处理大量并发连接。
高可用：通过健康检查和故障转移机制，确保服务的可靠性。
灵活性强：支持多种负载均衡算法和调度策略，适应不同的应用场景。
模块化: 支持多种模块扩展，如 HTTP、TCP、SSL/TLS 等。
丰富的功能：支持SSL终止、HTTP重写、压缩等多种功能。
简单易用: 配置语法简洁，易于上手。

点击了解《HAProxy 与 NGINX：全面比较》

二、安装

haproxy官网：https://www.haproxy.org/
2.1 yum 安装

sudo yum install haproxy -y
注意: yum 安装的 HAProxy 版本可能比较旧，建议使用编译安装方式获取最新版本。
2.2 rpm 包安装

从第三方网站下载 rpm 包进行安装，例如：https://pkgs.org/download/haproxy
注意: 下载 rpm 包时，请务必选择可靠的来源，并注意版本兼容性。
2.3 编译安装

<ol>安装依赖包
sudo yum install -y make gcc pcre pcre-devel bzip2-devel openssl openssl-devel
下载并编译安装

#下载安装包，并解压
wget https://www.haproxy.org/download/3.0/src/haproxy-3.0.9.tar.gz
tar -xzf haproxy-3.0.9.tar.gz
cd haproxy-3.0.9
#编译安装
make TARGET=linux-glibc USE_OPENSSL=1 USE_PCRE=1 USE_SYSTEMD=1
sudo make install PREFIX=/usr/local/haproxy
#创建软链接（可选）
sudo ln -s /usr/local/haproxy/sbin/haproxy /usr/sbin/

复制代码

TARGET：指定目标操作系统和内核版本。
- haproxy-2.x 及以下版本安装时：TARGET=linux2628 .（linux2628 表示目标是 Linux 系统，内核版本为 2.6.28 或更高版本。这个参数确保 HAProxy 在编译时针对特定的内核版本进行优化。）
- haproxy-3.x 版本安装时： TARGET=linux-glibc .
USE_OPENSSL=1：启用对 OpenSSL 的支持。这使得 HAProxy 能够处理 SSL/TLS 加密的流量。
- 如果你需要 HAProxy 支持 HTTPS 或其他加密协议，这个选项是必需的。
USE_PCRE=1：启用对 PCRE（Perl Compatible Regular Expressions）库的支持。PCRE 库用于支持正则表达式。
- 这对于 HAProxy 的一些高级功能（如基于 URL 的路由规则）是必要的。
USE_SYSTEMD=1：启用对 systemd 的支持。systemd 是一个系统和服务管理器，用于启动、停止和管理服务。
- 启用这个选项可以让 HAProxy 与 systemd 集成，从而更方便地管理 HAProxy 服务
PREFIX：指定的安装路径。

配置并验证

#创建服务用户
sudo useradd -r -M -s /sbin/nologin haproxy
#创建配置目录
sudo mkdir /etc/haproxy
sudo mkdir /var/lib/haproxy
#使用配置文件（可选）
sudo cp addons/ot/test/empty/haproxy.cfg /etc/haproxy
#验证 HAProxy 配置
sudo haproxy -f /etc/haproxy/haproxy.cfg -c
#启动测试
sudo haproxy -f /etc/haproxy/haproxy.cfg

复制代码

创建 HAProxy 服务文件

sudo tee /etc/systemd/system/haproxy.service <<-EOF
[Unit]
Description=HAProxy Load Balancer
After=syslog.target network.target
[Service]
Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid"
ExecStartPre=/usr/sbin/haproxy -f \$CONFIG -c -q
ExecStart=/usr/sbin/haproxy -Ws -f \$CONFIG -p \$PIDFILE
ExecReload=/usr/sbin/haproxy -f \$CONFIG -c -q
ExecReload=/bin/kill -USR2 \$MAINPID
KillMode=mixed
Restart=always
Type=notify
[Install]
WantedBy=multi-user.target
EOF

复制代码

action：主要操作模式 (必选其一)
- insert - HAProxy 主动插入一个新 Cookie
- prefix - 在应用已有的 Cookie 值前添加服务器标识
- rewrite - 完全重写应用设置的 Cookie (不推荐，可能破坏应用)
params：可选修饰参数
- indirect - 如果客户端已携带指定 Cookie，则不插入/修改
- nocache - 禁止代理 /CDN 缓存带有此 Cookie 的响应
- httponly - 设置 HttpOnly 标志，限制 cookie 只能通过 HTTP 访问（防止 JavaScript 访问）
- secure - 仅通过 HTTPS 传输 Cookie
- domain - 设置 Cookie 的作用域域名
- maxidle - 设置 Cookie 空闲过期时间（秒）
- maxlife - 设置 Cookie 绝对过期时间（秒）
- dynamic - 允许使用动态 Cookie 值
- attr - 设置额外的 Cookie 属性（如 SameSite）

server [:] [params ...]

name: 服务器在配置中的唯一标识名称
address: 服务器的 IP 地址或主机名
port: 服务器监听的端口（可选，默认使用 backend 定义的端口）
params: 可选的服务器参数
- 健康检查参数:
  - check: 启用健康检查（默认不检查），注意必须指定端口才能实现健康性检查
  - inter : 健康检查间隔（默认2000 ms，2s）
  - rise : 将服务器标记为"正常"所需连续成功检查次数（默认2s）
  - fall : 将服务器标记为"故障"所需连续失败检查次数（默认3s）
- 负载均衡参数:
  - weight : 服务器权重（用于加权轮询，默认1）
  - backup: 标记为备份服务器（仅当所有非备份服务器不可用时使用）
- 连接参数:
  - maxconn : 最大并发连接数，当连接数到达maxconn后，新连接会进入等待队列（默认0，即无限）
  - maxqueue : 最大队列长度，当队列已满后，新请求会发至此backend下的其他server（默认0，即无限）
- SSL/TLS 参数:
  - ssl: 启用 SSL/TLS 连接到后端
  - verify [none|required]: SSL 证书验证
- 其他参数：
  - cookie ：指定 server 每行的唯一标识（用于配合基于cookie的会话保持）
  - disabled：将后端服务器标记为"不可用状态"，即维护状态，除了持久模式

例子：

defaults
log global
log 127.0.0.1 local2
option httplog

复制代码

3.5 监听器配置（listen）

listen 是HAProxy配置中的一个重要部分，它允许在一个配置块中同时定义前端(frontend)和后端(backend)的设置，简化了配置过程，特别适用于简单的代理场景。
listen指令提供了一种简洁的方式来配置HAProxy，将前端和后端功能合并到一个配置块中，减少了配置文件的复杂性，特别适合不需要复杂路由规则的负载均衡场景。

对于简单场景，使用listen可以简化配置，不需要复杂的前端规则
对于复杂路由规则，仍建议使用分开的frontend和backend

listen语法结构

sudo tee /etc/rsyslog.d/haproxy.conf <<-EOF
\$ModLoad imudp
\$UDPServerRun 514
local2.* /var/log/haproxy.log
EOF

复制代码

例子:

#将 /etc/sysconfig/rsyslog 文件中的文件中的的配置为: SYSLOGD_OPTIONS="-c 2 -r -m 0"
sudo sed -i '/SYSLOGD_OPTION/c\SYSLOGD_OPTIONS="-c 2 -r -m 0"' /etc/sysconfig/rsyslog

复制代码

3.6 负载均衡调度算法

HAProxy负载均衡调度算法可以在HAProxy配置文件中设定。支持配置多组后端服务组，每个组可以分别指定一种调度算法。以下是HAProxy支持的几种调度算法。

在 HAProxy 中，负载均衡算法可以分为动态（Dynamic）和静态（Static）两大类，主要区别在于是否实时考虑后端服务器的状态（如连接数、响应时间等）。以下是分类说明及典型使用场景：

静态调度算法
静态算法在分配请求时不实时考虑后端服务器的当前负载状态，仅根据预设规则（如权重、哈希值）进行分发。
算法名称原理适用场景roundrobin（轮询，默认算法）按顺序依次将请求分发到后端服务器，循环往复。支持权重的运行时调整，支持慢启动（在刚启动时缓慢接收大量请求），仅支持最大4095个后端活动主机。后端服务器性能均匀，且无长连接影响。static-rr（加权轮询）类似 Round Robin，但支持为服务器分配权重（weight），权重高的服务器获得更多请求。服务器性能不一致时，通过权重分配流量。source（源地址哈希）根据客户端源 IP 的哈希值分配服务器，同源 IP 地址的请求固定分配到同一台服务器。需要会话保持（Session Persistence）的场景（如用户登录状态）。uri（URI 哈希）根据请求 URI 路径的哈希值分配服务器，相同 URI 的请求固定分配到同一台服务器。缓存优化（同一 URI 由同一服务器处理，提高缓存命中率）或需要固定 URI 到特定服务器的场景。url_param（URL 参数哈希）根据 URL 中的特定参数（如 ?session_id=xxx）哈希分配。（如果指定的参数没有值，则回退到轮询）需要基于特定参数保持会话（如用户 ID，保证同一用户ID的请求分配至同一服务节点）。first（首次可用）按服务器在列表中的顺序分配请求，直到服务器达到最大连接数后再切换到下一台。需要严格优先使用某台服务器的场景（如备份服务器）适合会话保持、缓存优化或服务器性能均匀的场景。例如：source（会话保持）、uri（缓存优化）、static-rr（权重分配）。
动态调度算法
动态算法会实时考虑后端服务器的状态（如连接数、响应时间等），动态调整流量分配。
算法名称原理适用场景leastconn（最少连接）优先将请求分配给当前连接数最少的服务器（可配合权重使用）。长连接或会话耗时差异较大的场景（如数据库、文件传输）。hdr（HTTP头哈希）根据客户端请求中的特定 HTTP 头字段（Header）计算哈希值，并将请求固定分配到同一台后端服务器。（如果指定的头字段不存在，则回退到轮询）需要自动规避高延迟或故障节点，优先选择响应快的服务器（如金融交易系统）。random（随机分配）随机选择（可配合权重使用），但结合服务器状态（如健康检查）调整。后端服务器数量多且性能接近。适合长连接、请求处理时间差异大或需自动容错的场景。例如：leastconn（数据库）、hdr（高可用 API）。

选择建议

会话保持：source、uri、url_param。
性能均衡：leastconn、static-rr。
简单公平：roundrobin、random。
动态调整：基于响应时间的算法。

根据实际业务需求（如会话、性能、缓存）和服务器特性（如权重、连接数）选择合适的算法。
3.6.1 hdr 负载均衡算法详解

hdr 是 HAProxy 中的一种动态负载均衡算法，它基于 HTTP 请求头（Header）的内容进行流量分发，常用于高级路由和会话保持场景。以下是详细说明：

算法原理
作用：根据客户端请求中的特定 HTTP 头字段（Header）计算哈希值，并将请求固定分配到同一台后端服务器。
核心机制：
- 提取指定的 HTTP 头（如 X-User-ID、Cookie 等）。
- 对头字段的值进行哈希计算，映射到后端服务器。
- 相同头值 → 同一服务器，实现会话保持（Session Persistence）。
配置语法
1. sudo systemctl restart rsyslog.service
2. sudo systemctl restart haproxy.service
复制代码
- ：要哈希的 HTTP 头字段（如 Cookie、X-Forwarded-For）。
- use_domain_only（可选）：仅对头字段中的域名部分哈希（适用于 Host 头）。
示例配置
1. # 全局参数的设置
2. global
3. # 日志配置
4. #log 127.0.0.1:514 local2 notice #定义全局日志输出目标和级别
5. log /dev/log local2 notice #local2是日志输出设备，日志级别设为 notice 或 info，避免 debug 影响性能
7. # 进程与安全
8. user haproxy #指定运行 HAProxy 的用户和组，也可使用uid，gid关键字替代之
9. group haproxy
10. chroot /var/lib/haproxy #切换根目录，增强安全性（默认 /）
11. #pidfile /var/run/haproxy.pid #设置进程 ID 文件路径（默认由系统管理，多实例隔离时，需为每个实例指定不同的 PID 文件）
12. daemon #以后台守护进程模式运行
14. # 性能调优
15. nbproc 4 #设置进程数（多核优化，建议与 CPU 核心数一致，默认 1）
16. maxconn 50000 #设置每个进程的最大连接数（默认 20000）
17. #ulimit-n 65536 #设置每个进程的最大文件描述符数（需 > maxconn，默认自动）
18. #spread-checks 5 #分散健康检查时间
20. # 统计与监控（未配置则禁用）
21. stats socket /var/lib/haproxy/stats [mode 660] [level admin] #启用统计套接字（文件路径，文件权限，访问权限）
22. stats timeout 30s #统计接口超时设置
24. # SSL/TLS 配置
25. ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 #默认 SSL 加密套件
26. ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 #默认 SSL 选项
27. tune.ssl.default-dh-param 2048 #DH 参数大小
28. # SSL 默认路径设置（可选）
29. ca-base /etc/ssl/certs #指定 CA (Certificate Authority) 证书的默认目录（引用时可以只写相对路径）
30. crt-base /etc/ssl/private #指定服务器证书和私钥的默认目录（在 bind 指令中引用证书时可以省略完整路径）
32. # 默认部分的定义
33. defaults
34. # 日志相关
35. mode http #设置代理模式（http七层|tcp四层|health健康检测，默认 tcp）
36. log global #使用全局日志配置
37. option httplog #启用详细的 HTTP 日志记录（httplog/tcplog）
38. option dontlognull #不记录空连接（如：健康检查日志等）
40. # HTTP选项
41. option forwardfor except 127.0.0.0/8 #在 HTTP 请求中添加 X-Forwarded-For 头，以便后端获取客户端的真实 IP 地址。
42. option http-server-close #是否保持长连接（http-keep-alive(默认)启用长连接、http-server-close：客户端启用长连接和 httpclose：禁用长连接）
43. #timeout http-keep-alive 10s #默认持久连接超时时间
44. option redispatch #当连接失败时，允许重新分发到其他服务器
45. retries 3 #HAProxy 会在连接后端服务器失败时，自动重试 3 次（请求级别的重试）；解决临时性网络抖动或后端服务器短暂不可用的问题。（默认 3）
46. #maxconn 3000 #设置前端的最大并发连接数（默认 2000）
47. #balance roundrobin #定义默认负载均衡算法（roundrobin（默认）, leastconn, source, uri, hdr, rdp-cookie 等）
49. # 超时设置
50. timeout connect 10s #客户端与服务器建立连接的最大超时时间
51. timeout client 1m #客户端发送数据的最大超时时间
52. timeout server 1m #服务器响应数据的最大超时时间
53. #timeout queue 1m #队列中请求的最大等待时间（默认 10s）
54. #timeout http-request 10s #HTTP请求完成的超时时间（默认 5s）
56. # 健康检查
57. option httpchk GET /healthURL # 启用 HTTP 健康检查，/healthURL 是检查server的uri，通常配置在backend中（默认使用tcp-check）
58. http-check expect status 200 # 设置状态码
59. #timeout check 10s #健康检查的最大超时时间（默认 5s）
60. default-server check inter 3s fall 3 rise 2 #定义后端服务器的默认参数
61. stats uri /haproxy #默认前端路径
62. stats auth admin:asd123 #默认认证信息（可以多个）
64. ##错误处理，定义返回给客户端的定制错误页面
65. #errorfile 400 /etc/haproxy/errors/400.http
66. #errorfile 403 /etc/haproxy/errors/403.http
67. #errorfile 503 /etc/haproxy/errors/503.http #自定义错误页面
68. #errorloc 503 http://www.example.com/maintenance.html #重定向到维护页面
70. # 定义一个名为 status 的部分
71. listen status
72. #bind *:8080 #可能同时监听 IPv4 和 IPv6（不推荐，不同版本兼容不一样）
73. bind 0.0.0.0:8080 #定义监听 IPv4
74. bind :::8080 v6only off #定义监听 IPv6，v6only off：允许 IPv4 映射到 IPv6
75. #mode http #定义代理模式（http|tcp）
76. #log global #继承 global中log的定义
77. stats realm Haproxy\ Statistics #设置统计页面认证时的提示内容
78. stats uri /admin?stats #定义访问统计页面的 URI（默认 /haproxy?stats）
79. stats auth admin:asd123 #设置统计页面认证的用户和密码（如果要设置多个，另起一行写入即可）
80. stats refresh 30s #设置页面自动刷新时间为 30s（默认不自动刷新）
81. stats hide-version #隐藏统计页面上的 haproxy 版本信息
82. #stats admin if TRUE #启用管理功能，允许你动态管理后端服务器（如上线/下线服务器、修改权重等）
83. #stats admin if { src 192.168.1.100 } #仅允许 192.168.1.100 管理（if 后面可以跟 ACL（访问控制列表））
85. # 定义一个名为 http_80_in 的前端部分
86. frontend http_80_in
87. bind 0.0.0.0:80 #http_80_in定义前端部分监听的套接字
88. mode http #定义代理模式（http|tcp）
89. #log global #继承global日志配置
90. #option httplog #详细日志（HTTP|TCP）
91. #option dontlognull #不记录空连接
92. # 启用X-Forwarded-For，在requests头部插入客户端IP发送给后端的server，使后端server获取到客户端的真实IP
93. #option forwardfor #添加X-Forwarded-For头
94. #option httpclose #关闭HTTP连接
95. #option redispatch #连接失败时重试其他服务器
97. #超时设置
98. #timeout client 30s #客户端超时
99. #timeout http-request 10s #HTTP请求超时
101. #HTTP相关配置
102. #http-request set-header X-Real-IP %[src]
103. #http-request set-header X-Forwarded-Proto https if { ssl_fc }
104. #http-request deny if { path /private } { src 192.168.1.0/24 }
106. #访问控制：acl + use_backend - 基于条件路由
107. # 定义一个名叫 is_server_dead 的acl，当后端的 static_sever 中存活机器数（基于HTTP请求状态码）小于1时会被到匹配
108. acl is_server_dead nbsrv(static_server) lt 1
109. # 定义一个名叫 is_php_web 的acl，匹配url以 .php 结尾的当请求（两种写法任选其一）
110. acl is_php_web url_reg /*.php$
111. #acl is_php_web path_end .php
112. # 定义一个名叫 is_static_web 的acl，匹配url以 .css/.jpg/.png/.jpeg/.js/.gif 结尾的当请求（两种写法任选其一）
113. acl is_static_web url_reg /*.(css|jpg|png|jpeg|js|gif)$
114. #acl is_static_web path_end .gif .png .jpg .css .js .jpeg
115. #如果满足策略 is_server_dead 时，则将请求交予后端 php_server
116. use_backend php_server if is_server_dead
117. use_backend php_server if is_php_web
118. use_backend static_server if is_static_web
120. #redirect prefix http://www.example.com code 301 if { hdr(host) -i example.com }
121. #redirect scheme https code 301 if !{ ssl_fc }
123. #默认后端
124. default_backend static_server
126. #定义一个名为 php_server 的后端部分
127. backend php_server
128. #mode http #设置为http模式
129. balance source #设置haproxy的调度算法为源地址hash
130. cookie SERVERID #允许向cookie插入SERVERID，每台服务器的SERVERID可在下面使用cookie关键字定义
131. option httpchk GET /test/index.php # 开启对后端服务器的健康检测，通过GET /test/index.php来判断后端服务器的健康情况
133. #server语法：server [:port] [param*]
134. server server_1 10.12.25.68:80 cookie s1 check inter 2000 rise 3 fall 3 weight 2
135. server server_2 10.12.25.72:80 cookie s2 check inter 2000 rise 3 fall 3 weight 1
136. server server_bak 10.12.25.79:80 cookie s3 check inter 1500 rise 3 fall 3 backup
138. #定义一个名为 static_server 的后端部分
139. backend static_server
140. mode http
141. option httpchk GET /test/index.html
142. server serv_1 10.12.25.83:80 cookie 3 check inter 2000 rise 3 fall 3
复制代码
核心特性与使用场景
- （1）会话保持（Session Persistence）：相同 HTTP 头值的请求始终分配到同一台服务器，如：
  - 需要保持用户登录状态（如基于 Cookie）。
  - 确保同一用户的请求由同一服务器处理（如购物车、游戏会话）。
- （2）灵活的路由控制：可基于任意 HTTP 头字段（如 User-Agent、Authorization）进行路由。
  - 示例：将移动端流量（User-Agent 包含 Mobile）导向特定服务器组。
- （3）动态哈希调整：后端服务器增减时，HAProxy 会自动重新计算哈希分布（类似一致性哈希）。
1. bind *:80 #监听所有IP的 80端口（不推荐，可能同时监听 IPv4 和 IPv6，不同版本兼容不一样）
2. bind 0.0.0.0:80 #监听所有 IPv4 地址
3. bind [::]:80 #监听所有 IPv6 地址
4. bind :::80 v6only off #同时监听IPv4和IPv6
5. bind 192.168.1.100:443 ssl crt /etc/haproxy/cert.pem #监听带SSL证书的HTTPS
复制代码
注意事项
- （1）HTTP 头必须存在
  - 如果指定的头字段不存在，HAProxy 会回退到轮询（Round Robin）。
  - 解决方案：使用 hdr_reg（正则匹配）或结合 ACL 规则确保头字段有效。
- （2）哈希冲突问题
  - 不同头值可能哈希到同一台服务器（概率低）。
  - 解决方案：增加后端服务器数量或调整哈希算法（如一致性哈希）。
- （2）性能开销
  - 计算哈希比静态算法（如 roundrobin）略高，但影响可忽略。
对比其他会话保持算法
算法依据适用场景灵活性hdr任意 HTTP 头字段需要精细路由或会话保持⭐⭐⭐⭐source客户端源 IP简单 IP 级会话保持⭐⭐uri请求 URI 路径缓存优化（如 CDN）⭐⭐⭐url_paramURL 查询参数（如 ?id=）基于参数的路由⭐⭐⭐

总结
hdr 的核心价值：通过 HTTP 头实现灵活的路由控制和会话保持，适合需要精细流量管理的场景。
推荐使用场景：

基于用户身份（如 Cookie、JWT）的会话保持。
多租户或 API 网关的流量隔离。
需要动态哈希调整的高可用架构。

3.7 健康检查（Health Check）

HAProxy 的健康检查（Health Check）是确保后端服务器（Backend Server）可用性的关键机制，通过定期检测服务器状态，自动将故障节点从负载均衡池中移除或重新加入。常见的健康检查类型包括TCP连接检查、HTTP请求检查等。

健康检查类型
1. acl <criterion> [flags] [operator] [value] ...
2. #定义一条ACL，ACL是根据数据包的指定属性条件，以指定表达式计算出的 true/false 值。如：
3. acl url_ms1 path_beg -i /ms1/
4. #定义了名为 url_ms1 的ACL，该ACL在请求uri中，以/ms1/开头的路径（-i忽略大小写）时为 true
复制代码
高级健康检查选项
1. frontend http_in
2. #disabled #禁用前端 http_in
3. bind *:80
4. #条件性禁用：disabled + acl
5. #当访问路径以 /maintenance 开头时，禁用整个前端
6. #acl maintenance_mode path_beg /maintenance
7. #disabled if maintenance_mode
8. #disabled if { file(/etc/haproxy/maintenance.flag) -m found }
9. #示例1：基于主机名的路由
10. acl host_web hdr(host) -i example.com #请求头部头部的 host 精确匹配 example.com
11. use_backend web_servers if host_web
12. use_backend api_servers if { hdr(host) -i api.example.com }
14. #示例2：基于URL路径的路由
15. acl path_images path_beg -i /images/ #请求路径以 /images/ 开始
16. use_backend image_servers if path_images
18. #示例3：基于HTTP方法的复杂条件
19. acl is_get method GET #get请求方式
20. acl is_post method POST #post请求方式
21. acl is_admin path_beg /admin/ #请求路径以 /admin/ 开始
22. acl valid_user hdr(X-User-Id) -m found #请求头部的 X-User-Id 完全匹配 found
23. use_backend admin_servers if is_admin valid_user
24. use_backend readonly_servers if is_get !is_admin
25. use_backend write_servers if is_post !is_admin
27. #示例4：基于源IP的路由
28. acl internal_network src 192.168.1.0/24 #匹配源IP地址
29. acl vpn_network src 10.0.0.0/8
30. use_backend internal_servers if internal_network
31. use_backend vpn_servers if vpn_network
33. #默认后端
34. default_backend default_servers
37. backend web_servers
38. backend api_servers
39. ...
40. backend default_servers
复制代码
监控与管理
- （1）日志记录
  健康检查日志需在 HAProxy 配置中启用：
  log 127.0.0.1 local0 notice
- （2）查看健康状态
1. # 禁用前端
2. echo "disable frontend http_front" | sudo socat stdio /var/run/haproxy/admin.sock
3. # 启用前端
4. echo "enable frontend http_front" | sudo socat stdio /var/run/haproxy/admin.sock
5. # 查看状态
6. echo "show stat" | sudo socat stdio /var/run/haproxy/admin.sock | grep http_front
复制代码
访问 http://:9000/haproxy_stats 查看服务器状态（颜色标记健康/故障）。
常见问题
- （1）误判（Flapping），如：服务器频繁被标记为故障又恢复。
  - 解决：调整 rise 和 fall 参数，增加检测稳定性。
- （2）检查路径不可达，如：HTTP 检查返回 404。
  - 解决：确保后端服务器提供正确的健康检查端点（如 /health）。
- （3）超时设置：调整超时时间避免误判
  - timeout check 10s

最佳实践

轻量级检查：使用专用低开销的检查端点（如 /health）。
隔离检查流量：避免健康检查影响业务流量。
结合容器化环境：在 Kubernetes/Docker 中，检查需兼容动态 IP 变化。

通过合理配置健康检查，HAProxy 可以显著提高服务的可靠性和容错能力。根据实际需求选择 TCP/HTTP 检查，并灵活调整参数以优化性能。

四、实例

frontend http-in
bind *:80
bind *:443 ssl crt /etc/ssl/certs/mydomain.pem
#示例1：HTTP到HTTPS重定向
redirect scheme https code 301 if !{ ssl_fc }
#示例2：路径重定向
redirect prefix /new/path code 301 if { path_beg /old/path/ }
#示例3：域名重定向
acl is_old_domain hdr(host) -i old.example.com
redirect prefix http://new.example.com code 301 if is_old_domain
#redirect prefix http://new.example.com code 301 if { hdr(host) -i old.example.com }
#示例4：域名重定向是否“保留路径”，原始请求：http://old.example.com/path/to/resource
#prefix - 保留路径，只重置协议和域名，重定向到：https://new.example.com/path/to/resource
redirect prefix https://new.example.com code 301 if { hdr(host) -i old.example.com }
#location - 丢弃路径，完全替换 URL，重定向到：https://new.example.com (丢失了原始路径)
redirect location https://new.example.com code 301 if { hdr(host) -i old.example.com }
#示例5：重定向是否保留参数，原始请求：http://example.com/old/path/?search=hello
#不使用 drop-query（默认），重定向到：http://example.com/new/path/?search=hello
redirect prefix /new/path code 301 if { path_beg /old/path/ }
#使用 drop-query，重定向到：http://example.com/new/path（?search=hello 被丢弃）
redirect prefix /new/path drop-query code 301 if { path_beg /old/path/ }
#示例6：添加尾部斜杠
redirect append-slash if { path_reg ^/path[^/]*$ }
#示例7：带条件的重定向
acl is_mobile hdr(User-Agent) -i -m reg (android|iphone|ipad)
redirect prefix http://m.example.com code 302 if is_mobile

复制代码

Via

https://www.cnblogs.com/bandaoyu/p/16752467.html
https://blog.csdn.net/qq_65017742/article/details/141099157

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册