HAProxy（一）

四层负载均衡与七层负载均衡区别

四层负载均衡和七层负载均衡是两种不同的负载均衡方式，主要区别在于负载均衡的层级及其所支持的协议不同。

四层负载均衡，也称为传输层负载均衡，工作在 OSI 模型的传输层（第四层），主要是基于 IP 地址和端口号来进行负载均衡，常用的四层负载均衡器有 LVS、HAProxy、Nginx（1.9以后） 等。四层负载均衡可以处理 TCP 和 UDP 协议，可以实现基于轮询、最小连接数、哈希等算法的负载均衡策略，可以实现网络流量的分发和负载均衡，但不能实现应用层的协议解析。

七层负载均衡，也称为应用层负载均衡，工作在 OSI 模型的应用层（第七层），主要是基于应用层协议（如 HTTP、SMTP、FTP 等）进行负载均衡，常用的七层负载均衡器有 HAProxy、Nginx、F5 等。七层负载均衡可以实现基于 URL、域名、Cookie 等信息的负载均衡策略，可以实现更精细的流量控制和负载均衡，同时也可以进行应用层协议解析、缓存、SSL 加速等操作。

因此，四层负载均衡和七层负载均衡各有优缺点，选用哪种方式取决于具体的场景和需求。

简介

HAProxy是法国开发者威利塔罗(Wily Tarreau)在2000年使用C语言开发的一个开源软件，是一款具备高并发(一万以上)、高性能的TCP和HTTP负载均衡器，支持基于cookie的持久性，自动故障切换，支持正则表达式及web状态统计。

核心功能

• 负载均衡：L4和L7两种模式，支持RR/静态RR/LC/IP Hash/URI Hash/URL_PARAM Hash/HTTP_HEADER Hash 等丰富的负载均衡算法

• 健康检查：支持TCP和HTTP两种健康检查模式

• 会话保持：对于未实现会话共享的应用集群，可通过 Insert Cookie/Rewrite Cookie/Prefix Cookie，以及上述的多种 Hash 方式实现会话保持

• SSL：HAProxy 可以解析 HTTPS 协议，并能够将请求解密为 HTTP 后向后端传输

• HTTP 请求重写与重定向

• 监控与统计：HAProxy 提供了基于 Web 的统计信息页面，展现健康状态和流量数据。基于此功能，使用者可以开发监控程序来监控 HAProxy 的状态

下载

源码包下载地址 Index of /repo/pkgs/haproxy

产品文档 HAProxy Documentation Converter

配置

/etc/haproxy/haproxy.cfg 配置文件由两大部分组成 Global 和 Proxies

Global：全局配置段

进程及安全配置相关参数

性能调整相关参数

Debug相关参数

chroot /usr/local/haproxy    #锁定运行目录
deamon    #以守护进程运行
#stats socket /var/lib/haproxy/haproxy. sock mode 600 level admin    #socket文件
user，group，uid，gid    #运行haproxy的用户身份，如 user wenzi或uid 666
nbproc    #开启的haproxy进程数，与CPu保持一致
nbthread    #指定每个haproxy进程开启的线程数，默认为每个进程一个线程
cpu-map 1 0    #绑定haproxy进程至指定CPU
maxconn    #每个haproxy进程的最大并发连接数
maxss1conn    #每个haproxy进程ss1最大连接数,用于haproxy配置了证书的场景下
maxconnrate    #每个进程每秒创建的最大连接数量
spread-checks    #后端server状态check随机提前或延迟百分比时间，建议2-5(20%-50%)之间
pidfile    #指定pid文件路径
log 127.0.0.1 local3 info    #定义全局的sys1og服务器;最多可以定义两个

Proxies：代理配置段

defaults

为frontend，backend，listen提供默认配置

option redi spatch    #当server Id对应的服务器挂掉后，强制定向到其他健康的服务器，重新派发
option abortonclose    #当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接，关闭
option http-keep-alive    #开启与客户端的会话保持
option forwardfor    #透传客户端真实IP至后端web服务器
mode http    #设置默认工作类型，7层是http，四层是tcp
timeout http-keep-alive 120s    #session会话保持超时时间，范围内会转发到相同的后端服务器
timeout connect 120s    #客户端请求从haproxy到后端server的最长连接等待时间(TCP之前)
timeout server 600s    #客户端请求从haproxy到后端服务端的请求处理超时时长（TCP之后) 
timeout client 600s    #设置haproxy与客户端的最长非活动时间
timeout check 5s    #对后端服务器的默认检测超时时间

frontend

接收请求的前端虚拟节点，可指定具体使用的后端backend，相当于Nginx中的Server {}

bind [<address>]:<port_range> [，...] [param*]listen http_proxy    #监听http的多个IP的多个端口和sock文件
bind :80,:443,:8801-8810
bind 10.0.0.1:10080,10.0.0.1:10443
bind /var/run/ss1-frontend.sock user root mode 600 accept-proxylisten http_https_proxy    #https监听
bind :80
bind :443 ss7 crt /etc/haproxy/site.pemlisten http_https_proxy_explicit    #监听ipv6、ipv4和unix sock文件
bind ipv6@ :80
bind ipv4@public_ssl:443 ssl crt /etc/haproxy/site.pem
bind [e-mail] user root mode 600 accept-proxylisten externa7_bind_app1    #监听file descriptor
bind "fd@${FD_APP1]"

backend

后端服务集群的配置，相当于Nginx中的upstream {}

mode http/tcp    #指定负载协议类型
option    #配置选项
server    #定义后端real server

注意：option后面加httpchk,smtpchk,mysql-check,pgsql-check，ss-hello-chk方法，可用于实现更多应用层检测功能。

check    #对指定rea7进行健康状态检查，默认不开启
addr IP    #可指定的健康状态监测IP
port num    #指定的健康状态监测端口
inter num    #健康状态检查间隔时间，默认2000ms
fall num    #后端服务器失效检查次数，默认为3
rise num    #后端服务器从下线恢复检查次数，默认为2
weight    #默认为1，最大值为256，0表示不参与负载均衡backup #将后端服务器标记为备份状态
disab1ed    #将后端服务器标记为不可用状态
redirect prefix http: //www.magedu.net/    #将请求临时重定向至其它URL，只适用于http模式
maxconn <maxconn>:当前后端server的最大并发连接数
backlog <backlog>:当server的连接数达到上限后的后援队列长度

示例

frontend+backend结合配置

#官网业务访问入口
frontend WEB_PORT_80
bind 192.168.7.248:80
mode http
use_backend web_prot_http_nodesbackend web_prot_http_nodes
mode http
option forwardfor
server 192.168.7.101 192.168.7.101:8080  check inter 3000 fall 3 rise 5
server 192.168.7.102 192.168.7.102:8080  check inter 3000 fall 3 rise 5

listen：

同时拥有前端和后端配置

使用listen替代 frontend+backend结合配置的 上述配置

#官网业务访问入口
listen    WEB_PORT_80bind 192.168.7.248:80mode httpoption forwardforserver 192.168.7.101 192.168.7.101:8080  check inter 3000 fall 3 rise 5server 192.168.7.102 192.168.7.102:8080  check inter 3000 fall 3 rise 5

调度算法

静态算法

按照事先定义好的规则轮询公平调度，不关心后端服务器的当前负载、链接数和相应速度等，且无法实时修改权重，只能靠重启HAProxy生效。

static-rr

基于权重的轮询调度，不支持权重的运行时调整及后端服务器慢启动，其后端主机数量没有限制

first

根据服务器在列表中的位置，自上而下进行调度，但是其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务，因此会忽略服务器的权重设置。

动态算法

基于后端服务器状态进行调度适当调整，比如优先调度至当前负载较低的服务器，且权重可以在haproxy运行时动态调整无需重启。

roundrobin

基于权重的轮询动态调度算法，支持权重的运行时调整，不完全等于lvs中的rr轮训模式，HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)，其每个后端backend中最多支持4095个realserver，roundrobin为默认调度算法，且支持对real server权重动态调整。

leastconn

leastconn加权的最少连接的动态，支持权重的运行时调整和慢启动，即当前后端服务器连接最少的优先调度(新客户端连接)，比较话合长连接的场景使用，比比如MySOL等场景

其它算法

source：根据请求源ip地址

url：根据请求的URL

url_param：根据请求的url参数进行调度

hdr(name)：根据HTTP请求头来锁定每一次HTTP请求

rdp-cookie：根据cookie名来锁定并hash每一次TCP请求。

使用场景

first：使用较少

static-rr：session共享的web集群

leastconn：数据库

source：基于客户端公网IP的会话保持

uri：缓存服务器，CDN服务商

hdr：基于客户端请求报文头做下一步处理

rdp-cookie：很少使用