【无标题】
Haproxy概述
是一款开源的负载均衡软件，同时支持四层（实现TCP的转发、以及端口映射）和七层（支持http的调度）的负载；可以根据ACL的访问控制将前端的请求调度到后端的服务器；和nginx一样，所有的流量都需要经过haproxy，并且haproxy本身是单进程模型，通过异步IO（事件方式）来处理连接，因此承载的并发量是很大的，也很稳定；同时还支持图形化资源监控，并且支持通用的负载均衡算法，比如轮循，加权轮循等
算法的特征：
1.部分算法支持动态调整权重（RR、leastconn和hash），不需要重启haproxy
2.算法支持慢启动
3.HASH的方式多样，几乎可以涵盖HTTP的头部信息，也就是可以对URL、客户端的来源、头部的文件信息，用户agent等进行hash计算
4.支持强一致性hash算法
haproxy的配置文件：
haproxy配置文件的路径是: /etc/haproxy/haproxy.cfg
HAProxy 配置文件由以下部分组成：
global
用于定义全局参数，属于进程级的配置，通常和操作系统配置有关
default
用于配置默认参数，这些参数可以被用到 frontend，backend，listen 组件
frontend
用于定义前端服务的配置。在 frontend 中配置 ACL 规则，可将请求定向到相关的 backend
backend
用来定义后端服务集群的配置，真实服务器，一个 backend 对应一个或者多个实体服务器
listen
常常用于状态页面监控，以及后端 server 检查，是 frontend 和 backend 的组合体
haproxy的日志配置
vim /etc/haproxy/haproxy.cfg
log 127.0.0.1 local2 info 指定rsyslog中日志的级别 info级别表示的是info以上的级别也就是包含错误、警告、严重错误日志
重启haproxy systemctl restart haproxy.service
vim /etc/rsyslog/rsyslog.conf 编写local2.info 日志存放的文件
$ModLoad imudp 加载UDP模块
$UDPServerRun 514 开启监听端口
local2.* /var/log/haproxy.log 指定日志类型和级别存放的文件 * 表示任意级别，当然也可以是local2.info
重启rsyslog服务 systemctl restart rsyslog.service
查看发现日志已更新
haproxy的负载均衡
haproxy的负载均衡算法:
| 算法名称 | 核心原理 | 适用场景 |
|---|---|---|
roundrobin | 默认算法，按权重轮询，支持动态调整权重 | 通用场景、后端性能相近的短连接服务 |
static-rr | 静态轮询，权重固定不可动态调整，性能略高 | 节点数量固定、无需动态调权的场景 |
leastconn | 分配给活跃连接数最少的服务器（支持权重） | 长连接场景（如数据库、API 接口） |
first | 按列表顺序分配，直到节点达最大连接数 | 优先利用特定节点资源的场景 |
source | 对客户端源 IP 哈希，固定会话到同一节点 | 需要会话粘性的场景（如电商购物车） |
uri | 对请求 URI 哈希，相同 URI 固定到同一节点 | 静态资源缓存场景（如 CDN、图片服务） |
url_param | 对 URL 指定参数哈希，基于参数保持会话粘性 | 依赖 URL 参数维持会话的场景 |
hdr( | 对指定 HTTP 头（如 Cookie）哈希，基于头粘滞 | 依赖 HTTP 头维持会话的场景 |
rdp-cookie | 对 RDP 协议 Cookie 哈希，保持远程桌面会话 | 远程桌面服务场景 |
leasttime | 结合活跃连接数与响应时间，选择最优节点 | 对响应时间敏感的场景（如支付接口） |
random | 随机选择服务器，可结合权重 / 连接数限制 | 分散负载、无粘性需求的高并发场景 |
修改配置文件后端服务器并配置负载均衡算法
重启服务后进行访问测试
Haproxy透传客户端真实 IP:
用客户机(192.168.31.5)访问haproxy
查看nginx上的日志，发现只显示haproxy的ip,无法知晓客户的来源
编辑 HAProxy 的配置文件，在其中添加 IP 透传相关配置项（该配置仅针对客户端 IP 生效，排除 HAProxy 自身的 IP）；使用 sed 命令查看并确认配置文件中已成功添加的透传配置内容；重启 HAProxy 服务使新增的配置生效。
重启 HAProxy 服务后，从客户机端访问 HAProxy，接着在 Nginx 服务器上查看日志，发现日志条目末尾新增了客户机的 IP 地址。
Haproxy的监控配置
vim /etc/haproxy/haproxy.cfg
listen stats
bind :9000 # 监听的端口号，可以根据需要修
mode http
stats enable
stats uri /stats # 访问统计页面的URI，可以自定义
stats realm Haproxy Statistics # 认证提示信息，可选
stats auth admin:password # 访问统计页面的用户名和密码，可选
通过浏览器查看监控页面
Haproxy ACL
Haproxy 通过ACL的规则，将用户的请求调度到后端指定的服务器组，Haproxy根据负载均衡的算法，在后端服务器中选择指定的后端提供服务
Haproxy ACL 的语法规则：
acl的格式：
acl acl的名称 acl的规则（理解为类别） 字符操作符 具体操作符 操作对象
acl
为自定义的规则名，可使用字母、数字和特殊符号，字母区分大小写
[flags]为条件标记位
[operator]为具体操作符
[
ACL的常用规则
请求来源控制访问：
acl source_ip src 192.168.1.10 （匹配ip地址）
acl source_ip src 192.168.1.0/24 （匹配网段）
请求方法控制：
acl allow_get method GET
acl allow_get method POST
域名访问控制:
acl allow_domain hdr(host) -i example.com (-i是忽略大小写)
URL请求来源进行访问控制：
acl php url_reg -i .php$ 使用正则匹配特定url格式,.php$ 任何以php结尾的文件
acl php path_end .php 直接指定URL的地址为.php结尾的文件
acl dir path /api/v1/ 匹配指定的路径
为ACL指定后端服务器：
use_backend 直接指定后端
use_backend backend_name [{if | unless} acl_name
default_backend 前端默认所使用的后端，不满足ACL时使用的后端
通过 HAProxy 的 ACL 规则实现基于源 IP 的流量分发
当请求的源 IP 为 192.168.31.11 时，将流量转发至 test_back 后端服务器集群
其他所有 IP 的请求，默认转发至 http_back 后端服务器集群
重启haproxy后进行访问测试:
192.168.31.5进行访问测试，请求被默认转发至 http_back 集群（后端服务器端口为 80）
192.168.31.11进行访问测试，请求被 ACL 规则匹配并转发至 test_back 集群（后端服务器端口为 81）
为ACL指定跳转或者是允许限制访问
redirect location https://example.com/ if acl_name
当请求的源 IP 网段为 192.168.31.11 时，将流量转发至 https://www.baidu.com
其他所有 IP 的请求，默认转发至 http_back 后端服务器集群
浏览器访问测试
跳转至百度
http的拒绝与允许：
http-request deny if acl_name 拒绝一个acl的访问
http-request allow if acl_name 允许一个acl的访问
tcp的拒绝与允许：
客户端与服务器建立连接时进行判断：
tcp-request connection {accept | reject} [{if | unless} acl_name
服务端发送响应后进行判断：
tcp-response connection {accept | reject | close} [{if | unless} acl_name
haproxy端口映射配置
修改mode为tcp
Shh haproxy的8999端口会映射至后端nginx1服务器的22端口
ssh连接测试，成功登录nginx2(192.168.31.100)
在 HAProxy 配置中添加 ACL 规则，明确拒绝源 IP 为 192.168.31.11 的请求进行转发
从源 IP 为192.168.31.11的客户端发起 SSH 连接测试，结果为连接被 HAProxy 拒绝转发，无法成功建立连接，验证了 ACL 拦截规则已生效。
ACL逻辑关系
逻辑与： 默认所有的acl之间都是逻辑与的关系，因此逻辑与没有任何方式进行表示，两个条件需要同时满足
use_backend backend_name if aclname1 aclname2
逻辑或： 使用or来进行表示，只要满足两个条件中的任意一个即可
use_backend backend_name if aclname1 or aclname2
逻辑非： 使用!来进行表示，对acl进行取反
use_backend backend_name if !aclname
通过Haproxy 实现动静分离
Haproxy的节点 192.168.31.10
PHP的节点 192.168.31.100:81 这个节点专门处理php的文件
html的节点 192.168.31.101:81 这个节点专门处理静态网页文件
配置nginx1(192.168.31.100:81)php动态页面解析
安装php-fpm
修改虚拟主机配置文件
虚拟主机添加php解析配置段
配置完成后重启nginx
创建测试页面用于访问测试
haproxy配置
mode设置为http
监听服务器 8080 端口，根据请求路径后缀，将 .php 请求转发到 192.168.31.100:81 的 PHP 服务，将 .html 及其他请求转发到 192.168.31.101:81 的静态页面服务，并对后端节点进行健康检查以保障可用性。
配置完成后重启haproxy
测试验证
访问静态页面:
动态页面访问测试
负载均衡的对比特性
| 对比维度 | HAProxy | Nginx | LVS |
|---|---|---|---|
| 定位 | 专业四层 / 七层负载均衡器 | Web 服务器 + 反向代理 + 轻量负载均衡器 | 内核级四层负载均衡器（Linux 内核原生模块） |
| 工作层级 | 四层（TCP/UDP）+ 七层（HTTP/HTTPS） | 主要七层（HTTP/HTTPS），新版支持四层（TCP） | 仅四层（TCP/UDP） |
| 协议支持 | HTTP/HTTPS/TCP/UDP/HTTP2 等 | HTTP/HTTPS/TCP/UDP（有限支持） | TCP/UDP |
| 负载算法 | 轮询、最小连接、源地址哈希、URL 哈希、URI 参数哈希等（丰富） | 轮询、加权轮询、IP 哈希、最小连接等（基础） | 轮询、加权轮询、源地址哈希、目标地址哈希等（极简） |
| 性能特点 | 纯用户态，性能高（万级并发），适合中高负载场景 | 用户态，性能优秀（万级并发），兼顾静态资源服务 | 内核态转发，性能极高（百万级并发），无用户态开销 |
| 核心功能 | 会话保持、七层规则路由、精细健康检查（四层 + 七层）、统计面板、流量镜像 | 静态资源服务、反向代理、缓存、七层路由、基础健康检查 | DR/NAT/TUN 三种转发模式，依赖 Keepalived 实现高可用，功能极简 |
| 健康检查 | 支持四层（端口检测）+ 七层（HTTP 状态码、内容检测） | 支持四层（TCP）+ 七层（HTTP）基础检查 | 仅四层端口检测，需依赖 Keepalived 等工具增强 |
| 适用场景 | 复杂七层流量控制、需精细健康检查的业务（如电商、支付） | Web 服务静态资源分发 + 反向代理 + 轻量负载均衡（如中小站点） | 超大规模并发、仅需四层转发的核心业务（如金融、运营商） |
| 部署复杂度 | 中等（配置灵活，需理解规则逻辑） | 简单（配置直观，生态成熟） | 较高（需理解内核模式，依赖 Keepalived 实现高可用） |
