网站导航
> 技术文档 > 解密负载均衡：如何轻松提升业务性能

解密负载均衡：如何轻松提升业务性能

网友: 技术文档 2025-07-26 20:31:59

什么是负载均衡 负载均衡： Load Balance ，简称 LB ，是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均衡将特定的业务(web 服务、网络流量等 ) 分担给指定的一个或多个后端特定的服务器或设备，从而提高了 公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展。 【将流量按照合理的方式打在合适的服务器上】 【LVS是最前端的调度器，后端的调度就由haproxy来执行】 为什么用负载均衡

Web服务器动态水平扩展 --> 对用户完全透明
提升业务并发处理能力 --> 有效解决单服务器性能瓶颈
优化公网IP资源 --> 显著降低IT运营成本
保护内部服务器IP --> 增强系统安全性
简易配置 --> 采用标准化配置文件格式
功能全面 --> 同时支持四层和七层协议，支持主机动态移除
高性能表现 --> 轻松应对数万至数十万并发请求

负载均衡类型 硬件

F5

  • 美国F5网络公司官网：F5 | 多云安全和应用交付

Netscaler

  • 美国思杰公司产品页面：NetScaler: Application Delivery at Scale

Array

  • 华耀官网：北京华耀科技有限公司

AD-1000

  • 深信服官网：深信服 - 让每个用户的数字化更简单、更安全

四层负载均衡 1. 通过 ip+port 决定负载均衡的去向。 2. 对流量请求进行 NAT 处理，转发至后台服务器。 3. 记录 tcp 、 udp 流量分别是由哪台服务器处理，后续该请求连接的流量都通过该服务器处理。 【即使客户端和服务器中夹着一个调度器，客户端还是回和服务器有一定的网络通信的】 支持四层的软件 lvs ：重量级四层负载均衡器。 Nginx ：轻量级四层负载均衡器，可缓存。（ nginx 四层是通过 upstream 模块） Haproxy ：模拟四层转发。 七层负载均衡 1. 通过虚拟 ur| 或主机 ip 进行流量识别，根据应用层信息进行解析，决定是否需要进行负载均衡。 2. 代理后台服务器与客户端建立连接，如 nginx 可代理前后端，与前端客户端 tcp 连接，与后端服务器建立 tcp 连接 , 【客户端与服务器是没有网络链接的，二者是相互独立的个体。二者通过中的的调度器调度：客户端发送报文给调度器，调度器拆包将其调度给合适的服务器；之后，服务器发送报文给调度器，调度器再发给客户端。速度比四层的LVS慢一点，毕竟不是服务器和客户端的直接连接发送】 支持 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 攻击 haproxy 简介

HAProxy是由法国开发者威利塔罗(Willy Tarreau)于2000年使用C语言开发的开源软件。

作为一款高性能负载均衡器，它支持TCP和HTTP协议，具备万级以上的高并发处理能力。主要特性包括：

  • 基于cookie的会话保持
  • 自动故障转移
  • 正则表达式支持
  • 实时Web状态统计

资源链接：

  • 企业版官网：HAProxy Technologies | Powering the World\'s Busiest Applications
  • 社区版官网：http://www.haproxy.org
  • GitHub仓库：https://github.com/haprox

haproxy 的安装和服务信息 【用户在通过火墙后，认可用户可以使用HAPROXY并开始访问，HAPROXY通过客户的请求将相应流量调度给后端相应的服务器上；与LVS架构很类似】 实验环境【关闭防火墙、SELinux】 IP为172.25.254.的是nat模式 IP为192.168.0.的是仅主机模式

功能 IP 客户端 172.25.254.111 haproxy 172.25.254.100;192.168.0.10 RS1 172.25.254.10 RS2 172.25.254.20

软件安装 安装软件包 

dnf install haproxy -y

查看版本 

haproxy -v

haproxy 软件基本信息 

软件安装包： haproxy-2.4.22-3.el9_3.x86_64.rpm启动文件： /lib/systemd/system/haproxy.service主配置目录： /etc/haproxy/主配置文件： /etc/haproxy/haproxy.cfg子配置目录： /etc/haproxy/conf.d

官方文档： http://cbonte.github.io/haproxy-dconv/ 多进程和线程 多进程和 socket 文件配置如下，在haproxy中进行： 

vim /etc/haproxy/haproxy.cfg
# turn on stats unix socketstats socket /var/lib/haproxy/haproxy.sock1 mode 600 level admin process 1 #启用多个sock文件stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2nbproc 2 #启用多进程cpu-map 1 0 #进程和cpu核心绑定防止cpu抖动从而减少系统资源消耗cpu-map 2 1 #2 表示第二个进程，1表示第二个cpu核心

systemctl start haproxy.service

查看： 

pstree -p | grep haproxy

启用多线程： 

vim /etc/haproxy/haproxy.cfg
nbthread 2 #启用多线程

systemctl restart haproxy.service

查看：

systemctl restart haproxy.service

多线程对比 【如果开启多线程的话，需要线程与CPU进行绑定，每个线程对应一个自己的CPU，减少不必要的时间损耗】 

cat /proc/xxxx(haproxy子进程id)/status

Proxies 配置 -defaults 

defaultsmode http #HAProxy实例使用的连接协议log global #指定日志地址和记录日志条目的syslog/rsyslog日志设备#此处的 global表示使用 global配置段中设定的log值。option httplog #日志记录选项，httplog表示记录与 HTTP会话相关的各种属性值#包括 HTTP请求、会话状态、连接数、源地址以及连接时间等option dontlognull #dontlognull表示不记录空会话连接日志option http-server-close #等待客户端完整HTTP请求的时间，此处为等待10s。option forwardfor except 127.0.0.0/8 #透传客户端真实IP至后端web服务器#在apache配置文件中加入:
%{XForwarded-For}i#后在webserver中看日志即可看到地址透传信息option redispatch #当server Id对应的服务器挂掉后，强制定向到其他健康的服务器，重新派发option http-keep-alive #开启与客户端的会话保持retries 3 #连接后端服务器失败次数3.3.2.3 Proxies配置-frontendfrontend 配置参数：frontend 配置示例：timeout http-request 10s #等待客户端请求完全被接收和处理的最长时间timeout queue 1m #设置删除连接和客户端收到503或服务不可用等提示信息前的等待时间timeout connect 120s #设置等待服务器连接成功的时间timeout client 600s #设置允许客户端处于非活动状态，即既不发送数据也不接收数据的时间timeout server 600s #设置服务器超时时间，即允许服务器处于既不接收也不发送数据的非活动时间timeout http-keep-alive 60s #session 会话保持超时时间，此时间段内会转发到相同的后端服务器timeout check 10s #指定后端服务器健康检查的超时时间maxconn 3000default-server inter 1000 weight 3

systemctl restart haproxy.service

Proxies 配置 -frontend 

frontend lee-webserver-80bind 172.25.254.100:80mode httpuse_backend lee-webserver-80-RS

Proxies 配置 -backend 

backend lee-webserver-80-RSmode httpserver web1 172.25.254.10:80 check inter 3s fall 3 rise 5server web2 172.25.254.20:80 check inter 3s fall 3 rise 5

systemctl restart haproxy.service

测试：

在RS1,RS2安装nginx:

dnf install nginx -y

开启：

systemctl start nginx

在网页文档中写入内容：

#写在RS1echo RS1 -172.25.254.10 > /usr/share/nginx/html/index.html#写在RS2echo RS2 -172.25.254.20 > /usr/share/nginx/html/index.html

在客户端测试：

for N in {1..6};do curl 172.25.254.100;done

Proxies 配置 -listen 简化配置 使用 listen 替换 frontend 和 backend 的配置方式，可以简化设置，通常只用于 TCP 协议的应用 

 99 listen webserver100 bind *:80101 mode http102 balance static-rr103 server webserver1 172.25.254.10:80 check inter 3s fall 3 weight 2104 server webserver2 172.25.254.20:80 check inter 3s fall 3 weight 2

systemctl restart haproxy.service

客户端测试：

for N in {1..6};do curl 172.25.254.100;done

socat 工具 haproxy安装socat工具： 

dnf install socat -y

修改配置文件：

vim /etc/haproxy/haproxy.cfgstats socket /var/lib/haproxy/stats mode 600 level adminsystemctl restart haproxy.service

查看帮助： 

socat -hecho \"help\" | socat stdio /var/lib/haproxy/stats

查看 haproxy 状态： 

echo \"show info\" | socat stdio /var/lib/haproxy/stats

查看集群状态： 

echo \"show servers state\" | socat stdio /var/lib/haproxy/stats

查看集群权重： 

 echo get weight webserver/web1 | socat stdio /var/lib/haproxy/stats

设置集群权重： 

echo set weight webserver/web1 1 | socat stdio /var/lib/haproxy/stats

后端服务器： 下线： 

echo \"disable server webserver/web1 \" | socat stdio /var/lib/haproxy/stats

上线：

echo \"enable server webserver/web1 \" | socat stdio /var/lib/haproxy/stats

haproxy 的状态界面 

vim /etc/haproxy/haproxy.cfg...上面内容省略...listen statsmode httpbind *:1616stats enablelog globalstats uri /haproxy-statusstats auth lee:lee

haproxy 的算法 客户端进行测试 

while true;do curl 172.25.254.100 ; sleep 0.1;done

【 HAProxy通过固定参数 balance 指明对后端服务器的调度算法 balance参数可以配置在listen或backend选项中。 HAProxy的调度算法分为静态和动态调度算法 有些算法可以根据参数在静态和动态算法中相互转换。 】 静态算法 静态算法：按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、连接数和响应速度 等，且无法实时修改权重 ( 只能为 0 和 1, 不支持其它值 ) ，只能靠重启 HAProxy 生效。 static-rr ：基于权重的轮询调度 不支持运行时利用 socat 进行权重的动态调整 ( 只支持 0 和 1, 不支持其它值 ) 不支持端服务器慢启动 其后端主机数量没有限制，相当于 LVS 中的 wrr 【 慢启动是指在服务器刚刚启动上不会把他所应该承担的访问压力全部给它，而是先给一部分，当没 问题后在给一部分 】  first 根据服务器在列表中的位置，自上而下进行调度 其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务 其会忽略服务器的权重设置 不支持用 socat 进行动态修改权重 , 可以设置 0 和 1, 可以设置其它值但无效 破坏掉第一台： 动态算法 【 动态算法 基于后端服务器状态进行调度适当调整， 新请求将优先调度至当前负载较低的服务器 权重可以在haproxy运行时动态调整无需重启 】 roundrobin 1. 基于权重的轮询动态调度算法， 2. 支持权重的运行时调整，不同于 lvs 中的 rr 轮训模式， 3. HAProxy 中的 roundrobin 支持慢启动 ( 新加的服务器会逐渐增加转发数 ) ， 4. 其每个后端 backend 中最多支持 4095 个 real server ， 5. 支持对 real server 权重动态调整， 6. roundrobin 为默认调度算法 , 此算法使用广泛 动态调整权重 

echo \"set weight webserver_80/webserver1 2\" | socat stdio /var/lib/haproxy/haproxy.sock

leastconn leastconn 加权的最少连接的动态 支持权重的运行时调整和慢启动，即 : 根据当前连接最少的后端服务器而非权重进行优先调度 ( 新客户 端连接 ) 比较适合长连接的场景使用，比如： MySQL 等场景。 其他算法 【其它算法即可作为静态算法，又可以通过选项成为动态算法】 source 源地址 hash ，基于用户源地址 hash 并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一 个后端 web 服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服 务器，默认为静态方式，但是可以通过 hash-type 支持的选项更改这个算法一般是在不插入 Cookie 的 TCP 模式下使用，也可给拒绝会话 cookie 的客户提供最好的会话粘性，适用于 session 会话保持但不支持 cookie 和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法 和一致性 hash map-base 取模法 map-based ：取模法，对 source 地址进行 hash 计算，再基于服务器总权重的取模，最终结果决定将此请 求转发至对应的后端服务器。 此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度 缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果整体改变 【

 原理一句话总结

用 源地址（source IP） 做哈希，再 对总权重取模，决定转发到哪台后端服务器。

 优点

  • 实现简单，计算快。

  • 请求分布均匀，能做到较好的负载均衡。

  • 无状态，不依赖历史连接或会话。

 缺点

  • 静态调度：一旦后端服务器数量或权重变化，所有哈希结果都会重新分布。

    • 也就是说：上线/下线一台机器，所有连接都会被打乱重排。

  • 不支持：

    • 动态权重调整（不能在线改权重）

    • 慢启动（slow-start）

    • 会话保持（除非用一致性哈希）

 举个例子

假设有三台后端服务器，权重分别为：

  • A：3

  • B：2

  • C：1
    总权重 = 6

一个客户端 IP 哈希后得 17，则：

17 % 6 = 5

根据权重区间划分：

  • A：0~2

  • B：3~4

  • C：5
    → 请求会打到 C。

如果此时 C 下线，总权重变成 5，那么：

17 % 5 = 2

现在会打到 A，之前打到 C 的所有请求都变了。

 总结一句话

取模哈希法简单高效，但服务器变化会导致“全量重排”，不适合对稳定性要求高的业务。

 替代方案

  • 一致性哈希调度（consistent hashing）：服务器增减只影响局部请求，避免全量重排。

  • 加权轮询（WRR）或 最少连接数（LC）：支持动态权重和慢启动。

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

#不支持动态调整权重值[root@haproxy ~]# echo \"set weight webserver_80/webserver1 2\" | socat stdio/var/lib/haproxy/haproxy.sockBackend is using a static LB algorithm and only accepts weights \'0%\' and \'100%\'.#只能动态上线和下线[root@haproxy ~]# echo \"set weight webserver_80/webserver1 0\" | socat stdio/var/lib/haproxy/haproxy.sock[root@haproxy ~]# echo \"get weight webserver_80/webserver1\" | socat stdio/var/lib/haproxy/haproxy.sock0 (initial 1)

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

  1. 基本概念

• 传统取模：hash(o) mod n
服务器数量 n 一变，所有结果重新洗牌 → 命中率雪崩。

• 一致性哈希：把服务器和对象都映射到 0～2³² 的「Hash 环」上。
对象顺时针找最近的服务器。
服务器数量变化时，只影响环上相邻的一小段 → 局部重映射。

  1. 环偏斜（Skew）与虚拟节点

• 问题：真实节点在环上可能分布不均，导致负载不均。
• 解决：每个物理节点拆成 w × k 个「虚拟节点」
HAProxy 中叫 id，Nginx 中叫 weight × consistent 参数。
虚拟节点越多，分布越均匀，但 CPU 略增。

】 uri 基于对用户请求的 URI 的左半部分或整个 uri 做 hash ，再将 hash 结果对总权重进行取模后 根据最终结果将请求转发到后端指定服务器 适用于后端是缓存服务器场景 默认是静态算法，也可以通过 hash-type 指定 map-based 和 consistent ，来定义使用取模法还是一致性 【 注意：此算法基于应用层，所以只支持 mode http ，不支持 mode tcp】 uri 取模法配置示例 uri 一致性 hash 配置示例 访问测试： 客户端测试： url_param url_param 对用户请求的 url 中的 params 部分中的一个参数 key 对应的 value 值作 hash 计算，并由服务器 总权重相除以后派发至某挑出的服务器 , 后端搜索同一个数据会被调度到同一个服务器，多用与电商 通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个 real server 如果无没 key ，将按 roundrobin 算法 url_param 取模法配置示例 客户端访问测试： 

curl 172.25.254.100/index.html?name=aaa

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

  1. 一句话解释

HAProxy 先看你指定的 HTTP 头字段（比如 User-Agent、X-Real-IP、X-Api-Key 等），
把这个头的值做 hash → 再按 服务器总权重取模 → 决定把请求扔给哪台后端。
• 头字段存在 → 用 hash 结果挑服务器（静态映射）。
• 头字段不存在 → 退化成普通轮询（round-robin）。

  1. 为什么用它

• 同一客户端或同一类客户端 始终落到同一台机器（会话粘滞、缓存亲和）。
• 头字段变化少，hash 结果就稳定，命中率高。
• 支持在线调权重（一致性哈希版本），也支持慢启动。

】 hdr 取模法配置示例 客户端测试: 

curl -v 172.25.254.100

  一致性 hash 配置示例 客户端测试： 

curl -vA \"firefox\" 172.25.254.100

算法总结 

#静态static-rr--------->tcp/httpfirst------------->tcp/http#动态roundrobin-------->tcp/httpleastconn--------->tcp/httprandom------------>tcp/http#以下静态和动态取决于hash_type是否consistentsource------------>tcp/httpUri--------------->httpurl_param--------->httphdr--------------->http

各算法使用场景 

first #使用较少static-rr #做了session共享的web集群roundrobinrandomleastconn #数据库source#基于客户端公网IP的会话保持Uri--------------->http #缓存服务器，CDN服务商，蓝汛、百度、阿里云、腾讯url_param--------->http #可以实现session保持hdr #基于客户端请求报文头部做下一步处理

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

（在响应里给客户端 种一个特定 cookie，以后客户端每次带着这个 cookie 来，HAProxy 就根据 cookie 值把请求 精确地送回上一次那台后端，实现会话黏着（sticky session）。）

注意：不支持 tcp mode ，使用 http mode

】

配置： 验证 cookie 信息： 通过命令行验证：

curl -i 172.25.254.100

指定访问： 

curl -b WEBCOOKIE=web1 172.25.254.100

curl -vb WEBCOOKIE=web1 172.25.254.100

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

listen stats mode http bind *:1616 stats enable log global stats uri /status stats auth xyz:xyz

浏览器访问： 

http://172.25.254.100:1616/status

backend server 信息 session rate( 每秒的连接会话信息 ): Errors( 错误统计信息 ) ： cur: 每秒的当前会话数量 : Req: 错误请求量 max: 每秒新的最大会话数量 conn: 错误链接量 limit: 每秒新的会话限制量 Resp: 错误响应量 sessions( 会话信息 ): Warnings( 警告统计信息 ) ： cur: 当前会话量 Retr: 重新尝试次数 max: 最大会话量 Redis: 再次发送次数 limit: 限制会话量 Total: 总共会话量 Server(real server 信息 ) ： LBTot: 选中一台服务器所用的总时间 Status: 后端机的状态，包括 UP 和 DOWN Last ：和服务器的持续连接时间 LastChk: 持续检查后端服务器的时间 Wght: 权重 Bytes( 流量统计 ) ： Act: 活动链接数量 In: 网络的字节输入总量 Bck: 备份的服务器数量 Out: 网络的字节输出总量 Chk: 心跳检测时间 Dwn: 后端服务器连接后都是 DOWN 的数量 Denied( 拒绝统计信息 ) ： Dwntme: 总的 downtime 时间 Req: 拒绝请求量 Thrtle:server 状态 Resp: 拒绝回复量 IP 透传 web 服务器中需要记录客户端的真实 IP 地址，用于做访问统计、安全防护、行为分析、区域排行等场景。 四层 IP 透传 未开启透传的四层代理： haproxy: rs1: 正常nginx： 

vim /etc/nginx/nginx.conf

在访问 haproxy 后查看 nginx 日志： rs1： 

tail -n 3 /var/log/nginx/access.log

开启四层透传： 

\' \"$proxy_protocol_addr\"\'80 proxy_protocol; #启用此项，将无法直接访问此网站，只能通过四层代理
vim /etc/nginx/nginx.confsystemctl restart nginx

修改 haproxy： 查看日志内容： 

tail -n 3 /var/log/nginx/access.log

七层 IP 透传 当 haproxy 工作在七层的时候，也可以透传客户端真实 IP 至后端服务器 1 HAProxy 配置 在由 haproxy 发往后端主机的请求报文中添加 “X-Forwarded-For\" 首部，其值为前端客户端的地址；用于向后端主发送真实的客户端IP 修改 haproxy： 

vim /etc/haproxy/haproxy.cfg

web 服务器日志格式配置 配置 web 服务器，记录负载均衡透传的客户端 IP 地址 【修改haproxy的端口号为8080，避免占用阿帕奇的端口号，导致阿帕奇无法正常启动】 apache配置： 

LogFormat \"%{X-Forwarded-For}i %a %l %u %t \\\"%r\\\" %>s %b \\\"%{Referer}i\\\" \\\"%{User-Agent}i\\\"\" combined

ACL 访问控制列表 ACL ， Access Control Lists ） 是一种基于包过滤的访问控制技术 它可以根据设定的条件对经过服务器传输的数据包进行过滤 ( 条件匹配 ) 即对接收到的报文进行匹配和过 滤，基于请求报文头部中的源地址、源端口、目标地址、目标端口、请求方法、 URL 、文件后缀等信息内 容进行匹配并执行进一步操作，比如允许其通过或丢弃。 ACL 示例 - 域名匹配： 客户端测试： 基于源地址的访问控制： 匹配浏览器类型： （浏览器和wget都不可以访问） 基于文件后缀名实现动静分离 在rs1,rs2上制作页面，安装php：

dnf install php -y
vim /usr/share/nginx/html/index.php

创建相关文件： 

[root@rs1 ~]# mkdir /usr/share/nginx/html/static[root@rs1 ~]# echo static 192.168.0.101 > /usr/share/nginx/html/static/index.html

测试：

自定义 HAProxy 错误界面 

[root@haproxy ~]# mkdir /haproxy/errorpages/ -p[root@haproxy ~]# cp /usr/share/haproxy/503.http /haproxy/errorpages/503page.http[root@haproxy ~]# vim /haproxy/errorpages/503page.http

客户端测试： 基于 http 重定向错误页面 浏览器测试： HAProxy 四层负载 

listen mysql_portbind :3306mode tcpbalance leastconnserver mysql1 192.168.0.101:3306 checkserver mysql2 192.168.0.102:3306 check

在后端服务器rs1,rs2安装和配置 mariadb 服务： 

yum install mariadb-server -yvim /etc/my.cnf[mysqld]server-id=1 #在另一台主机为[mysqld]server-id=2 #在另一台主机为

mysql -e \"grant all on *.* to lee@\'%\' identified by \'lee\';\"

客户端测试：

mysql -ulee -plee -h 172.25.254.100 -e \"show variables like\'hostname\'\"

mysql -ulee -plee -h172.25.254.100 -e \"select @@server_id\"

HAProxy https 实现 haproxy： 制作证书： 

mkdir /etc/haproxy/certs/
openssl req -newkey rsa:2048 -nodes -sha256 -keyout /etc/haproxy/certs/timinglee.org.key -x509 -days 365 -out /etc/haproxy/certs/timinglee.org.crt

cat /etc/haproxy/certs/timinglee.org.crt \\ /etc/haproxy/certs/timinglee.org.key \\ > /etc/haproxy/timinglee.org.pem
frontend webserverbind *:80redirect scheme https if !{ ssl_fc }mode httpuse_backend webclusterfrontend webserver-httpsbind *:443 ssl crt /etc/haproxy/timinglee.org.pemmode httpuse_backend webclusterbackend webclustermode httpbalance roundrobinserver web1 172.25.254.10:80 check inter 3s fall 3 rise 5server web2 172.25.254.20:80 check inter 3s fall 3 rise 5

客户端测试： 

curl -IkL http://172.25.254.100

【 查haproxy文件问题： 

haproxy -c -f /etc/haproxy/haproxy.cfg

】
幽默笑话

网络标签：

相关问题