负载均衡之HAProxy超全内容！！！

一、负载均衡

1.1 负载均衡概念

负载均衡（Load Balance，简称 LB）是高并发、高可用系统必不可少的关键组件，目标是尽力将网络流量平均分发到多个服务器上，以提高系统整体的响应速度和可用性。

1.2 软件负载均衡

软件负载均衡，应用最广泛，无论大公司还是小公司都会使用。

软件负载均衡从软件层面实现负载均衡，一般可以在任何标准物理设备上运行。

软件负载均衡的主流产品有：Nginx、HAProxy、LVS。

LVS 可以作为四层负载均衡器。其负载均衡的性能要优于 Nginx。

HAProxy 可以作为 HTTP 和 TCP 负载均衡器。

Nginx、HAProxy 可以作为四层或七层负载均衡器。

今天要介绍的就是HAPorxy

1.3 四层和七层负载区别

1.3.1 请求过程

四层负载

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

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

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

七层负载

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

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

1.3.2 区别

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

四层的负载均衡

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

七层的负载均衡

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

二、HAProxy基础

2.1 概念

HAProxy是一款开源、高性能的负载均衡器和代理服务器，专为TCP和HTTP应用而设计。它可以将客户端的请求分发到多台后端服务器，从而提高应用的可用性和性能。HAProxy支持多种负载均衡算法和健康检查机制，是构建高可用性系统的理想选择。

2.2 基本配置信息

下载haproxy

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

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

global ：全局配置段

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

性能调整相关参数

Debug 参数

proxies ：代理配置段

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

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

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

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

2.2.1 global配置

参数	作用
chroot	锁定运行目录
deamon	以守护进程运行
user,group,uid,gid	运行haproxy的用户身份
stats socket	套接字文件
nbproc N	指定每个 haproxy 进程开启的线程数，默认为每个进程一个线程
nbthread 1（和nbproc互斥）	指定每个 haproxy 进程开启的线程数，默认为每个进程一个线程
cpu-map 1 0	绑定 haproxy worker 进程至指定 CPU ，将第 1 个 work 进程绑定至0 号 CPU
cpu-map 2 1	绑定 haproxy worker 进程至指定 CPU ，将第 2 个 work 进程绑定至1 号 CPU
maxconn N	每个 haproxy 进程的最大并发连接数
maxsslconn N	每个 haproxy 进程 ssl 最大连接数 , 用于 haproxy 配置了证书的场景下
maxconnrate N	每个进程每秒创建的最大连接数量
spread-checks N	后端 server 状态 check 随机提前或延迟百分比时间，建议 2- 5(20%-50%) 之间，默认值 0
pidfile	指定 pid 文件路径
log 127.0.0.1 local2 info	定义全局的 syslog 服务器；日志服务器需要开启 UDP 协议，最多可以定义两个

2.2.2 server配置

check                 #对指定real 进行健康状态检查，如果不加此设置，默认不开启检查 , 只有check后面没有其它配置也可以启用检查功能

                          #默认对相应的后端服务器IP和端口, 利用 TCP 连接进行周期性健康性检查 , 注意必须指定端口才能实现健康性检查

addr <IP> #可指定的健康状态监测 IP ，可以是专门的数据网段，减少业务网络的流量

port <num>       #指定的健康状态监测端口

inter <num>      #健康状态检查间隔时间，默认 2000 ms

fall <num>         #后端服务器从线上转为线下的检查的连续失效次数，默认为 3

rise <num>         #后端服务器从下线恢复上线的检查的连续有效次数，默认为 2

weight <weight>         #默认为 1 ，最大值为 256 ， 0( 状态为蓝色 ) 表示不参与负载均衡，但仍接受持久连接

backup                 #将后端服务器标记为备份状态, 只在所有非备份主机down机时提供服务，类似Sorry

disabled          #将后端服务器标记为不可用状态，即维护状态，除了持久模式

                        #将不再接受连接,状态为深黄色 , 优雅下线 , 不再接受新用户的请求

redirect prefix http://www.baidu.com/                 #将请求临时(302) 重定向至其它 URL ，只适用于 http 模式

maxconn <maxconn>         #当前后端 server 的最大并发连接数

2.2.3 基础配置

一共四台主机，一台client，一台haproxy，两台后端服务器

client

IP随意，只要与其他三台在同一个网段

webserver1

webserver2

haproxy

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg

第一种写法：

第二种写法

[root@haproxy ~]# systemctl restart rsyslog.service

2.3 日志设置

[root@haproxy ~]# vim /etc/rsyslog.conf

将upd模块的注释打开

重启服务

2.4 socat工具

对服务器动态权重和其它状态可以利用 socat 工具进行调整， Socat 是 Linux 下的一个多功能的网络工具，名字来由是Socket CAT ，相当于 netCAT 的增强版 .Socat 的主要特点就是在两个数据流之间建立双向通道，且支持众多协议和链接方式。如 IP 、 TCP 、 UDP 、 IPv6 、 Socket 文件等调度算法。

socat也叫热处理。

下载socat

修改权重

禁用webcluster1

多线程

修改过配置文件，都需要重启服务

[root@haproxy ~]# systemctl restart rsyslog.service

stats失效

三、HAProxy调度算法

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

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

HAProxy分为静态和动态算法，其他算法

其他算法：可以根据参数在静态和动态算法中相互转换。

3.1 静态算法

3.1.1 static-rr（基于权重的轮询）

不支持运行时利用 socat 进行权重的动态调整 (热处理，只支持 0 和 1, 不支持其它值 )

不支持端服务器慢启动

其后端主机数量没有限制，相当于 LVS 中的 wrr

注：

慢启动是指在服务器刚刚启动上不会把他所应该承担的访问压力全部给它，而是先给一部分，当没

问题后在给一部分

无法热处理

3.1.2 first

根据服务器在列表中的位置，自上而下进行调度

其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务

其会忽略服务器的权重设置

不支持用 socat 进行动态修改权重 , 可以设置 0 和 1, 可以设置其它值但无效

如果有maxconn，则匹配maxconn的最大值

无法热处理

3.2 动态算法

3.2.1 roundrobin

基于权重的轮询动态调度算法，可以使用socat动态调整权重（热处理）。

优先选取，负载小，再选取权重高的
HAProxy的roundrobin轮询模式不完全等于LVS的RR轮训模式，区别在于
①HAProxy中的roundrobin⽀持慢启动，新加的服务器会逐渐增加转发数；
②HAProxy每个后端backend中最多⽀持4095个real server；
③HAProxy⽀持对real server权重动态调整（socat）；

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg

[root@haproxy ~]# systemctl restart haproxy.service

支持热处理

3.2.2 leastconn

当前后端服务器连接最少的优先调度。
①支持加权的最少连接
②支持动态调整权重（热处理，socat）
③支持慢启动

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg

[root@haproxy ~]# systemctl restart haproxy.service

3.3 其他算法

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

3.3.1 source

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

源地址hash，基于⽤户源地址hash并将请求转发到后端服务器。
第一种，默认为静态即取模⽅式；
第二种，可以通过hash-type⽀持的选项更改，动态即hash一致方式。

缺点：如果访问客户端时一个家庭，那么所有的家庭的访问流量都会被定向到一台服务器，这时 source 算法的缺陷

动态需要添加：

3.3.1.1 source之map-base取模法

取模法，基于服务器总权重的hash数组取模。
不⽀持在线调整权重；
不⽀持慢启动；
缺点：当服务器的总权重发⽣变化时，即有服务器上线或下线，都会因权重发⽣变化⽽导致调度结果整体改变。

注：

所谓取模运算，就是计算两个数相除之后的余数， 10%7=3, 7%4=3

map-based 算法：基于权重取模， hash(source_ip)% 所有后端服务器相加的总权重

3.3.1.2 source之一致hash法

⼀致性哈希，该hash是动态的。
⽀持在线调整权重；
⽀持慢启动；
优点：当服务器的总权重发⽣变化时，对调度结果影响是局部的，不会引起⼤的变动。
使用场景：在没有做session共享的情况下，想做会话保持。

3.3.2 uri

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

基于对⽤户请求的uri做hash并将请求转发到后端指定服务器。

3.2.2.1 url_param

url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用于电商
通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个real server
如果无没key，将按roundrobin算法

3.3.3 hdr

针对用户每个http头部(header)请求中的指定信息做hash，
此处由 name 指定的http首部将会被取出并做hash计算，
然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。

四、状态页

通过 web 界面，显示当前 HAProxy的运行状态

五、cookie

cookie value ：为当前 server 指定 cookie 值，实现基于 cookie 的会话黏性，相对于基于 source 地址 hash 调度算法对客户端的粒度更精准，但同时也加大了haproxy 负载，目前此模式使用较少，已经被 session 共享服务器代替

六、IP透传

概念

web 服务器中需要记录客户端的真实 IP 地址，用于做访问统计、安全防护、行为分析、区域排行等场景

七层和四层配置差不多，只有一点区别

配置

七层透传

四层透传

四层http不能透传

七、ACL

访问控制列表ACL，Access Control Lists）
是一种基于包过滤的访问控制技术
它可以根据设定的条件对经过服务器传输的数据包进行过滤(条件匹配)即对接收到的报文进行匹配和过滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、URL、文件后缀等信息内容进行匹配并执行进一步操作，比如允许其通过或丢弃。

hdr string ，提取在一个 HTTP 请求报文的首部

hdr （ [<name> [ ， <occ>]] ）：完全匹配字符串 ,header 的指定信息， <occ> 表示在多值中使用的值的出

现次数

hdr_beg （ [<name> [ ， <occ>]] ）：前缀匹配， header 中指定匹配内容的 begin

hdr_end （ [<name> [ ， <occ>]] ）：后缀匹配， header 中指定匹配内容 end

hdr_dom （ [<name> [ ， <occ>]] ）：域匹配， header 中的 dom （ host ）

hdr_dir （ [<name> [ ， <occ>]] ）：路径匹配， header 的 uri 路径

hdr_len （ [<name> [ ， <occ>]] ）：长度匹配， header 的长度匹配

hdr_reg （ [<name> [ ， <occ>]] ）：正则表达式匹配，自定义表达式 (regex) 模糊匹配

hdr_sub （ [<name> [ ， <occ>]] ）：子串匹配， header 中的 uri 模糊匹配模糊匹配 c 报文中 a/b/c 也会匹配

base : string

# 返回第一个主机头和请求的路径部分的连接，该请求从主机名开始，并在问号之前结束 , 对虚拟主机有用

<scheme>://<user>:<password>@#<host>:<port>/<path>;<params>#?<query>#<frag>

base : exact string match

base_beg : prefix match

base_dir : subdir match

base_dom : domain match

base_end : suffix match

base_len : length match

base_reg : regex match

base_sub : substring match

path : string

# 提取请求的 URL 路径，该路径从第一个斜杠开始，并在问号之前结束（无主机部分）

<scheme>://<user>:<password>@<host>:<port>#/<path>;<params>#?<query>#<frag>

path : exact string match

path_beg : prefix match # 请求的 URL 开头，如 /static 、 /images 、 /img 、 /css

path_end : suffix match # 请求的 URL 中资源的结尾，如 .gif .png .css .js .jpg .jpeg

path_dom : domain match

path_dir : subdir match

path_len : length match

path_reg : regex match

path_sub : substring match

url : string

# 提取请求中的整个 URL 。

url ： exact string match

url_beg : prefix match

url_dir : subdir match

url_dom : domain match

url_end : suffix match

url_len : length match

url_reg : regex match

url_sub : substring match