当前位置：首页 > web >正文

haproxy的负载均衡集群搭建

web 2025/7/23 6:08:27

1.HAProxy 简介

HAProxy（High Availability Proxy）是一款开源的高性能 TCP/HTTP 负载均衡器和 反向代理软件，广泛应用于分发网络流量、提升系统可用性和扩展性。它支持：

四层（L4，传输层）和七层（L7，应用层）负载均衡。
多种负载均衡算法（如轮询、最小连接、哈希等）。
SSL/TLS 终止、健康检查、会话保持等高阶功能。
高并发、低延迟，适合大规模分布式系统。

1.1四层（L4） vs 七层（L7）负载均衡的区别

特性	四层负载均衡（L4）	七层负载均衡（L7）
工作层级	传输层（TCP/UDP）	应用层（HTTP/HTTPS等）
决策依据	基于 IP 地址、端口、协议（无内容解析）	基于 URL、HTTP头、Cookie、报文内容等
性能	更高（仅处理网络包，无应用层解析）	较低（需解析应用层协议，计算开销更大）
典型场景	数据库负载、游戏服务器、非 HTTP 流量	Web 服务器、API 网关、基于路径的路由
功能示例	端口转发、IP 哈希分发	URL 路由、主机名分发、SSL 终止、缓存加速
协议支持	TCP、UDP	HTTP、HTTPS、FTP、SMTP（需应用层协议支持）

1.2关键区别总结

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量

四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理

七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

1.分层位置:四层负载均衡在传输层及以下，七层负载均衡在应用层及以下

2.性能 :四层负载均衡架构无需解析报文消息内容，在网络吞吐量与处理能力上较高:七层可支持解析应用层报文消息内容，识别URL、Cookie、HTTP header等信息。、

3.原理 :四层负载均衡是基于ip+port;七层是基于虚拟的URL或主机IP等。

4.功能类比:四层负载均衡类似于路由器;七层类似于代理服务器。

5.安全性:四层负载均衡无法识别DDoS攻击;七层可防御SYN Cookie/Flood攻击

2.haproxy的基本配置信息

2.1 global全局配置段

global
log 127.0.0.1 local2 #定义全局的syslog服务器；日志服务器需要开启UDP协议，最多可以定义两个
chroot /var/lib/haproxy #锁定运行目录
pidfile /var/run/haproxy.pid #指定pid文件
maxconn 100000 #指定最大连接数
user haproxy #指定haproxy的运行用户
group haproxy #指定haproxy的运行组
daemon #指定haproxy以守护进程方式运行
# turn on stats unix socket
stats socket /var/lib/haproxy/stats #指定haproxy的套接字文件
nbproc 2 #指定haproxy的work进程数量，默认是1个
cpu-map 1 0 #指定第一个work绑定第一个cpu核心
cpu-map 2 1 #指定第二个work绑定第二个cpu核心
nbthread 2 #指定haproxy的线程数量，默认每个进程一个线程，此参数与nbproc互斥
maxsslconn 100000 #每个haproxy进程ssl最大连接数,用于haproxy配置了证书的场景下
maxconnrate 100 #指定每个客户端每秒建立连接的最大数量

2.2多进程和多线程配置信息

nbproc 2 #启用多进程
cpu-map 1 0 #进程和cpu核心绑定防止cpu抖动从而减少系统资源消耗
cpu-map 2 1 #2 表示第二个进程，1表示第二个cpu核心

多进程启用后，我们能看见haproxy启用了多个进程

开启多线程模式（多进程和多线程模式两者不能同时开启）

3.proxies配置

配置模块	作用	类比 Nginx	类比 LVS	是否必须	多实例
`defaults`	定义全局默认参数，作用于后续所有 `frontend`、`backend`、`listen`（可覆盖）。	`http` 块中的默认配置	无直接对应，类似全局默认规则	可选	可定义多个，无名或有名
`frontend`	声明前端服务（监听端口/域名），定义流量入口规则（如 ACL 路由）。	`server` 块（虚拟主机）	Director 的 VIP 服务集群	可选	可定义多个
`backend`	定义后端服务器组（真实服务器），配置负载均衡策略和健康检查。	`upstream` 块	Real Server (RS) 组	可选	可定义多个
`listen`	合并 `frontend` 和 `backend` 功能，简化配置（生产常用）。	`server` + `upstream` 组合	VIP 和 RS 合并配置	可选	可定义多个

3.1default配置

defaults
mode http #HAProxy实例使用的连接协议
log global #指定日志地址和记录日志条目的
syslog/rsyslog日志设备
#此处的 global表示使用 global配置段中设定的log值。
option httplog #日志记录选项，httplog表示记录与 HTTP会话相关的各种属性值
#包括 HTTP请求、会话状态、连接数、源地址以及连接时间等
option dontlognull #dontlognull表示不记录空会话连接日志
option http-server-close #等待客户端完整HTTP请求的时间，此处为等待10s。
option forwardfor except 127.0.0.0/8 #透传客户端真实IP至后端web服务器
#后在webserver中看日志即可看到地址透传信息
option redispatch #当server Id对应的服务器挂掉后，强制定向到其他健康的服务器，重发
option http-keep-alive #开启与客户端的会话保持
retries 3 #连接后端服务器失败次数
timeout http-request 10s #等待客户端请求完全被接收和处理的最长时间
timeout queue 1m #设置删除连接和客户端收到503或服务不可用等提示信息前的等待时间
timeout connect 120s #设置等待服务器连接成功的时间
timeout client 600s #设置允许客户端处于非活动状态，即既不发送数据也不接收数据的时间
timeout server 600s #设置服务器超时时间，即允许服务器处于既不接收也不发送数据的非动时间
timeout http-keep-alive 60s #session 会话保持超时时间，此时间段内会转发到相同的后端服务器
timeout check 10s #指定后端服务器健康检查的超时时间
maxconn 3000
default-server inter 1000 weight 3

4.haproxy负载均衡简单示例

4.1配置网络ip和realserver的服务

将提供服务的两台主机配置为192.168.182.121 和192.168.182.122 haproxy代理服务器ip为192.168.182.124

开启两台RS的nginx服务，并改写默认发布网页内容来验证haproxy的负载均衡；

4.2haproxy配置

在haproxy主机上下载该服务，配置主配置文件；

通过访问haproxy查看

4.3haproxy的状态页面配置

重启服务后，通过浏览器访问9999端口就可以查看haproxy的状态页面。

5.socat工具

socat简介：

对服务器动态权重和其它状态可以利用 socat工具进行调整，Socat 是 Linux 下的一个多功能的网络工

具，名字来由是Socket CAT，相当于netCAT的增强版.Socat 的主要特点就是在两个数据流之间建立双向

通道，且支持众多协议和链接方式。如 IP、TCP、 UDP、IPv6、Socket文件等

可以利用socat工具支持后端server参数的热更改（临时的更改，不会更改配置文件）

5.1热更改server的权重

利用socat工具查看，修改对应服务的权重

6.haproxy中各种算法

6.1静态调度算法

静态算法在运行时不会根据后端服务器的实时状态调整负载分配，仅依赖预先配置的权重或顺序。修改权重通常需要重启 HAProxy 才能生效。

1. roundrobin（轮询tcp/http）

特点：按顺序依次分配请求，每个服务器轮流接收流量。
权重支持：支持静态权重（weight），权重高的服务器获得更多请求。
适用场景：后端服务器性能相近，无需动态调整权重的环境。

2. static-rr（静态加权轮询tcp/http）

特点：类似于 roundrobin，但权重完全静态，运行时不可调整。
权重支持：仅支持固定权重（0 或 1），不支持动态修改。
适用场景：需要简单轮询且不依赖动态权重的场景。

3. first（首服务器优先tcp/http）

特点：优先使用第一个可用的服务器，直到其达到最大连接数后再切换到下一个。
权重支持：不支持权重。
适用场景：适用于需要固定优先级的场景（如主备模式）。

4. leastconn（最少连接数tcp/http）

静态模式：仅根据服务器当前的连接数分配请求，不考虑响应时间。
权重支持：支持权重，权重高的服务器能承载更多连接。
适用场景：长连接服务（如数据库、WebSocket），但静态模式不感知服务器负载变化。

5. source（源 IP 哈希tcp/http）

特点：基于客户端 IP 的哈希值固定分配请求到同一台服务器。
权重支持：不支持权重。
适用场景：需要会话保持（Session Persistence）的场景。

6. uri（URI 哈希http）

特点：根据请求 URI 的哈希值分配请求，相同 URI 始终分配到同一台服务器。
权重支持：不支持权重。
适用场景：缓存优化或需要相同 URI 固定访问同一后端。

7. url_param（URL 参数哈希http）

特点：根据指定的 URL 参数（如 ?user_id=xxx）分配请求。
权重支持：不支持权重。
适用场景：需要基于特定参数保持会话的场景。

8. hdr（HTTP 头部哈希 http）

特点：根据指定的 HTTP 头部（如 Cookie、User-Agent）分配请求。
权重支持：不支持权重。
适用场景：需要基于 HTTP 头部信息进行路由的场景。

6.2 动态调度算法

动态算法会实时监测后端服务器的状态（如响应时间、健康状态等），并动态调整流量分配。

1. leastconn（动态最少连接数）

动态模式：不仅考虑当前连接数，还结合服务器的健康状态和权重。
权重支持：支持动态权重调整。
适用场景：适用于动态调整流量的长连接服务。

2. random（随机选择）

动态模式：随机选择一台服务器，但会根据权重调整概率。
权重支持：支持权重。
适用场景：需要简单随机分配且支持权重的场景。

3. dynamic-rr（动态加权轮询）

特点：类似于 static-rr，但支持运行时动态调整权重（如通过 API）。
权重支持：支持动态权重。
适用场景：需要运行时调整权重的轮询场景。

4. agent-check（基于 Agent 检查的动态调整）

特点：通过外部 Agent 检查服务器状态，动态调整权重或健康状态。
权重支持：支持动态调整。
适用场景：需要自定义健康检查逻辑的环境。

5. dynamic-first（动态首服务器优先）

特点：类似于 first，但支持运行时调整服务器优先级。
权重支持：支持动态调整。
适用场景：主备模式但需要动态切换的场景。

6.3 动态静态算法对比

特性	静态算法	动态算法
运行时调整	❌ 不支持	✅ 支持
依赖服务器状态	❌ 不依赖	✅ 依赖
适用场景	简单负载均衡	智能负载均衡
典型算法	`roundrobin`, `static-rr`, `source`	`leastconn`, `random`, `dynamic-rr`

6.4 基于uri 哈希算法的配置

在访问一个网页地址时候，可以分为

左半部分：/<path>;<params>

整个uri：/<path>;<params>?<query>#<frag>

根据左半部分做hash一致性运算分配对应服务器

对应配置文件

添加多个页面以验证算法

访问结果：

7.基于cookie的会话保持

cookie只支持在七层代理，四层代理不支持cookie技术

配置信息

name： #cookie 的 key名称，用于实现持久连接
insert： #插入新的cookie,默认不插入cookie
indirect： #如果客户端已经有cookie,则不会再发送cookie信息
nocache： #当client和hapoxy之间有缓存服务器（如：CDN）时，不允许中间缓存器缓存cookie，
#因为这会导致很多经过同一个CDN的请求都发送到同一台后端服务器