一.负载均衡

1.1.什么是负载均衡

负载均衡：Load Balance，简称LB，是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均

衡将特定的业务(web服务、网络流量等)分担给指定的一个或多个后端特定的服务器或设备，从而提高了

公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展

阿里云SLB介绍 ：https://yq.aliyun.com/articles/1803

1.2.为什么用负载均衡

Web服务器的动态水平扩展-->对用户无感知

增加业务并发访问及处理能力-->解决单服务器瓶颈问题

节约公网IP地址-->降低IT支出成本

隐藏内部服务器IP-->提高内部服务器安全性

配置简单-->固定格式的配置文件

功能丰富-->支持四层和七层，支持动态下线主机

性能较强-->并发数万甚至数十万

1.3.负载均衡类型

1.3.1硬件：

F5 美国F5网络公司 https://f5.com/zh

Netscaler 美国思杰公司 https://www.citrix.com.cn/products/citrix-adc/、

Array 华耀 https://www.arraynetworks.com.cn/
AD-1000 深信服 深信服 - 让每个用户的数字化更简单、更安全

1.3.2.四层负载均衡

1.通过ip+port决定负载均衡的去向。

2.对流量请求进行NAT处理，转发至后台服务器。

3.记录tcp、udp流量分别是由哪台服务器处理，后续该请求连接的流量都通过该服务器处理。

4.支持四层的软件

lvs：重量级四层负载均衡器。

Nginx：轻量级四层负载均衡器，可缓存。（nginx四层是通过upstream模块）

Haproxy：模拟四层转发。

1.3.3.七层负载均衡

1.通过虚拟ur|或主机ip进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡。

2.代理后台服务器与客户端建立连接，如nginx可代理前后端，与前端客户端tcp连接，与后端服务器建立

tcp连接,

3.支持7层代理的软件：

Nginx:基于http协议(nginx七层是通过proxy_pass)

Haproxy:七层代理，会话保持、标记、路径转移等。

1.3.4 四层和七层的区别

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

四层的负载均衡，就是通过发布三层的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攻击

二.haproxy简介

HAProxy是法国开发者 威利塔罗(Willy Tarreau) 在2000年使用C语言开发的一个开源软件

是一款具备高并发(万级以上)、高性能的TCP和HTTP负载均衡器

支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计

企业版网站：https://www.haproxy.com

社区版网站：http://www.haproxy.org

github：https://github.com/haprox

企业版本和社区版功能对比

三.haproxy的安装和服务信息

3.1.实验环境

功能                    IP

Client                 eth0：172.,25.254.140

haproxy               eth0：172.25.254.134

RS1                     eth0：172.25.254.137

RS2                     eth0：172.25.254.138

3.2.软件安装

软件包下载地址

https://github.com/haproxy/wiki/wiki/Packages

安装软件包：

[root@haproxy ~]# dnf install haproxy -y

查看版本

[root@haproxy ~]# haproxy -v

关闭防火墙

[root@haproxy ~]# systemctl disable --now firewalld

haproxy软件基本信息

3.3.haproxy的基本配置信息

官方文档：http://cbonte.github.io/haproxy-dconv/

HAProxy 的配置文件haproxy.cfg由两大部分组成，分别是：

global：全局配置段

进程及安全配置相关的参数

性能调整相关参数

Debug参数

proxies：代理配置段

defaults：为frontend, backend, listen提供默认配置

frontend：前端，相当于nginx中的server {}

backend：后端，相当于nginx中的upstream {}

listen：同时拥有前端和后端配置,配置简单,生产推荐使用

RS1/2配置

访问侧式

环境搭建完成

1.3 线程与CPU核心绑定

原因

HAProxy默认以单线程模式运行，但现代版本支持多线程（通过nbthread参数配置）。线程绑定的核心目的和优势包括：

性能优化：将线程绑定到特定CPU核心（通过cpu-map配置），减少上下文切换开销，提升缓存命中率，尤其在高并发场景下显著降低延迟。

资源隔离：避免线程在不同核心间迁移导致的性能波动，确保关键流量处理的稳定性。

NUMA架构适配：在多处理器NUMA系统中，绑定线程到本地内存节点可减少跨节点访问延迟。

通过配置nbproc和cpu-map实现进程与CPU核心的绑定。

global

    nbthread 4  # 启用4个工作线程

    cpu-map 1 0  # 线程1绑定到CPU核心0

    cpu-map 2 1  # 线程2绑定到CPU核心1

    cpu-map 3 2  # 线程3绑定到CPU核心2

cpu-map 4 3  # 线程4绑定到CPU核心3

绑定后减少线程跨核心切换的开销，提升处理效率，适用于高并发场景

#添加多线程

1.vim /etc/haproxy/haproxy.cfg

2.修改完重启文件件 systemctl restart haproxy

进程会在下面多n个

2.通过文件配置具体内容

2.1前端（Frontend）监听

Haproxy配置前端监听特定端口（如80或443），接收客户端请求。前端定义访问控制、SSL证书等参数

每次修改完文件后都要重启服务systemctl restart haproxy

负载均衡算法的具体配置

静态负载均衡算法

采用“慢更新”策略：先给一点点访问压力，当没问题后在给一部分

服务器加入时逐步增加负载，但权重固定不可动态调整。

适用场景：服务器性能差异小且负载稳定。

缺点：灵活性低，无法适应突发流量或服务器性能变化。

动态负载均衡算法

roundrobin（轮询）

根据权重比例分配请求，结合实时LVS负载计算最优目标服务器，谁的值小就给谁

• 支持动态权重调整（无需重启）。
• 适用场景：服务器性能差异大或负载波动频繁。

文件配置：

先将这部分全部注释掉

然后添加 roundrobin（轮询）配置

测试访问是否是轮询、

leastconn（最小连接数）

优先分配请求给当前连接数最少的服务器，权重高的服务器在连接数相近时优先。

支持动态权重调整。

适用场景：长连接服务（如数据库）。

重启之后访问测试

第二种修改权重的方法：

source（源地址哈希）

根据客户端IP哈希固定分配请求到同一服务器。

优点：会话保持。

缺点：服务器故障时影响所有关联客户端。

重启，访问

发现链接只打在一台主机上

map-base（取模）

总结：对主机标识取模分配请求，服务器故障需全局重新计算。

主机有数字，该数字除以服务器的个数然后取余，余数跟对应的服务器建立链接，挂了一台服务器算法就得重新计算链接

如果有一台主机（服务器）挂科了，所有主机都要重新建立VIP

适用场景：服务器数量固定且故障率低。

这个可以和其他算法共存

一致性hash

一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash（o） mod n

该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动

算法：

1、后端服务器哈希环点keyA=hash(后端服务器虚拟ip)%(2^32)

2、客户机哈希环点key1=hash(client_ip)%(2^32) 得到的值在[0---4294967295]之间

3、将keyA和key1都放在hash环上，将用户请求调度到离key1最近的keyA对应的后端服务器

hash环偏斜问题

增加虚拟服务器IP数量，比如：一个后端服务器根据权重为1生成1000个虚拟IP，再hash。而后端服务器权 重为2则生成2000的虚拟IP，再bash,最终在hash环上生成3000个节点，从而解决hash环偏斜问题

hash对象

Hash对象到后端服务器的映射关系：

一致性hash示意图

后端服务器在线与离线的调度方式

URI哈希

基于请求URI哈希分配，相同URI指向同一服务器。

仅支持HTTP模式（mode http）。

适用场景：静态资源缓存优化。

此时可以通过VIP访问两个服务器对应的index

url_param（URL参数哈希）

根据指定URL参数（如user_id）哈希分配请求。

适用场景：需按业务参数保持会话一致性。

重启服务

访问出现的都是同一个

hdr(User-Agent)（用户代理哈希）

根据请求头中的User-Agent分配请求。

适用场景：针对不同客户端类型差异化处理。

现在我们访问的都是同一个页面

指定浏览器，就可以保证访问该浏览器时出现固定的页面

Cookie会话保持

通过cookie或stick-table实现会话粘滞，确保用户请求始终指向同一后端服务器。

适用场景：登录态等强会话依赖服务。

backend web_backend

  balance roundrobin

  cookie SERVERID insert nocache

  server server1 192.168.1.10:80 cookie s1 check

  server server2 192.168.1.11:80 cookie s2 check

bash

动态权重调整

# 动态修改服务器权重（需启用stats socket）

echo "set server backend/server1 weight 50" | sudo socat stdio /var/run/haproxy.sock

动态配置与ACL规则

使用ACL（访问控制列表）实现高级路由，例如按路径、域名或Header分流。

frontend web_front

  bind *:80

  acl path_blog path_beg /blog

  use_backend blog_backend if path_blog

  default_backend web_backend

以上算法可根据实际业务需求组合使用，例如：

电商场景：source + Cookie保证会话一致性。

CDN加速：URI哈希提升缓存命中率。