haproxy 、haproxy配置

HAProxy介绍

HAProxy是一个单线程，事件驱动的非阻塞引擎，它将一个非常快速的I / O层与一个基于优先级的调度器结合在一起。由于其设计时考虑了数据转发目标，因此其架构经过优化，可尽可能快地将数据移动到最少的操作。因此，它实现了在每个级别提供旁路机制的分层模型，确保数据不会达到更高的水平，除非需要。大多数处理在内核中执行，HAProxy尽可能快地通过

提供一些提示或避免某些操作来帮助内核尽快完成工作，当它猜测它们可以被分组以后。结果，典型的数字显示了15％的处理时间花费在HAProxy上，在TCP或HTTP关闭模式下花费在内核上的85％，在HAProxy上花费约30％，在HTTP保持花费模式下花费70％。

一个进程可以运行多个代理实例; 据报道，单个进程中30万个不同代理的配置运行良好。因此，通常不需要为所有实例启动多个进程。

有可能使HAProxy运行在多个进程上，但是它有一些限制。一般来说，在HTTP关闭或TCP模式下没有意义，因为内核端不能很好地进行一些操作，比如connect（）。对于HTTP保持活动模式，性能非常好可以通过一个单一的流程来实现，这个流程通常比一般的需求要好一个数量级。当用作SSL 卸载程序时，这是有意义的，而且这个特性在多进程模式下得到很好的支持。

HAProxy只需要haproxy可执行文件和配置文件即可运行。对于日志记录，强烈建议使用正确配置的syslog守护进程

和日志循环。配置文件在启动之前被解析，然后HAProxy尝试绑定所有监听套接字，如果有任何失败，则拒绝启动。过去这一点，它不能再失败了。这意味着没有运行时失败，如果它接受启动，它将工作，直到停止。

一旦HAProxy启动，它确实做了三件事情：

处理传入连接是迄今为止最复杂的任务，因为它依赖

于很多配置可能性，但是可以概括为以下9个步骤：

前端和后端有时被视为半代理，因为他们只看端到端连接的一端; 前端只关心客户端，而后端只关心服务器。HAProxy还支持

完整的代理，这正是前端和后端的联合。当需要进行HTTP 处理时，配置通常会被分割成前端和后端，因为任何前端都可能将

连接传递给任何后端。相对于TCP-only代理，使用前端和后端的一个好处是配置比用完整的代理更可读。

Haproxy实现web的页面的动静分离

一、Haproxy概述；

概述：Haproxy是一个开源的高性能的反向代理或者说是负载均衡服务软件之一，由C语言编写而成，支持会话保持、七层处理、健康检查、故障修复后自动加载、动静分离。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接；

Haproxy软件引入了frontend，backend的功能，frontend（acl规则匹配）可以运维管理人员根据任意HTTP请求头做规则匹配，然后把请求定向到相关的backend（server pools等待前端把请求转过来的服务器组）。

二、Haproxy原理实现；

代理模式：

1.四层tcp代理：例如：可用于邮件服务内部协议通信服务器、Mysql服务等；

2.七层应用代理：例如：HTTP代理或https代理。在4层tcp代理模式下，Haproxy仅在客户端和服务器之间双向转发流量。但是在7层模式下Haproxy会分析应用层协议，并且能通过运行、拒绝、交换、增加、修改或者删除请求（request）或者回应（reponse）里指定内容来控制协议。

四层代理：

ISO参考模型中的第四层传输层。四层负载均衡也称为四层交换机，它主要是通过分析IP层及TCP/UDP层的流量实现的基于IP加端口的负载均衡。常见的基于四层的负载均衡器有LVS、F5等。以常见的TCP应用为例，负载均衡器在接收到***个来自客户端的SYN请求时，会通过设定的负载均衡算法选择一个***的后端服务器，同时将报文中目标IP地址修改为后端服务器IP，然后直接转发给该后端服务器，这样一个负载均衡请求就完成了。从这个过程来看，一个TCP连接是客户端和服务器直接建立的，而负载均衡器只不过完成了一个类似路由器的转发动作。在某些负载均衡策略中，为保证后端服务器返回的报文可以正确传递给负载均衡器，在转发报文的同时可能还会对报文原来的源地址进行修改。整个过程下图所示。

七层代理：

ISO参考模型中的***层第七层应用层。七层负载均衡也称为七层交换机，此时负载均衡器支持多种应用协议，常见的有HTTP、FTP、SMTP等。七层负载均衡器可以根据报文内容，再配合负载均衡算法来选择后端服务器，因此也称为“内容交换器”。比如，对于Web服务器的负载均衡，七层负载均衡器不但可以根据“IP+端口”的方式进行负载分流，还可以根据网站的URL、访问域名、浏览器类别、语言等决定负载均衡的策略。例如，有两台Web服务器分别对应中英文两个网站，两个域名分别是A、B，要实现访问A域名时进入中文网站，访问B域名时进入英文网站，这在四层负载均衡器中几乎是无法实现的，而七层负载均衡可以根据客户端访问域名的不同选择对应的网页进行负载均衡处理。常见的七层负载均衡器有HAproxy、Nginx等。

这里仍以常见的TCP应用为例，由于负载均衡器要获取到报文的内容，因此只能先代替后端服务器和客户端建立连接，接着，才能收到客户端发送过来的报文内容，然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡算法来决定最终选择的内部服务器。纵观整个过程，七层负载均衡器在这种情况下类似于一个代理服务器。整个过程如下图所示。

三、常见的代理了解

1、lvs和硬件F5，是基于IP的三层负载，硬件适配性能好，处理性能强。

2、haproxy，可以适配三层负载均衡，同样可以适配七层。对于页面明确有请求分离的时候，可以使用haproxy。

3、nginx，对于日PV小于500万，对于需要进行高并发的站点，可以使用nginx代理

四、haproxy配置文件讲解

五、案例：Haproxy+Nginx+Tomcat搭建高可用集群

实例步骤

1、配置tomcat服务器

2、安装haproxy

3、配置haproxy服务：

4、测试集群

5、配置haproxy的日志文件分离（查看haproxy日志）

6、配置haproxy服务器的日志管理web界面

测试

看到以上界面实验就做完了

END

Haproxy 8种算法+Session共享

Haproxy有8种负载均衡算法（balance），分别如下：

1.balanceroundrobin# 轮询，软负载均衡基本都具备这种算法

2.balancestatic-rr# 根据权重，建议使用

3.balanceleastconn# 最少连接者先处理，建议使用

4.balancesource# 根据请求源IP，建议使用

5.balanceuri# 根据请求的URI

6.balanceurl_param，#根据请求的URl参数'balanceurl_param'requiresanURLparametername

7.balancehdr(name)# 根据HTTP请求头来锁定每一次HTTP请求

8.balancerdp-cookie(name)# 根据据cookie(name)来锁定并哈希每一次TCP请求

由于负载请求分发到不同服务器，可能导致Session会话不同步的问题，若想实现会话共享或保持，可采用如下3种方式：

1.用户IP 识别

haroxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令）

配置指令

balance source

2.cookie 识别

haproxy 将WEB服务端发送给客户端的cookie中插入(或添加加前缀)haproxy定义的后端的服务器cookie ID。

配置指令例举

cookie SESSION_cookie insert indirect nocache

用firebug可以观察到用户的请求头的cookie里 有类似” cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5; SESSION_cookie=app1” SESSION_cookie=app1就是haproxy添加的内容

3.Session 识别

haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。

配置指令例举

appsession JSESSIonID len 64 timeout 5h request-learn

HAProxy 的 ACLs 详解

编译自：

using ACLs and pattern extraction

文档版本：HAProxy version 1.4.27

目录：

使用 ACLs，可以基于请求和响应的任何部分，进行服务内容的切换。总的原则如下：

acl 关键字用于定义一条新的测试准则，或者对一条已经存在的测试准则进行重新定义：

criterion：

指定对请求或者响应的某个部分进行测试

[flags]：

对测试进行调整

[operator]：

value：

注，ACL名称只能使用大写字母、小写字母、数字、-(中线)、_(下划线)、.(点号)和:(冒号)。此外，ACL名称会区分字母大小写。my_acl 和 My_Acl 是两个不同的 ACLs。

对 ACLs 的数量没有限制，它们只占用少量内存。

整数匹配的规则：

1. 允许范围匹配

例如：

1024:65535

1024:

0:1023

:1023

这是指准确的字符串匹配，有一些规则如下：

基本规则同上

匹配某个IP地址：

192.168.0.110

（支持使用主机名，但不推荐这样做，因为对配置来讲，会造成阅读和调试上的困难）

如果使用主机名，需确保 /etc/hosts 中有对应的解析条目，不要依赖 DNS 解析。

匹配某个网络：

192.168.0.0/24

这是***部分的测试区域，不需要对请求或响应的内容进行分析。其中包含 TCP/IP 地址和端口，以及一些与流量无关的内部信息。

alw***s_false

这个永远不会匹配。所有的 values 和 flags 被忽略。可在调整配置时使用。

alw***s_true

这个永远匹配。所有的 values 和 flags 被忽略。可在调整配置时使用。

avg_queue integer

avg_queue(backend) integer

某个指定 backend 的等待队列长度的平均数，如果在指定范围内，返回 ture。

返回值为：某个 backend 的等待连接总数 / 该 backend 活动的后端服务器总数。

根据该值，可大致判断一个新的连接需要等待多久才会被处理。

其主要使用场景是，当某个新的用户确定只能得到降级的服务，返回一个 sorry page 给该用户。

应注意的是，当 backend 中没有活动的服务器了，我们会把等待队列的连接数x2，作为测量值。这是一个公平的预测，因为我们期望有一台服务器能快速归位。但这种情况下，更好的方法是将流量转发给另一个后端。

be_conn integer

be_conn(backend) integer

返回指定 backend 中当前已建立的连接数（possibly including the connection being evaluated），如果在指定范围内，返回 ture。

如果没有特别指定是那个 backend，则表示使用当前的 backend。

可用于这样的场景，如果被测试的 backend 中连接数已经满负荷，将其流量转发给另一个 backend。

be_id integer

返回 backend 的 id。可在 frontend 中使用，用于检测是被哪一个 backend 所调用。

be_sess_rate integer

be_sess_rate(backend) integer

返回“会话创建速率”：new sessions/s，如果在指定范围内，返回 true。

使用场景：

示例：

connslots integer

connslots(backend) integer

connslots = backend 服务器剩余的可容纳的连接数 + backend 的等待队列中剩余的可容纳的连接数，在指定范围内时返回 true。

简单来说，就是衡量一个 backend 当前还能接收多少新建连接。基于这个值，可以做更好的负载均衡。一般配合 fe_conn（frontend 当前已经接收的连接数） 一起做判断。

dst ip_address

返回当前客户端所连接的本地的 IPv4 地址。It can be used to

switch to a different backend for some alternative addresses.

dst_conn integer

返回一个socket 上已经建立的连接数（including the one being evaluated）。如果当前接收的连接数已经到达满负荷，可用于在 hard-blocking 之前返回 sorry 页面；或者，使用某个指定的 backend 接收新的请求。

我们可以使用它对不同的监听地址设置不同的限制。

dst_port integer

返回当前客户端所连接的本地的端口地址。It can be used to switch

to a different backend for some alternative ports.

fe_conn integer

fe_conn(frontend) integer

返回某个 frontend 中已经建立的连接数（possibly including the connection being evaluated），如果在指定范围内，返回 true。

如果未指定是哪个 frontend，使用当前的 frontend。

如果所关联的 backend 接收的连接数被认为已经到达满负荷，可用于在 hard-blocking 之前返回 sorry 页面；或者，使用某个指定的 backend 接收新的请求。

fe_id integer

返回 frontend 的 id。在 backend 中可使用它判断自己是被哪个 frontend 所调用。

fe_sess_rate integer

fe_sess_rate(frontend) integer

返回 frontend 的 “新建会话速率”。单位为：新建会话数/秒。如果在指定范围内，返回 true。

一般使用场景：限制新建连接的速率为一个可接受的范围内。在***时间防止服务滥用。防止 ddos 攻击等。

结合 4层 ACLs，可强制让一个客户端等待少许时间，等待新建会话率降至合理范围内。

示例：

nbsrv integer

nbsrv(backend) integer

返回当前 backend 或某个指定的 backend 的可用服务器数。当可用服务器数过低时，可切换到其他 backend。

一般和 monitor fail 配合使用。

queue integer

queue(backend) integer

返回当前 backend 或某个指定的 backend 的等待队列中的连接数。

当队列长度超过警戒值，一般意味着遇到访问高峰，或者大量的服务器失效。一种可行的措施是拒绝新的用户，并且维持旧的连接。

so_id integer

返回 socket 的 id。

用于 frontend，当有多个 bind 关键字时，也就是监听了多个地址时，是有用的。

src ip_address

返回客户端的 IPv4 地址。

一般用于对某些资源进行访问限制，比如统计数据资源。

src_port integer

返回客户端的 TCP source port。用处较少。

srv_id integer

返回 server 的 id。

可用于 frontend 和 backend

srv_is_up(server)

srv_is_up(backend/server)

当指定 backend 或当前 backend 中的 server 正在运行，返回 true，否则返回 false。

不接受参数。

当健康检查报告了一个外部状态时（eg: a geographical site's availability），采取一定的动作。

第二部分的测试区域，基于缓存中找到的数据，它们在分析的过程可能就会发生变化。

要求有数据被缓存，常用于 “TCP 请求内容检查”：

req_len integer

如果在 request buffer 中的数据长度匹配了指定的范围，返回 true。

如果 buffer is changing，那么就不会返回 false。在一个会话刚开始的时候，req_len eq 0 是肯定匹配的。

对于 req_len ge 大于0的整数，会等待数据进入 buffer，如果 haproxy 确定没有数据进来时，才会返回 false。

用于 “TCP 请求内容检查”

req_proto_http

如果在 请求buffer 中的数据看起来像是 HTTP 或者能被当做 HTTP 进行正确解析，返回 true。

通过 “TCP 请求内容检查” 的规则，可用于调度 HTTP 流量和 HTTPS 流量到不同的端口地址。

req_rdp_cookie string

req_rdp_cookie(name) string

远程桌面协议相关

req_rdp_cookie_cnt integer

req_rdp_cookie_cnt(name) integer

远程桌面协议相关

req_ssl_ver decimal

如果在请求缓存中的数据，看起来像 SSL 协议数据，而且协议版本在指定的范围内，返回 ture。

支持 SSLv2 hello messages 和 SSLv3 messages。

此测试意在进行严格限制，尽量避免被轻易地欺骗。

In particular, it waits for as many bytes as announced in the

message header if this header looks valid (bound to the buffer size)

注意，TLSv1 协议将被称为 SSL version 3.1。

用于 “TCP 请求内容检查”

wait_end

等待分析周期结束，返回 true。

一般与内容分析联合使用，避免过早返回一个错误的结论。

也可用于延迟某些动作，比如拒绝某些指定的IP地址的动作。

因为它要么停止规则检查，要么立即返回 true，所以建议在一条规则的最后使用这个 acl。

注意，默认的 ACL "WAIT_END" 总是可用的，不需要预先声明。

本测试用于 “TCP 请求内容检查”

示例：

第三部分的测试区域，是七层测试。要求对 HTTP 请求进行完全的解析之后进行。

因为请求和响应都被建立了索引，所以虽然相比四层匹配要求更多的 CPU 资源，但也不会太多。

hdr string

hdr(header) string

hdr* 匹配所有 headers，hdr*(header) 匹配指定的 header，注意括号里面不能有空格。

指定首部时，其名称不区分大小写；

The header matching complies with RFC2616, and treats all values delimited by commas as separate headers.

对于响应首部，使用 shdr()；

示例，检查是否设置了 "connection: close" ：

hdr_beg string

hdr_beg(header) string

任何一个 header 的值是以 string 起始的，返回 true

对于响应首部，使用 shdr_beg()；

hdr_cnt integer

hdr_cnt(header) integer

如果指定的 header 出现的次数在指定范围内，或匹配指定的值，返回 true；

一行 header 语句如果包含多个值，将被多次计数；

用于检查指定 header 的是否存在，是否被滥用；

通过拒绝含有多个指定 header 的请求，可阻挡 request ***uggling attacks；

对于响应首部，使用 shdr_cnt()；

hdr_dir string

hdr_dir(header) string

用于文件名或目录名匹配，当某个 header 包含被 / 分隔的 string，返回 true；

可与 Referer 联合使用；

对于响应首部，使用 shdr_dir()；

hdr_dom string

hdr_dom(header) string

用于域名匹配，可与 Host header 一起使用；当某个 header 包含被 . 分隔的 string，返回 true；

对于响应首部，使用 shdr_dom()；

hdr_end string

hdr_end(header) string

当任何一个 header 的值是以 string 结束的，返回 true

对于响应首部，使用 shdr_end()；

hdr_ip ip_address

hdr_ip(header) ip_address

当某个 header 的值包含匹配 ip_address 的值，返回 true；

通常与 X-Forwarded-For or X-Client-IP 一起使用；

对于响应首部，使用 shdr_ip()；

hdr_len integer

hdr_len(header) integer

至少有一个 header 的 length 与指定的值或者范围匹配时，返回 true；

对于响应首部，使用 shdr_len()；

hdr_reg regex

hdr_reg(header) regex

有一个 header 与正则表达式匹配时，返回 true，可在任何时候使用；

注意，正则匹配比其他匹配更慢；

对于响应首部，使用 shdr_reg()；

hdr_sub string

hdr_sub(header) string

有一个 header 包含其中一个 string 时，返回 true；

对于响应首部，使用 shdr_sub()；

hdr_val integer

hdr_val(header) integer

有一个 header 起始的数字，与指定值或范围匹配；可用于限制 content-length，只接受合理长度的请求；

对于响应首部，使用 shdr_val()；

http_***th(userlist)

http_***th_group(userlist) group [group]*

从客户端收到的认证信息与 userlist 中记录的匹配时，返回 true；

目前只支持 http basic ***th；

http_first_req

如果处理的请求是连接的***个请求，返回 true；

method string

用于检查 HTTP 请求的方法，匹配时，返回 true；

path string

请求中的 path 部分（以 / 起始，到 ? 为止的部分），与某个 string 相等时，返回 true；

可用于匹配某个文件，比如：/favicon.ico

path_beg string

当 path 以某个 string 为起始，返回 true；可用于发送某些目录名到 alternative backend；

path_dir string

当 path 中包含以 / 分隔的 string 时，返回 true；可用于匹配文件名或目录名；

path_dom string

当 path 中包含以 . 分隔的 string 时，返回 true；可用于域名匹配；

path_end string

当 path 以某个 string 为结束时，返回 true；可用于控制文件扩展名；

path_len integer

当 path 的长度与指定值或范围匹配时，返回 true；可用于检测 abusive requests；

path_reg regex

当 path 与正则表达式匹配时，返回 true；

path_sub string

当 path 包含某个 string 时，返回 true；可用于检测 path 中的指定模式，比如 “../”；

req_ver string

用于检查 HTTP 请求的版本，比如 1.0；

status integer

用于检查 HTTP response 的状态码，比如 302；

可根据状态码做一定的动作，比如，如果 response 的状态码不是 3xx，则删除 Location header；

url string

应用于请求中的整个 URL；真正的用处是匹配 *，已有一个预定义的 ACL： HTTP_URL_STAR；

url_beg string

当 URL 以某个 string 起始时，返回 true；可用于检查是否以 / 或者某个协议的 scheme 起始；

url_dir string

如果 URL 中包含以 / 分隔的 string，返回 true；用于文件名和目录名匹配；

url_dom string

如果 URL 中包含以 . 分隔的 string，返回 true；用于域名匹配；

url_end string

当 URL 以某个 string 结束时，返回 true；用处很少；

url_ip ip_address

用于检查 HTTP 请求中，绝对 URI 中所指定的 IP 地址；可用于根据 IP 地址做资源的访问限制；

跟 http_proxy 一起用时可发挥作用；

url_len integer

当 URL 的长度与指定值或范围匹配时，返回 true；可用于检测 abusive requests；

url_port integer

用于检查 HTTP 请求中，绝对 URI 中所指定的 PORT 地址；可用于根据 PORT 地址做资源的访问限制；

跟 http_proxy 一起用时可发挥作用；

注意，如果请求中没有指定端口，则表示端口为 80；

url_reg regex

当 URL 与正则表达式匹配时，返回 true；

url_sub string

当 URL 包含某个 string 时，返回 true；可用于检查 query string 中的某些 pattern；

预定义的 ACLs 不需要声明，可以直接使用。它们的命名都是大写字母。

有些 actions 只在满足了有效的条件时才能执行；条件是 ACLs 的逻辑组合；

有三个可用的逻辑运算符：

一个条件的构成：

actions 配合条件：

例如，构造一个条件，希望阻挡满足条件 HTTP 请求，满足如下条件之一时，拒绝该请求：

规则是：

例2.

建立 url_static 测试，当 path 以 /static、/images、/img、/css 起始，或者以 .gif、.png、.jpg、.css、.js 结尾，返回 true；

建立 host_www 测试，当请求的 Host 首部字段以 www 起始，返回 true，忽略大小写；

建立 host_static 测试，当请求的 Host 首部字段以 img. video. download. ftp. 之一为起始，返回 true，忽略大小写；

满足 host_static 测试，或者 host_www AND url_static 测试的请求，转发给 static backend；

只满足 host_www 测试的请求，转发 www backend；

HAProxy 支持使用匿名的 ACLs；不需要事先声明；它们必须被 { ACLs } 括起来，注意空格；例如：

一般而言，不建议使用匿名的 ACL，因为更容易出现错误；

只有对于简单 ACLs，比如匹配一个 src IP地址，这时使用匿名更容易阅读：

The stickiness features relies on pattern extraction in the request and

response. Sometimes the data needs to be converted first before being stored,

for instance converted from ASCII to IP or upper case to lower case.

All these operations of data extraction and conversion are defined as

"pattern extraction rules". A pattern rule alw***s has the same format. It

begins with a single pattern fetch word, potentially followed by a list of

arguments within parenthesis then an optional list of transformations. As

much as possible, the pattern fetch functions use the same name as their

equivalent used in ACLs.

The list of currently supported pattern fetch functions is the following :

src This is the source IPv4 address of the client of the session.

It is of type IP and only works with such tables.

dst This is the destination IPv4 address of the session on the

client side, which is the address the client connected to.

It can be useful when running in transparent mode. It is of

type IP and only works with such tables.

dst_port This is the destination TCP port of the session on the client

side, which is the port the client connected to. This might be

used when running in transparent mode or when assigning dynamic

ports to some clients for a whole application session. It is of

type integer and only works with such tables.

hdr(name) This extracts the last occurrence of header name in an HTTP

request and converts it to an IP address. This IP address is

then used to match the table. A typical use is with the

x-forwarded-for header.

The currently available list of transformations include :

lower Convert a string pattern to lower case. This can only be placed

after a string pattern fetch function or after a conversion

function returning a string type. The result is of type string.

upper Convert a string pattern to upper case. This can only be placed

after a string pattern fetch function or after a conversion

function returning a string type. The result is of type string.

ipmask(mask) Apply a mask to an IPv4 address, and use the result for lookups

and storage. This can be used to make all hosts within a

certain mask to share the same table entries and as such use

the same server. The mask can be passed in dotted form (eg:

255.255.255.0) or in CIDR form (eg: 24).

haproxy故障（cannot raise FD limit to ）

如下图所示，出现这个错误。

这个是windows下的错误，haproxy版本1.7.10.

查找原因：如果是在linux平台下，可以调整系统的ulimit -n 参数，但是 在windows系统下，未找到如何设置 。

提示：HAProxy要求系统的ulimit -n参数大于[maxconn*2+18]，在设置较大的maxconn时，需要检查并修改ulimit -n参数。

在linux平台下，可以采用如下策略实现高可用（keepalived+haproxy）。

即：

在两台物理机上安装并配置HAProxy，两台主机上上安装两套完全一样的HAProxy。

在两台HAProxy的主机上 分别 运行着一个Keepalived实例，这两个Keepalived争抢同一个虚IP地址，两个HAProxy也尝试去绑定这同一个虚IP地址上的端口。

显然，同时只能有一个Keepalived抢到这个虚IP，抢到了这个虚IP的Keepalived主机上的HAProxy便是当前的MASTER。

Keepalived内部维护一个权重值，权重值***的Keepalived实例能够抢到虚IP。同时Keepalived会定期check本主机上的HAProxy状态，状态OK时权重值增加。

关于haproxy和haproxy配置的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。