一.负载均衡
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哈希提升缓存命中率。