HAProxy全站最详细！从入门到精通！！理论+实践=王炸！！！

负载均衡

定义

负载均衡：Load Balance，简称LB，是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均衡将特定的业务(web服务、网络流量等)分担给指定的一个或多个后端特定的服务器或设备，从而提高了公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展。

为什么用负载均衡

HAProxy的作用实现负载均衡，将请求分发到多个服务器上，从而提高系统的可用性和性能。它可以根据不同的负载均衡算法（如轮询、加权轮询、IP哈希等）来分配请求，并支持会话保持、健康检查、SSL终止等功能。此外，HAProxy还可以实现反向代理、SSL加速、HTTP压缩等功能，使其成为一款功能强大的代理软件。

• Web服务器的动态水平扩展–>对用户无感知
• 增加业务并发访问及处理能力–>解决单服务器瓶颈问题
• 节约公网IP地址–>降低IT支出成本
• 隐藏内部服务器IP–>提高内部服务器安全性
• 配置简单–>固定格式的配置文件
• 功能丰富–>支持四层和七层，支持动态下线主机
• 性能较强–>并发数万甚至数十万

负载均衡类型

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

硬件负载均衡

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

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

Array 华耀 https://www.arraynetwaorks.com.cn/

AD-1000 深信服 http://www.sangfor.com.cn/

四层负载均衡

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

对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等），常见例子有：LVS，F5。

1. 通过ip+port决定负载均衡的去向。
2. 对流量请求进行NAT处理，转发至后台服务器。、
3. 记录tcp、udp流量分别是由哪台服务器处理，后续该请求连接的流量都通过该服务器处理。
4. 支持四层的软件
   • Ivs:重量级四层负载均衡器。
   • Nginx:轻量级四层负载均衡器，可缓存。(nginx四层是通过upstream模块)
   • Haproxy:模拟四层转发。

七层负载均衡

七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡：在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

​ 对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议，常见例子有： haproxy，MySQL Proxy。

1. 通过虚拟url或主机ip进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡。
2. 代理后台服务器与客户端建立连接，如nginx可代理前后端，与前端客户端tcp连接，与后端服务器建 立tcp连接。
3. 支持7层代理的软件：
   • Nginx:基于http协议(nginx七层是通过proxy_pass)
   • Haproxy:七层代理，会话保持、标记、路径转移等。

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

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决 定怎么样转发流量
四层的负载均衡，就是通过发布三层的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攻击

所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。

haproxy简介

HAProxy是法国开发者威利塔罗(Willy Tarreau)在2000年使用C语言开发的一个开源软件，是一款具备高并发(万级以上)、高性能的TCP和HTTP负载均衡器。支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计。
企业版网站：https://www.haproxy.com
社区版网站：http://www.haproxy.org
github：https://github.com/haprox

haproxy实验环境的部署

前提：所有主机的防火墙均为关闭状态

克隆三台虚拟机RHEL9.4。分别为haproxy、webserver1、webserver2三台主机

haproxy：网卡eth0、IP为172.25.254.100、主机名为haproxy.example.com

webserver1：网卡eth0、IP为172.25.254.10、主机名为webserver1.example.com

webserver2：网卡eth0、IP为172.25.254.20、主机名为webserver2.example.com

在两台webserver上安装nginx

[root@webserver1 ~]# dnf install nginx -y

[root@webserver2 ~]# dnf install nginx -y

[root@webserver1 ~]# echo webserver1:172.25.254.10 > /usr/share/nginx/html/index.html
[root@webserver1 ~]# systemctl enable --now nginx.service 
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.

[root@webserver2 ~]# echo webserver2:172.25.254.20 > /usr/share/nginx/html/index.html
[root@webserver2 ~]# systemctl enable --now nginx.service 
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.

# 客户端访问
[root@haproxy ~]# curl 172.25.254.10
webserver1:172.25.254.10
[root@haproxy ~]# curl 172.25.254.20
webserver2:172.25.254.20

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

此时基本环境就已经搭建完成

haproxy基本配置信息

官方文档：http://cbonte.github.io/haproxy-dconv/
HAProxy的配置文件haproxy.cfg由两大部分组成，分别是：

global：全局配置段

• 进程及安全配置相关的参数
• 性能调整相关参数
• Debug参数

proxies：代理配置段

• defaults:为frontend,backend,listen提供默认配置
• frontend:前端，相当于nginx中的server {}
• backend:后端，相当于nginx中的upstream {}
• listen:同时拥有前端和后端配置，配置简单，生产推荐使用

# 在haproxy主机上安装haproxy
[root@haproxy ~]# dnf install haproxy -y

# 配置文件设定
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
# 将以下内容写入配置文件中
frontend webcluster
    bind *:80
    mode http
    use_backend webcluster-host

backend webcluster-host
    balance roundrobin
    server  web1 172.25.254.10:80
    server  web2 172.25.254.20:80

[root@haproxy ~]# systemctl restart haproxy.service
[root@haproxy ~]# systemctl enable haproxy.service 
Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service.


#本机访问
[C:\~]$ curl 172.25.254.100
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    25  100    25    0     0   9211      0 --:--:-- --:--:-- --:--:-- 12500
webserver1:172.25.254.10

[C:\~]$ curl 172.25.254.100
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    25  100    25    0     0  10660      0 --:--:-- --:--:-- --:--:-- 12500
webserver2:172.25.254.20


# 将前后端合并，将之前写的注释掉，把以下内容写进去
#frontend webcluster
 #   bind *:80
  #  mode http
   # use_backend webcluster-host

#backend webcluster-host
 #   balance roundrobin
  #  server  web1 172.25.254.10:80
   # server  web2 172.25.254.20:80

listen webcluster
   bind *:80
   mode http
   balance roundrobin
   server  web1 172.25.254.10:80
   server  web2 172.25.254.20:80
   
# 重启服务，客户端访问。实验效果跟上面一样
[root@haproxy ~]# systemctl restart haproxy.service
[C:\~]$ curl 172.25.254.100
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    25  100    25    0     0  10084      0 --:--:-- --:--:-- --:--:-- 12500
webserver1:172.25.254.10

[C:\~]$ curl 172.25.254.100
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    25  100    25    0     0  11876      0 --:--:-- --:--:-- --:--:-- 12500
webserver2:172.25.254.20

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

haproxy的全局配置参数及日志分离

配置参数

[root@haproxy ~]# pstree -p | grep haproxy
           |-haproxy(32904)---haproxy(32906)---{haproxy}(32907)

# 将`nbproc 2`添加到配置文件的global中
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg 
nbproc 2 # 启用多进程
[root@haproxy ~]# systemctl restart haproxy.service 
[root@haproxy ~]# pstree -p | grep haproxy
           |-haproxy(32924)-+-haproxy(32926)
           |                `-haproxy(32927)
# 系统中的线程数量并不是越多越好，跟CPU的核心数量有关。

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

[root@haproxy ~]# systemctl restart haproxy.service 
[root@haproxy ~]# pstree -p | grep haproxy
           |-haproxy(32957)-+-haproxy(32959)
           |                `-haproxy(32960)
           
# 多线程与多进程互斥，多进程与多线程同时设定重启服务的时候会报错
# 查看多线程数量 32960为haproxy子进程的id
[root@haproxy ~]# cat /proc/32960/status | grep -i thread
Threads:	1
Speculation_Store_Bypass:	thread vulnerable

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
········
global
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     100000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

    # utilize system-wide crypto-policies
    ssl-default-bind-ciphers PROFILE=SYSTEM
    ssl-default-server-ciphers PROFILE=SYSTEM
    #nbproc 2
    #cpu-map 1 0
    #cpu-map 2 1
    nbthread 2
    
    
    ·······
    
[root@haproxy ~]# systemctl restart haproxy.service 
[root@haproxy ~]# pstree -p | grep haproxy
           |-haproxy(33009)---haproxy(33011)---{haproxy}(33012)
[root@haproxy ~]# cat /proc/33011/status | grep -i thread
Threads:	2
Speculation_Store_Bypass:	thread vulnerable


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

定向haproxy日志

[root@haproxy ~]# vim /etc/rsyslog.conf
···
# 将这两行注释打开
#打开udp端口
#module(load="imudp") # needs to be done just once
#input(type="imudp" port="514")
module(load="imudp") # needs to be done just once
input(type="imudp" port="514")

····
# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log
local2.*                                                /var/log/haproxy.log


·····

[root@haproxy ~]# ll /var/log/haproxy.log
ls: cannot access '/var/log/haproxy.log': No such file or directory
[root@haproxy ~]# systemctl restart rsyslog.service


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

proxies配置

proxies配置-defaults

Proxies配置-frontend

bind：指定HAProxy的监听地址，可以是IPV4或IPV6，可以同时监听多个IP或端口，可同时用于listen字段中

#格式：

bind [

]:<port_range> [, …] [param*]

#注意：如果需要绑定在非本机的IP，需要开启内核参数：net.ipv4.ip_nonlocal_bind=1

backlog #针对所有server配置,当前端服务器的连接数达到上限后的后援队列长度，注意：不支持backend

Proxies配置backend

• 定义一组后端服务器，backend服务器将被frontend进行调用。

• 注意: backend 的名称必须唯一,并且必须在listen或frontend中事先定义才可以使用,否则服务无法启动

mode http|tcp #指定负载协议类型,和对应的frontend必须一致

option #配置选项

server #定义后端real server,必须指定IP和端口

注意：option后面加 httpchk，smtpchk,mysql-check,pgsql-check，ssl-hello-chk方法，可用于实现更多应用层检测功能。

server配置

haproxy的热更新方法

socat

socat是一个多功能的网络工具，名字来由是” Socket CAT”，可以看作是netcat的N倍加强版，

官方网站：http://www.dest-unreach.org/socat/
socat是一个两个独立数据通道之间的双向数据传输的继电器。这些数据通道包含文件、管道、设备（终端或调制解调器等）、插座（Unix，IP4，IP6 - raw，UDP，TCP）、SSL、SOCKS4客户端或代理CONNECT。

Socat支持广播和多播、抽象Unix sockets、Linux tun/tap、GNU readline 和 PTY。它提供了分叉、记录和进程间通信的不同模式。多个选项可用于调整socat和其渠道，Socat可以作为TCP中继（一次性或守护进程），作为一个守护进程基于socksifier，作为一个shell Unix套接字接口，作为IP6的继电器，或面向TCP的程序重定向到一个串行线。

socat的主要特点就是在两个数据流之间建立通道；且支持众多协议和链接方式：ip,tcp,udp,ipv6,pipe,exec,system,open,proxy,openssl,socket等

socat [参数] <地址1> <地址2>
1

使用 socat 需要提供两个地址，然后 socat 做的事情就是把这两个地址的数据流串起来，把第左边地址的输出数据传给右边，同时又把右边输出的数据传到左边。

最简单的地址就是一个减号“-”，代表标准输入输出，而在命令行输入：

socat - -   # 把标准输入和标准输出对接，输入什么显示什么
1

就会对接标准输入和标准输出，你键盘敲什么屏幕上就显示什么，类似无参数的 cat 命令。除了减号地址外，socat 还支持：TCP, TCP-LISTEN, UDP, UDP-LISTEN, OPEN, EXEC, SOCKS, PROXY 等多种地址，用于端口监听、链接，文件和进程读写，代理桥接等等。

利用socat对服务器动态权重调整

#修改配置文件
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
stats socket /var/lib/haproxy/stats mode 600 level admin

#查看haproxy状态
[root@haproxy ~]# echo "show info" | socat stdio /var/lib/haproxy/stats
Name: HAProxy
Version: 2.4.22-f8e3218
Release_date: 2023/02/14
Nbthread: 1
Nbproc: 1
Process_num: 1
Pid: 33542
Uptime: 0d 0h03m43s
Uptime_sec: 223
Memmax_MB: 0
PoolAlloc_MB: 0
#查看集群状态
[root@haproxy ~]# echo "show servers state" | socat stdio /var/lib/haproxy/stats
1
# be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight
srv_iweight srv_time_since_last_change srv_check_status srv_check_result
srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id
srv_fqdn srv_port srvrecord srv_use_ssl srv_check_port srv_check_addr
srv_agent_addr srv_agent_port
2 webcluster 1 web1 172.25.254.20 2 0 2 2 188 6 3 7 6 0 0 0 - 80 - 0 0 - - 0
2 webcluster 2 web2 172.25.254.30 2 0 1 1 188 6 3 7 6 0 0 0 - 80 - 0 0 - - 0
4 static 1 static 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 4331 - 0 0 - - 0
5 app 1 app1 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 5001 - 0 0 - - 0
5 app 2 app2 127.0.0.1 0 0 1 1 187 8 2 0 6 0 0 0 - 5002 - 0 0 - - 0
5 app 3 app3 127.0.0.1 0 0 1 1 186 8 2 0 6 0 0 0 - 5003 - 0 0 - - 0
5 app 4 app4 127.0.0.1 0 0 1 1 186 8 2 0 6 0 0 0 - 5004 - 0 0 - - 0
#查看集群权重
[root@haproxy ~]# echo get weight webcluster/web1 | socat stdio
/var/lib/haproxy/stats
2 (initial 2)
[root@haproxy ~]# echo get weight webcluster/web2 | socat stdio
/var/lib/haproxy/stats
1 (initial 1)
#设置权重
[root@haproxy ~]# echo "set weight webcluster/web1 1 " | socat stdio
/var/lib/haproxy/stats
[root@haproxy ~]# echo "set weight webcluster/web1 2 " | socat stdio
/var/lib/haproxy/stats
#下线后端服务器
[root@haproxy ~]# echo "disable server webcluster/web1 " | socat stdio
/var/lib/haproxy/stats
#上线后端服务器
[root@haproxy ~]# echo "enable server webcluster/web1 " | socat stdio
/var/lib/haproxy/stats


## 针对多进程处理方法
#如果开启多进程那么我们在对进程的sock文件进行操作时其对进程的操作时随机的
#如果需要指定操作进程那么需要用多soct文件方式来完成
haproxy ~]# vim /etc/haproxy/haproxy.cfg
...上面内容省略...
stats socket /var/lib/haproxy/stats1 mode 600 level admin process 1
stats socket /var/lib/haproxy/stats2 mode 600 level admin process 2
nbproc 2
cpu-map 1 0
cpu-map 2 1
...下面内容省略...
#这样每个进程就会有单独的sock文件来进行单独管理
[root@haproxy ~]# ll /var/lib/haproxy/
总用量 0
srw------- 1 root root 0 8月 8 13:43 stats
srw------- 1 root root 0 8月 8 13:46 stats1
srw------- 1 root root 0 8月 8 13:46 stats2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

haproxy算法

HAProxy通过固定参数balance指明对后端服务器的调度算法

balance参数可以配置在listen或backend选项中

HAProxy的调度算法分为静态和动态调度算法

有些算法可以根据参数在静态和动态算法中相互转换

静态算法

静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度等，且无法实时修改权重（只能为0和1,不支持其它值），只能靠重启HAProxy生效。

static-rr：基于权重的轮询调度

• 不支持运行时利用socat进行权重的动态调整（只支持0和1，不支持其它值）
• 不支持端服务器慢启动（慢启动是指在服务器刚刚启动时不会把它所应该承担的访问压力全部给它，而是先给一部分，当没有问题后再给一部分）
• 其后端主机数量没有限制，相当于LVS中的wrr

案例实现：

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg 
--------------以上内容省略------------------
listen webcluster
   bind *:80
   mode http
   #balance first
   balance static-rr
   server  web1 172.25.254.10:80 check inter 2 fall 3 rise 5 weight 2
   server  web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1
   
------------以下内容省略------------------------
[root@haproxy ~]# systemctl restart haproxy.service

#测试
[root@test ~]# for i in {1..10}; do curl 172.25.254.100; done
webserver2:172.25.254.20
webserver1:172.25.254.10
webserver2:172.25.254.20
webserver1:172.25.254.10
webserver2:172.25.254.20
webserver1:172.25.254.10
webserver2:172.25.254.20
webserver1:172.25.254.10
webserver2:172.25.254.20
webserver1:172.25.254.10

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

first（很少用）

• 根据服务器在列表中的位置，自上而下进行调度
• 其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务
• 其会忽略服务器的权重设置
• 不支持用socat进行动态修改权重，可以设置0和1,可以设置其它值但无效

效果很难演示出来所以这里不做测试

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg 
--------------以上内容省略------------------
listen webcluster
   bind *:80
   mode http
   balance first
   server  web1 172.25.254.10:80 check inter 2 fall 3 rise 5 weight 2
   server  web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1
   
------------以下内容省略------------------------
[root@haproxy ~]# systemctl restart haproxy.service
1
2
3
4
5
6
7
8
9
10
11

动态算法

• 基于后端服务器状态进行调度适当调整
• 新请求将优先调度至当前负载较低的服务器
• 权重可以在haproxy运行时动态调整无需重启
• 静态算法后端Real Server个数不限

roundrobin（使用最多）

• 基于权重的轮询动态调度算法
• 支持权重的运行时调整，不同于Ivs中的rr轮训模式
• HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)
• 其每个后端backend中最多支持4095个real server
• 支持对real server权重动态调整
• roundrobin为默认调度算法，此算法使用广泛

优先把流量给权重高且负载小的主机，以负载为主

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg 
--------------以上内容省略------------------
listen webcluster
   bind *:80
   mode http
   balance roundrobin
   server  web1 172.25.254.10:80 check inter 2 fall 3 rise 5 weight 2
   server  web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1
   
------------以下内容省略------------------------
[root@haproxy ~]# systemctl restart haproxy.service
1
2
3
4
5
6
7
8
9
10
11

leastconn

• leastconn加权的最少连接的动态
• 支持权重的运行时调整和慢启动（相当于LVS的wlc），即：根据当前连接最少的后端服务器而非权重进行优先调度(新客户端连接)【当两个主机的连接数都差不多的时候给权重高的，权重是次考虑的】
• 比较适合长连接的场景使用，比如：MySQL等场景。

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg 
--------------以上内容省略------------------
listen webcluster
   bind *:80
   mode http
   balance leastconn
   server  web1 172.25.254.10:80 check inter 2 fall 3 rise 5 weight 2
   server  web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1
   
------------以下内容省略------------------------
[root@haproxy ~]# systemctl restart haproxy.service
1
2
3
4
5
6
7
8
9
10
11

random

基于随机数作为一致性hash的key，随机负载平衡对于大型服务器场或经常添加或删除服务器非常有用，支持weight的动态调整，weight较大的主机有更大概率获取新请求

其他算法（既可作为静态算法，又可以通过选项成为动态算法）

默认不写就是hash-type map-base的静态，hash-type consistent 就是动态的。

source

源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP 模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持 cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash。

案例实现

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg 
--------------以上内容省略------------------
listen webcluster
   bind *:80
   mode http
   balance source
   server  web1 172.25.254.10:80 check inter 2 fall 3 rise 5 weight 2
   server  web2 172.25.254.20:80 check inter 2 fall 3 rise 5 weight 1
   
------------以下内容省略------------------------
[root@haproxy ~]# systemctl restart haproxy.service

[root@test ~]# for i in {1..10}; do curl 172.25.254.100; done
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20
webserver2:172.25.254.20

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

map-base 取模法

对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请求转发至对应的后端服务器。

此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度。

缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果整体改变，hash-type指定的默认值为此算法。

所谓取模运算，就是计算两个数相除之后的余数，10%7=3, 7%4=3
map-based算法：基于权重取模，hash(source_ip)%所有后端服务器相加的总权重。

map-base 取模法是用于将客户端请求分配到后端服务器的一种算法策略。 具体来说，当使用 map-base 取模法时，HAProxy 会根据客户端请求的某些特征（例如源 IP 地址）进行计算，并通过取模运算来确定将请求转发到后端的哪一台服务器。 例如，如果后端有 5 台服务器，HAProxy 对客户端源 IP 地址进行某种处理后得到一个数值，然后将这个数值对 5 取模，得到的结果（0 到 4 之间）就决定了将请求发送到对应的服务器。 这种方法的优点在于实现相对简单，并且在一定程度上能够平均地分配请求。 但它也有一些潜在的问题： 1. 如果后端服务器的数量发生变化（例如新增或移除服务器），那么取模的结果就会发生较大变化，可能导致部分请求的分配路径突然改变，影响服务的稳定性。 2. 当客户端的分布不均匀时（例如来自某些特定网段的客户端请求特别多），可能会导致后端服务器的负载不均衡。

一致性hash

在 Linux 中，HAProxy 中的一致性哈希（Consistent Hashing）是一种用于负载均衡的算法。 一致性哈希的主要思想是将后端服务器和客户端请求（通常基于某种特征，如源 IP 地址）映射到一个环形的哈希空间中。 比如说，这个哈希空间是从 0 到 2^32 - 1 的一个整数范围。每台后端服务器根据其标识（如 IP 地址或名称）计算出一个哈希值，并对应到这个环上的一个位置。客户端请求也通过类似的方式计算出哈希值，并在环上顺时针查找遇到的第一个服务器节点，该服务器就负责处理这个请求。 一致性哈希的优点在于： 当后端服务器数量发生变化时，例如新增或移除服务器，只有环上相邻的一小部分请求的分配会受到影响，而不是像传统的取模算法那样可能导致大部分请求的分配路径发生改变。 例如，如果原本有服务器 A、B、C 分布在环上，当新增服务器 D 时，只有原本会分配到服务器 A 与服务器 C 之间的那部分请求会被重新分配到服务器 D 上，其余请求的分配路径不变。 这就大大减少了因服务器数量变动而导致的请求重新分配的范围，提高了系统的稳定性和可扩展性。 同时，一致性哈希对于客户端请求分布的不均匀性也有更好的适应性，能够在一定程度上避免某些服务器负载过高或过低的情况。

一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash (o) mod n
该hash算法是动态的，支持使用socat等工具进行在线权重调整，支持慢启动

1. key1=hash(source_ip)%(2^32)
2. keyA=hash(后端服务器虚拟ip)%(2^32) [0—4294967295]
3. 将key1和keyA都放在hash环上，将用户请求调度到离key1最近的keyA对应的后端服务器

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

一致性hash示意图

解决hash环偏斜问题

增加虚拟节点数量

首先，确定每个物理节点需要创建的虚拟节点数量。这个数量可以根据实际情况进行设定，通常会根据物理节点的数量、系统的规模和负载均衡的要求来决定。 然后，为每个物理节点生成相应数量的虚拟节点标识。这些标识可以通过在物理节点的标识基础上添加一些后缀或前缀来创建，以确保虚拟节点标识的唯一性。 接下来，计算虚拟节点的哈希值。使用与计算物理节点哈希值相同的哈希函数，对虚拟节点标识进行计算，得到对应的哈希值。 将虚拟节点的哈希值映射到一致性哈希环上。这些虚拟节点的哈希值会均匀地分布在哈希环上，从而增加了物理节点在哈希环上的“密度”。 在处理请求时，按照一致性哈希的规则，先计算请求的哈希值，然后在哈希环上顺时针查找最近的节点。由于虚拟节点的存在，请求更有可能被分配到不同的物理节点上，从而实现更均匀的负载分布。 例如，假设有 3 台物理服务器 A、B、C，决定为每台服务器创建 10 个虚拟节点。 服务器 A 的标识为 A，则生成的 10 个虚拟节点标识可以是 A-1、A-2、A-3 … A-10。 计算这些虚拟节点标识的哈希值，并映射到哈希环上。 当有新的请求到来时，计算其哈希值，在哈希环上查找最近的节点。此时，很可能会找到某个服务器 A 的虚拟节点，从而将请求分配到服务器 A 上。 通过这种方式，增加了服务器 A 在哈希环上的“存在范围”，提高了其获得请求分配的机会，使得负载能够在多台物理服务器之间更加均衡地分布。

uri

缓存服务器，CDN服务商，百度、阿里云、腾讯

基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后，根据最终结果将请求转发到后端指定服务器，适用于后端是缓存服务器场景，默认是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性hash。

注意：此算法基于应用层，所以只支持 mode http ，不支持 mode tcp

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/喵喵爱编程/article/detail/1008815