HAproxy负载均衡剖析
Posted icloud布道师
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HAproxy负载均衡剖析相关的知识,希望对你有一定的参考价值。
逆境前行,能帮你的只有自己
************************************
用到什么整理什么
负载均衡器--HAproxy
本文制作需要3小时,阅读需要7分钟
HAproxy概述
Haproxy是一个使用c语言编写的自由开发源代码软件,它提供高可用性、负载均衡、以及基于http和tcp的应用程序代理。
HAProxy概述
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。根据官方数据,其最高极限支持10G的并发。
HAProxy特别适用于那些负载特大的web站点, 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中,同时可以保护你的web服务器不被暴露到网络上。其支持从4层至7层的网络交换,即覆盖所有的TCP协议。就是说,Haproxy 甚至还支持 mysql的均衡负载。
HAProxy 实现了一种事件驱动、单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。
HAProxy 支持连接拒绝 : 因为维护一个连接的打开的开销是很低的,有时我们很需要限制攻击蠕虫(attack bots),也就是说限制它们的连接打开从而限制它们的危害。这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救
了很多站点,这个优点也是其它负载均衡器没有的。
其配置简单,拥有非常不错的服务器健康检查功能还有专门的系统状态监控页面,当其代理的后端服务器出现故障, HAProxy会自动将该服务器摘除,故障恢复后再自动将该服务器加入。
INSTALL
下载解压源码包
#下载1.19版本
wget https://github.com/haproxy/haproxy/archive/v1.9.0.tar.gz
#解压
tar -z haproxy-1.8.10.tar.gz
#查看目录结构
cd haproxy-1.9.0/
ll
total 709
-rw-rw-r-- 1 root root 588191 Dec 20 2018 CHANGELOG
drwxrwxr-x 18 root root 1024 Dec 20 2018 contrib
-rw-rw-r-- 1 root root 42088 Dec 20 2018 CONTRIBUTING
drwxrwxr-x 5 root root 1024 Dec 20 2018 doc
drwxrwxr-x 2 root root 1024 Dec 20 2018 ebtree
drwxrwxr-x 3 root root 1024 Dec 20 2018 examples
drwxrwxr-x 6 root root 1024 Dec 20 2018 include
-rw-rw-r-- 1 root root 25089 Dec 20 2018 INSTALL
-rw-rw-r-- 1 root root 2029 Dec 20 2018 LICENSE
-rw-rw-r-- 1 root root 3087 Dec 20 2018 MAINTAINERS
-rw-rw-r-- 1 root root 41847 Dec 20 2018 Makefile
-rw-rw-r-- 1 root root 1017 Dec 20 2018 README
drwxrwxr-x 15 root root 1024 Dec 20 2018 reg-tests
-rw-rw-r-- 1 root root 2503 Dec 20 2018 ROADMAP
drwxrwxr-x 2 root root 1024 Dec 20 2018 scripts
drwxrwxr-x 2 root root 3072 Dec 20 2018 src
-rw-rw-r-- 1 root root 14 Dec 20 2018 SUBVERS
drwxrwxr-x 2 root root 3072 Dec 20 2018 tests
-rw-rw-r-- 1 root root 24 Dec 20 2018 VERDATE
-rw-rw-r-- 1 root root 6 Dec 20 2018 VERSION
编译安装
#rhel系最近的Linux系统
make -j $(nproc) TARGET=linux-glibc
make install PREFIX=/usr/local/haproxy //如果没有修改Makefile配置文件中PREFIX变量的值,就必须在此重新对,PREFIX=/usr/local/haproxy赋值,否则直接执行 make install 时,make install会直接读取Makefile文件中PREFIX的变量值。
# FreeBSD and OpenBSD
gmake -j 4 TARGET=freebsd
#嵌入式linux
make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_SLZ=1 USE_PCRE=1
查看生成文件
ll /usr/local/haproxy
drwxr-xr-x 3 root root 4096 Aug 22 13:57 doc
drwxr-xr-x 2 root root 4096 Aug 22 13:57 sbin
drwxr-xr-x 5 root root 4096 Nov 19 2018 share
详细指导请见:
https://github.com/haproxy/haproxy/blob/master/INSTALL
编写配置文件
mkdir /usr/local/haproxy/etc
vim /usr/local/haproxy/etc/haproxy.cfg
global
log 127.0.0.1 local0
#log 127.0.0.1 local1 notice
#log loghost local0 info
maxconn 4096
chroot /usr/local/haproxy
uid 99 #所属运行的用户uid
gid 99 #所属运行的用户组
daemon #以后台形式运行haproxy
nbproc 4 #启动1个haproxy实例。# #工作进程数量(CPU数量) ,实际工作中,应该设置成和CPU核心数一样。 这样可以发挥出最大的性能。
pidfile /usr/local/haproxy/run/haproxy.pid #将所有进程写入pid文件
maxconn 300 ##这里放开限制
#debug #调试错误时用
#quiet #安静
defaults
log global
log 127.0.0.1 local3 #日志文件的输出定向。产生的日志级别为local3. 系统中local1-7,用户自己定义
mode http #工作模式,所处理的类别,默认采用http模式,可配置成tcp作4层消息转发
option httplog #日志类别,记载http日志
option httpclose #每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现
option dontlognull #不记录空连接,产生的日志
option forwardfor #如果后端服务器需要获得客户端真实ip需要配置的参数,可以从Http Header中获得客户端ip
option redispatch #当serverid对应的服务器挂掉后,强制定向到其他健康服务器
retries 2 #2次连接失败就认为服务器不可用,主要通过后面的check检查
balance roundrobin #负载均衡算法
timeout connect 5000 #连接超时时间。 单位:ms 毫秒
timeout client 50000 #客户端连接超时时间
timeout server 50000 #服务器端连接超时时间
mode http
option httpchk GET /graph #健康检测#注意实际工作中测试时,应该下载某一个页面来进行测试,因此这个页面应该是个小页面,而不要用首页面。这里是每隔一秒检查一次页面。
frontend http #前端配置,http名称可自定义
bind 10.67.194.43:9090 #发起http请求80端口,会被转发到设置的ip及端口
default_backend http_back #转发到后端 写上后端名称
backend http_back #后端配置,名称上下关联
server s1 10.67.194.44:9090 check inter 2000 rise 3 fall 3 weight 3 #后端的主机 IP &权衡
server s2 10.67.194.37:9090 check inter 2000 rise 3 fall 3 weight 3 #后端的主机 IP &权衡
#server node1 192.168.179.131:8081 check inter 2000 rise 3 fall 3 weight 30
# inter 2000 健康检查时间间隔2秒
# rise 3 检测多少次才认为是正常的
# fall 3 失败多少次才认为是不可用的
# weight 30 权重
listen admin_stats
bind 0.0.0.0:9188
mode http
stats uri /haproxy-status
注意我的后端是两个Prometheus,借用案例测试时要注意修改以下字段
option httpchk GET /graph
否则会健康检查不到文件,判断为后端服务器都down掉,导致访问不了
配置文件详解
HAProxy 配置文件根据功能和用途,主要有 5 个部分组成,但有些部分并不是必须的, 可以根据需要选择相应的部分进行配置。
1、 global 部分
用来设定全局配置参数,属于进程级的配置,通常和操作系统配置有关。
2、 defaults 部分
默认参数的配置部分。在此部分设置的参数值,默认会自动被引用到下面的 frontend、
backend 和 listen 部分中,因此,如果某些参数属于公用的配置,只需在 defaults 部分添加一次即可。而如果在 frontend、backend 和 listen 部分中也配置了与 defaults 部分一样的参数,那么defaults 部分参数对应的值自动被覆盖。
3、frontend 部分
此部分用于设置接收用户请求的前端虚拟节点。frontend 是在 HAProxy1.3 版本之后才引入的一个组件,同时引入的还有 backend 组件。通过引入这些组件,在很大程度上简化了 HAProxy 配置文件的复杂性。frontend 可以根据 ACL 规则直接指定要使用的后端
4、backend 部分
此部分用于设置集群后端服务集群的配置,也就是用来添加一组真实服务器,以处理前端用户的请求。添加的真实服务器类似于 LVS 中的real server 节点。
5、listen 部分
此部分是 frontend 部分和 backend 部分的结合体。在 HAProxy1.3 版本之前,
HAProxy 的所有配置选项都在这个部分中设置。为了保持兼容性,HAProxy 新的版本仍然保留了 listen 组件的配置方式。目前在 HAProxy 中,两种配置方式任选其一即可。
global配置
log:
全局的日志配置,local0 是日志设备,info 表示日志级别。其中日志级别有err、warning、info、debug 四种可选。这个配置表示使用 127.0.0.1 上的 rsyslog 服务中的local0 日志设备,记录日志等级为info。
maxconn:
设定每个 haproxy 进程可接受的最大并发连接数,此选项等同于 Linux命令行选项“ulimit -n”。
user/ group:
设置运行 haproxy 进程的用户和组,也可使用用户和组的 uid 和gid 值来替代。
daemon:
设置 HAProxy 进程进入后台运行。这是推荐的运行模式。
nbproc:
设置 HAProxy 启动时可创建的进程数,此参数要求将HAProxy 运行模式设置为“daemon”,默认只启动一个进程。根据使用经验,该值的设置应该小于服务器的 CPU 核数。创建多个进程,能够减少每个进程的任务队列,但是过多的进程可能会导致进程的崩溃。
pidfile:
指定 HAProxy 进程的 pid 文件。启动进程的用户必须有访问此文件的权限。
defaults配置
mode:
设置 HAProxy 实例默认的运行模式,有 tcp、http、health 三个可选值。
--tcp 模式 在此模式下,客户端和服务器端之间将建立一个全双工的连接,不会对七层报文做任何类型的检查,默认为 tcp 模式,经常用于 SSL、SSH、SMTP 等应用。
--http 模式 在此模式下,客户端请求在转发至后端服务器之前将会被深度分析,所有不与 RFC 格式兼容的请求都会被拒绝。
--health 模式 目前此模式基本已经废弃
retries:
设置连接后端服务器的失败重试次数,连接失败的次数如果超过这里设置的值,HAProxy 会将对应的后端服务器标记为不可用。此参数也可在后面部分进行设置。
timeout connect:设置成功连接到一台服务器的最长等待时间,默认单位是毫秒,但也可以使用其他的时间单位后缀。
timeout client:
设置连接客户端发送数据时最长等待时间,默认单位是毫秒,也可以使用其他的时间单位后缀。
timeout server:
设置服务器端回应客户度数据发送的最长等待时间,默认单位是毫秒,也可以使用其他的时间单位后缀。
timeout check:
设置对后端服务器的检测超时时间,默认单位是毫秒,也可以使用其他的时间单位后缀。
frontend部分
bind:
option httplog:
在默认情况下,haproxy 日志是不记录 HTTP 请求的,这样很不方便 HAProxy 问题的排查与监控。通过此选项可以启用日志记录 HTTP 请求。
option forwardfor:
option httpclose:
此选项表示在客户端和服务器端完成一次连接请求后,HAProxy 将主动关闭此 TCP 连接。这是对性能非常有帮助的一个参数。
log global:
表示使用全局的日志配置,这里的“ global”表示引用在HAProxy 配置文件 global 部分中定义的 log 选项配置格式。
default_backend:
#指定默认的后端服务器池,也就是指定一组后端真实服务器,而这些真实服务器组将在 backend 段进行定义。这里的htmpool 就是一个后端服务器组。
backend部分
option redispatch:
此参数用于 cookie 保持的环境中。在默认情况下,HAProxy会将其请求的后端服务器的 serverID 插入到 cookie 中,以保证会话的 SESSION 持久性。而如果后端的服务器出现故障,客户端的 cookie 是不会刷新的,这就出现了问题。此时,如果设置此参数,就会将客户的请求强制定向到另外一个健康的后端服务器上,以保证服务的正常。
option abortonclose:
如果设置了此参数,可以在服务器负载很高的情况下, 自动结束掉当前队列中处理时间比较长的链接。
balance:
此关键字用来定义负载均衡算法。目前 HAProxy 支持多种负载均衡算法,常用的有如下几种:
--roundrobin 是基于权重进行轮询调度的算法,在服务器的性能分布比较均匀的时候,这是一种最公平、最合理的算法。此算法经常使用。
--static-rr 也是基于权重进行轮询的调度算法,不过此算法为静态方法,在运行时调整其服务器权重不会生效。
--source 是基于请求源 IP 的算法。此算法先对请求的源 IP 进行 hash 运算, 然后将结果与后端服务器的权重总数相除后转发至某个匹配的后端服务器。这种方式可以使同一个客户端 IP 的请求始终被转发到某特定的后端服务器。
--leastconn 此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法,例如数据库负载均衡等。此算法不 适合会话较短的环境中,例如基于 HTTP 的应用。
--uri 此算法会对部分或整个 URI 进行 hash 运算,再经过与服务器的总权重相除,最后转发到某台匹配的后端服务器上。
--uri_param 此算法会根据 URL 路径中的参数进行转发,这样可保证在后端真实服务器数量不变时,同一个用户的请求始终分发到同一台机器上。
--hdr(<name>): 此算法根据 http 头进行转发,如果指定的 http 头名称不存在,则使用 roundrobin 算法进行策略转发。
cookie:
表示允许向 cookie 插入 SERVERID,每台服务器的 SERVERID 可在下面的 server 关键字中使用 cookie 关键字定义。
option httpchk:
此选项表示启用 HTTP 的服务状态检测功能。HAProxy 作为一款专业的负载均衡器,它支持对 backend 部分指定的后端服务节点的健康检查,以保证在后端 backend 中某个节点不能服务时,把从 frotend 端进来的客户端请求分配至 backend 中其他健康节点上,从而保证整体服务的可用性。“option httpchk”的用法如下:
option httpchk <method> <uri> <version> 其中,各个参数的含义如下:
--method 表示 HTTP 请求的方式,常用的有 OPTIONS、GET、HEAD 几种方式。一般的健康检查可以采用 HEAD 方式进行,而不是才采用 GET 方式,这是因为 HEAD 方式没有数据返回,仅检查 Response 的 HEAD 是不是 200 状态。因此相对与 GET 来说,HEAD 方式更快,更简单。
--uri 表示要检测的 URL 地址,通过执行此 URL,可以获取后端服务器的运行状态。在正常情况下将返回状态码 200,返回其他状态码均为异常状态。
--version 指定心跳检测时的 HTTP 的版本号。
server:
这个关键字用来定义多个后端真实服务器,不能用于 defaults 和frontend部分。使用格式为:server <name> <address>[:port] [param*] 其中,每个参数含义如下:
check:
表示启用对此后端服务器执行健康状态检查。
inter:
设置健康状态检查的时间间隔,单位为毫秒。
rise:
设置从故障状态转换至正常状态需要成功检查的次数,例如。“rise 2”表示 2 次检查正确就认为此服务器可用。
fall:
设置后端服务器从正常状态转换为不可用状态需要检查的次数,例如,“fall 3”表示 3 次检查失败就认为此服务器不可用。
cookie:
为指定的后端服务器设定 cookie 值,此处指定的值将在请求入站时被检查,第一次为此值挑选的后端服务器将在后
--<name> 为后端真实服务器指定一个内部名称,随便定义一个即可。
--<address> 后端真实服务器的 IP 地址或主机名。
--<port> 指定连接请求发往真实服务器时的目标端口。在未设定时,将使用客户端请求时的同一端口。
--[param*] 为后端服务器设定的一系参数,可用参数非常多,这里仅介绍常用的一些参数:
----check:表示启用对此后端服务器执行健康状态检查。
----inter:设置健康状态检查的时间间隔,单位为毫秒。
----rise:设置从故障状态转换至正常状态需要成功检查的次数,例如。“rise 2”表示 2 次检查正确就认为此服务器可用。
----fall:设置后端服务器从正常状态转换为不可用状态需要检查的次数,例如,“fall 3”表示 3 次检查失败就认为此服务器不可用。
----cookie:为指定的后端服务器设定 cookie 值,此处指定的值将在请求入站时被检查,第一次为此值挑选的后端服务器将在后续的请求中一直被选中,其目的在于实现持久连接的功能。上面 的“cookie server1”表示 web1 的 serverid 为 server1。同理, “cookie server2”表示 web2 的 serverid 为 server2。
----weight:设置后端真实服务器的权重,默认为 1,最大值为 256。设置为 0 表示不参与负载均衡。
----backup:设置后端真实服务器的备份服务器,仅仅在后端所有真实服务器均不可用的情况下才启用。
服务启动
修改日志参数
需要修改日志文件,不然收不到日志信息
vim /etc/rsyslog.conf
ModLoad imudp #取消注释
UDPServerRun 514 #取消注释
local7.* /var/log/boot.log #下面添加两行
local3.* /var/log/haproxy.log
local0.* /var/log/haproxy.log
重启服务
systemctl restart rsyslog
启动haproxy
/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/etc/haproxy.cfg
查看状态
ps -aux | grep haproxy
nobody 25555 0.0 0.0 8888 2208 ? Ss 17:48 0:00 /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/etc/haproxy.cfg
关闭haproxy
killall haproxy
#没有killall命令?安装yum -y install psmisc
error
[WARNING] 233/154405 (19195) : Proxy 'http': in multi-process mode, stats will be limited to process assigned to the current request.
[WARNING] 233/154405 (19195) : Proxy 'http_back': in multi-process mode, stats will be limited to process assigned to the current request.
INFRA [root tests]#
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19198]: backend http_back has no server available!
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19198]: backend http_back has no server available!
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19197]: backend http_back has no server available!
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19197]: backend http_back has no server available!
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19196]: backend http_back has no server available!
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19196]: backend http_back has no server available!
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19199]: backend http_back has no server available!
Message from syslogd at Aug 22 15:44:06 ...
haproxy[19199]: backend http_back has no server available!
我这里查看日志是因为健康检查没有查到所定义的界面,所以会报错。可以把下面的
backend http_back #后端配置,名称上下关联
server s1 10.67.194.44:9090 weight 3 check inter 2000 rise 3 fall 3 #后端的主机 IP &权衡
check inter 2000字段删除,应该就可以正常访问了,
关键在于”option httpchk GET /graph “ 字段的/fraph是否正确,
另外也不建议用首页来测试,因为是一秒探测一次~!
这里推荐自己在当前目录下创建一个测试页面!
WEB
正常分发流量访问,也可以根据自己的需求来改动分发规则!
haproxy健康页面
stats uri /haproxy-stats 字段定义了健康页面
压测
具体ab测试见往期文章
编写ab.sh
#!/bin/bash
for i in `seq 1 1000`
do
ab -c 1000 -n 1000 http://10.67.194.43:9090/graph
done
修改配置文件
global
log 127.0.0.1 local0
#log 127.0.0.1 local1 notice
#log loghost local0 info
maxconn 4096
chroot /usr/local/haproxy
uid 99 #所属运行的用户uid
gid 99 #所属运行的用户组
daemon #以后台形式运行haproxy
nbproc 4 #启动1个haproxy实例。# #工作进程数量(CPU数量) ,实际工作中,应该设置成和CPU核心数一样。这样可以发挥出最大的性能。
pidfile /usr/local/haproxy/run/haproxy.pid #将所有进程写入pid文件
ulimit-n 1000000 ##这里增大文件打开数
max-spread-checks 1000ms
maxconn 30000000 ##这里放开限制
maxconnrate 30000000
maxsessrate 30000000
maxsslrate 30000000
#debug #调试错误时用
#quiet #安静
defaults
log global
log 127.0.0.1 local3 #日志文件的输出定向。产生的日志级别为local3. 系统中local1-7,用户自己定义
mode http #工作模式,所处理的类别,默认采用http模式,可配置成tcp作4层消息转发
option httplog #日志类别,记载http日志
option httpclose #每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现
option dontlognull #不记录空连接,产生的日志
option forwardfor #如果后端服务器需要获得客户端真实ip需要配置的参数,可以从Http Header中获得客户端ip
option redispatch #当serverid对应的服务器挂掉后,强制定向到其他健康服务器
retries 2 #2次连接失败就认为服务器不可用,主要通过后面的check检查
balance roundrobin #负载均衡算法
timeout connect 5000 #连接超时时间。单位:ms 毫秒
timeout client 50000 #客户端连接超时时间
timeout server 50000 #服务器端连接超时时间
mode http
option httpchk GET /graph #健康检测#注意实际工作中测试时,应该下载某一个页面来进行测试,因此这个页面应该是个小页面,而不要用首页面。这里是每隔一秒检查一次页面。
frontend http #前端配置,http名称可自定义
bind 10.67.194.43:9090 #发起http请求80端口,会被转发到设置的ip及端口
default_backend http_back #转发到后端 写上后端名称
backend http_back #后端配置,名称上下关联
server s1 10.67.194.44:9090 check inter 2000 rise 3 fall 3 weight 3 #后端的主机 IP &权衡
server s2 10.67.194.37:9090 check inter 2000 rise 3 fall 3 weight 3 #后端的主机 IP &权衡
#server node1 192.168.179.131:8081 check inter 2000 rise 3 fall 3 weight 30
# inter 2000 健康检查时间间隔2秒
# rise 3 检测多少次才认为是正常的
# fall 3 失败多少次才认为是不可用的
# weight 30 权重
listen admin_stats
bind 0.0.0.0:9188
mode http
stats uri /haproxy-status
开始测试
yum -y install httpd-tools
chmod +x ab.sh
./ab.sh
查看结果(选取最后一次)
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 10.67.194.43 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software:
Server Hostname: 10.67.194.43
Server Port: 9090
Document Path: /graph
Document Length: 90 bytes
Concurrency Level: 1000
Time taken for tests: 0.059 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
responses: 1000
Total transferred: 187000 bytes
html transferred: 90000 bytes
Requests per second: 16854.31 [#/sec] (mean)
Time per request: 59.332 [ms] (mean)
Time per request: 0.059 [ms] (mean, across all concurrent requests)
Transfer rate: 3077.89 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 21 6.0 21 32
Processing: 12 15 1.4 15 32
Waiting: 0 8 3.3 8 19
Total: 27 36 5.4 36 48
Percentage of the requests served within a certain time (ms)
36
38
39
40
43
47
48
48
48 (longest request)
--每1000次测试花费0.059 seconds
--总传输字节187000 bytes
--每秒处理请求16854.31 [#/sec]
--平均请求响应时间 59.332 [ms]
结果还可以...
完
以上是关于HAproxy负载均衡剖析的主要内容,如果未能解决你的问题,请参考以下文章