什么是haproxy
Haproxy是一款提供高可用性，负载均衡以及基于tcp和http的的应用交付控制器的开源软件。它由法国人威利塔罗使用c语言开发的。它广泛用于管理和路由网络流量，并确保应用程序的高可用性和高性能。
haproxy的功能
提供第4层（TCP层）和第7层（HTTP层）的负载均衡能力。
支持多种负载均衡算法，如轮询、最少连接数等。
可以进行健康检查，确保只有健康的服务器接收流量。
支持会话保持，这对于需要维护客户端会话状态的应用程序非常重要。
可以实现SSL/TLS卸载，即在HAProxy这一层处理加密流量，减轻后端服务器的负担。
支持复杂的路由规则，可以根据URL、头部信息等来决定流量的去向。
什么是负载均衡
负载均衡是一种网络技术，用于分配网络流量到多个服务器或资源，以优化资源使用，最大化吞吐量，最小化响应时间并避免单一资源过载。负载均衡能提高系统的可用性和可靠性。是现代分布式系统的重要组成部分。
负载均衡的特点
1.高可用性与容错性：
负载均衡器能够检测后端服务器的健康状态，自动将流量从故障服务器转移到正常服务器，确保服务的连续性。
通过将请求分散到多个服务器上，即使某个服务器发生故障，其他服务器仍然可以继续提供服务，从而提高系统的整体可用性。
2.扩展性与灵活性：
负载均衡允许系统轻松地添加或删除服务器，以应对流量的变化或业务需求的扩展。
可以根据不同的负载均衡算法（如轮询、最少连接、源地址哈希等）和策略来灵活配置流量的分发方式。
3.性能优化：
通过将请求分散到多个服务器上，负载均衡可以显著提高系统的处理能力，缩短响应时间。
可以根据服务器的负载情况和性能指标来动态调整流量的分发，确保系统资源的高效利用。
4.安全性：
负载均衡器可以作为系统的入口点，对进入的流量进行过滤、检查和防护，提高系统的安全性。
通过隐藏后端服务器的真实IP地址和端口号，可以防止直接的恶意攻击和扫描。
5.透明性与可管理性：
对于客户端来说，负载均衡器是透明的，客户端不需要知道后端服务器的具体信息。
负载均衡器提供了丰富的管理功能和统计信息，方便管理员监控系统的运行状态和性能。
6.成本效益：
通过负载均衡，可以充分利用现有的服务器资源，避免过度投资或浪费。
负载均衡器本身通常具有较低的成本，而它带来的性能和可用性提升可以显著降低系统的总体运营成本。
harproxy的基本配置
下载haproxy
yum install haproxy -y
启用多进程
vim /etc/haproxy/haproxy.cfg
# turn on stats unix socket
stats socket /var/lib/haproxy/stats1 mode 600 level admin process 1
stats socket /var/lib/haproxy/stats2 mode 600 level admin process 2
# 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
启用多线程
vim /etc/haproxy/haproxy.cfg
# turn on stats unix socket
stats socket /var/lib/haproxy/stats1 mode 600 level admin process 1
stats socket /var/lib/haproxy/stats2 mode 600 level admin process 2
# utilize system-wide crypto-policies
ssl-default-bind-ciphers PROFILE=SYSTEM
ssl-default-server-ciphers PROFILE=SYSTEM
nbthread 2
proxies配置
defaults
defaults
mode http # 默认为 HTTP 模式
log global # 继承全局的日志配置
option httplog # 启用详细的 HTTP 日志记录
option dontlognull # 不记录空的内容（例如，没有有效数据的请求）
option http-server-close # 服务器主动关闭连接
option forwardfor except 127.0.0.0/8 # 转发客户端真实 IP，但排除 127.0.0.0/8 网段
option redispatch # 当后端服务器不可用时，重新分配请求到其他可用服务器
retries 3 # 重试次数为 3 次
timeout http-request 10s # HTTP 请求的超时时间为 10 秒
timeout queue 1m # 队列超时时间为 1 分钟
timeout connect 10s # 连接超时时间为 10 秒
timeout client 1m # 客户端超时时间为 1 分钟
timeout server 1m # 服务器超时时间为 1 分钟
timeout http-keep-alive 10s # HTTP 保持活动连接的超时时间为10秒
timeout check 10s # 健康检查的超时时间为 10 秒
maxconn 3000 # 最大并发连接数为 3000
frontend
frontend main
bind *:5000 # 表示绑定到所有接口的 5000 端口
acl url_static path_beg -i /static /images /javascript /stylesheets # 定义一个名为 url_static 的访问控制列表（ACL），当请求路径以指定的字符串（不区分大小写）开头时匹配
acl url_static path_end -i .jpg .gif .png .css .js # 当请求路径以指定的文件扩展名（不区分大小写）结尾时也匹配
use_backend static if url_static # 如果请求匹配 url_static 这个 ACL 条件，则使用名为 static 的后端
default_backend app # 默认使用名为 app 的后端
backend
backend static
balance roundrobin # 为后端的服务器采用轮询（roundrobin）的负载均衡算法
server static 127.0.0.1:4331 check # 定义名为 static 的服务器，地址为 127.0.0.1:4331，并启用健康检查
listen
使用listen替换 frontend和backend的配置方式，可以简化设置，通常只用于TCP协议的应用
socat工具
对服务器动态权重和其它状态可以利用 socat工具进行调整，Socat 是 Linux 下的一个多功能的网络工具，名字来由是Socket CAT，相当netCAT的增强版.Socat 的主要特点就是在两个数据流之间建立双向通道，且支持众多协议和链接方式。如 IP、TCP、 UDP、IPv6、Socket文件等
实例
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
echo get weight webcluster/web1 | socat stdio /var/lib/haproxy/stats1 #查看权重
1 (initial 1)
echo "set weight webcluster/web1 2"| socat stdio /var/lib/haproxy/stats1 #改权重
echo "disable server webcluster/web1"| socat stdio /var/lib/haproxy/stats1 #禁用名为 webcluster/web1 的服务器
echo "enable server webcluster/web1"| socat stdio /var/lib/haproxy/stats1 #启用用名为 webcluster/web1 的服务器
结果
haproxy的算法
HAProxy通过固定参数 balance 指明对后端服务器的调度算法。
balance参数可以配置在listen或backend选项中。
HAProxy的调度算法分为静态和动态调度算法。
有些算法可以根据参数在静态和动态算法中相互转换。
haproxy的静态算法
静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度等，且无法实时修改权重(只能为0和1,不支持其它值)，只能靠重启HAProxy生效。
static-rr：基于权重的轮询调度
不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)
不支持端服务器慢启动
其后端主机数量没有限制，相当于LVS中的 wrr
first
根据服务器在列表中的位置，自上而下进行调度
其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务
其会忽略服务器的权重设置
不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效
haproxy的动态算法
基于后端服务器状态进行调度适当调整，
新请求将优先调度至当前负载较低的服务器
权重可以在haproxy运行时动态调整无需重启
roundrobin
基于权重的轮询动态调度算法
支持权重的运行时调整，不同于lvs中的rr轮训模式
HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数
其每个后端backend中最多支持4095个real server
支持对real server权重动态调整
roundrobin为默认调度算法,此算法使用广泛
leastconn
leastconn加权的最少连接的动态
支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户端连接)
比较适合长连接的场景使用，比如：MySQL等场景
其它算法
其它算法即可作为静态算法，又可以通过选项成为动态算法
source
源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器，默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash
map-base 取模法
map-based：取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请求转发至对应的后端服务器。
此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度。缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果整体改变
hash-type 指定的默值为此算法
一致性hash
一致性哈希，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动hash（o）mod n
该hash算法是动态的，支持使用 socat等工具进行在线权重调整，支持慢启动
一致性哈希算法的原理如下：
有一个哈希环（2^32），如图有A B C 三个服务器，将其编号的哈希值对2^32取模，得到的结果必然是在0~2^32之间，那么它一定可以在这个哈希环上对应一个点，于是就将缓存服务器都映射到这些点上。同理对需要缓存或访问的数据进行同样的操作，也可以在哈希环上得到一个点，那么沿顺时针方向，其遇到的第一个缓存服务器就将数据缓存到上面。如图示a.jpg缓存在B上，b.jpg缓存在C上。访问也是一样，计算取模的余数，然后去对应点的服务器拿数据。
当服务器数量或权重发生变化时，比如在c.jpg和A服务器之间加上一个D服务器，那么c.jpg的缓存服务器就从A服务器变成了D服务器。但是其他大部分还是正常缓存和访问的，并不是全部失效。
总结：
一致性hash算法当服务器数量发生变化时并不会所有的缓存都失效，大部分任可以正常访问，依然可以分担整个系统大部分压力，不至于在同一时间都将压力转到后端服务器
传统哈希
分布式缓存，比如有三台服务器s0 s1 s2 当我们缓存或访问时应该均匀的在每台服务器上，而不是只缓存或访问一台服务器。实现的方式就是哈希算法，原理如下：
比如有一张图片要缓存到服务器上，那么将它缓存的键进行哈希取值，然后对值进行取模，除数是服务器的数量（如果有权重要进行加权求和），然后会得到一个余数。比如图片上三台服务器，那么取模得到的余数就是0 1 2，正好和服务器的编号相对应，这样我们就可以将对应的号缓存到对应的服务器上去。例如：图片哈希取值为6，对3取模后为0，就缓存到s0服务器上。因为同一个图片哈希取值是不变的，因此当需要再次访问图片时，只需经过哈希值计算和取模计算，就可以找到上次实在那台服务器上缓存的，只需要到这台服务器上去访问就可以了。
弊端：
当服务器的数量或者权重发生变化时，那么对原来的缓存值进行取模运算时，除数就会不同，那么余数也会不同。比如上面6对3取模是0，但是如果加一台服务器，那么6对4取模就是2，这样就会到2号服务器去找图片，这样显然是不对的，是读取不到图片的。这样就导致了缓存失效，这时访问数据就会去找后端服务器，如果太多缓存失效，那么就会造成缓存雪崩，这样大量的访问压力就会到后端服务器，缓存集群就会失效，很可能导致后端服务器崩溃。
为了解决这个问题，避免大量的缓存失效，就有了一致性hash算法
算法总结
#静态
static-rr--------->tcp/http
first------------->tcp/http
#动态
roundrobin-------->tcp/http
leastconn--------->tcp/http
#以下静态和动态取决于hash_type是否consistent
source------------>tcp/http
Uri--------------->http
url_param--------->http
hdr--------------->http
使用场景
first
static-rr
roundrobin
leastconn
source
#使用较少
#做了session共享的web集群
#数据库
#基于客户端公网IP的会话保持
Uri--------------->http
url_param--------->http
hdr
haproxy的基本部署
实验环境
需要四台虚拟机
webserver1：172.25.254.10/24;webserver2:172.25.254.20/24; haproxy代理机：172.25.254.100/200；客户机IP地址172.25.254.50/24。
实验步骤
后端服务器下载http服务，并写入页面信息
cat /var/www/html/index.html
webserver1 172.25.254.10
#webserver2配置相同
#重启服务
systemctl restart httpd
haproxy代理机写入配置文件
vim /etc/haproxy/haproxy.cfg
......省略
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
#配置从这里开始##########
listen webcluster
bind *:80
mode http
balance roundrobin
server web1 172.25.254.10:80
server web2 172.25.254.20:80
##########
frontend main
bind *:5000
......省略
#重启服务
systemctl restart haproxy.service
测试
curl 172.25.254.100
webserver1 172.25.254.10
curl 172.25.254.100
webserver2 172.25.254.20
curl 172.25.254.100
webserver1 172.25.254.10
curl 172.25.254.100
webserver2 172.25.254.20
haproxy代理参数实验
实验环境
在上一个的基础上。webserver1权重为2，当后端服务器崩溃之后，访问的页面是代理机的8080端口
实验步骤
代理机下载httpd，将监听端口改为8080
#httpd配置文件改监听端口
vim /etc/httpd/conf/httpd.conf
......
systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
改写代理机的配置文件
cat /etc/haproxy/haproxy.cfg
......省略
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
#配置从这里开始##########
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
server web_sorry 172.25.254.100:8080 backup
##########
frontend main
bind *:5000
......省略
systemctl restart haproxy.service
测试
#后端服务器好的时候
curl 172.25.254.100
webserver1 172.25.254.10
curl 172.25.254.100
webserver1 172.25.254.10
curl 172.25.254.100
webserver2 172.25.254.20
curl 172.25.254.100
webserver1 172.25.254.10
curl 172.25.254.100
webserver1 172.25.254.10
curl 172.25.254.100
webserver2 172.25.254.20
#后端服务器崩了的时候
curl 172.25.254.100
sorry is time to go home!
curl 172.25.254.100
sorry is time to go home!
curl 172.25.254.100
sorry is time to go home!
haproxy四层透传实验
实验环境
与之前相同。将webserver2的appche改为nginx
实验步骤
webserver2主机nginx修改配置文件
启用 proxy_protocol项
haproxy主机改写配置文件
vim /etc/haproxy/haproxy.cfg
listen webcluster
bind 172.25.254.100:80
mode tcp
#balance first
#balance static-rr
#balance roundrobin
#balance uri
#balance url param name,userid
#balance hdr(Usr-Agent)
#hash-type consistent
#cookie HAHA insert nocache indirect
查看日志
tail -n 3 /var/log/nginx/access.log
172.25.254.100 - - [10/Aug/2024:10:38:22 +0800] "GET / HTTP/1.1" "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:10:38:42 +0800] "GET / HTTP/1.1" "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:10:38:44 +0800] "GET / HTTP/1.1" "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
haproxy的七层透传实验
实验环境
与之前相同
实验步骤
nginx改写配置文件
http改写配置文件
haproxy主机改写配置文件
查看日志
webserver1
tail -n 3 /etc/httpd/logs/access_log
172.25.254.100 - - [10/Aug/2024:11:01:00 +0800] "GET / HTTP/1.1" 200 25 "-" "curl/7.76.1"
172.25.254.100 - - [10/Aug/2024:11:01:01 +0800] "GET / HTTP/1.1" 200 25 "-" "curl/7.76.1"
172.25.254.100 - - [10/Aug/2024:11:01:02 +0800] "GET / HTTP/1.1" 200 25 "-" "curl/7.76.1"
webserver2
tail -n 3 /var/log/nginx/access.log
172.25.254.100 - - [10/Aug/2024:11:01:00 +0800] "GET / HTTP/1.1" "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:11:01:02 +0800] "GET / HTTP/1.1" "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
172.25.254.100 - - [10/Aug/2024:11:01:03 +0800] "GET / HTTP/1.1" "172.25.254.50"200 25 "-" "curl/7.76.1" "-"
