一、静态算法
按照事先定义好的规则轮询公平调度,不关心后端服务器的当前负载、连接数和响应速度 等,且无法实时修改权重(只能为0和1,不支持其它值),只能靠重启HAProxy生效。(不管后端死活)
1.1、static-rr:基于权重的轮询调度
不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)
不支持端服务器慢启动
其后端主机数量没有限制,相当于LVS中的 wrr
**慢启动**是指在服务器刚刚启动上不会把他所应该承担的访问压力全部给它,而是先给一部分,当没 问题后在给一部分
listen webserver
bind *:80
mode http
# balance roundrobin
balance static-rr
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1
server sorry 192.168.217.100:8080 backup
效果
1.2、first
根据服务器在列表中的位置,自上而下进行调度
其只会当第一台服务器的连接数达到上限,新请求才会分配给下一台服务
其会忽略服务器的权重设置
不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效
listen webserver
bind *:80
mode http
balance first
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1
server sorry 192.168.217.100:8080 backup
权重RS2是3一般会一点给,但first会忽略权重,让写在前面的RS1得到的请求更多,要等RS1连接上限了才会分配给其他
二、动态算法
基于后端服务器状态进行调度适当调整,
新请求将优先调度至当前负载较低的服务器
权重可以在haproxy运行时动态调整无需重启
2.1、roundrobin
listen webserver
bind *:80
mode http
balance roundrobin
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3
server sorry 192.168.217.100:8080 backup
2.2、leastconn
加权的最少连接的动态
listen webserver
bind *:80
mode http
balance leastconn
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3
server sorry 192.168.217.100:8080 backup
三、其他算法
3.1、source
listen webserver
bind *:80
mode http
balance source
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3
server sorry 192.168.217.100:8080 backup
3.2、map-basse取模法
取模就是计算两个数相除之后的余数比如当源hash值时1111,1112,1113,三台服务器a b c的权重均为1,即abc的调度标签分别会被设定为 0 1 2(1111%3=1,1112%3=2,1113%3=0)1111 ----- > nodeb1112 ------> nodec1113 ------> nodea如果a下线后,权重数量发生变化1111%2=1,1112%2=0,1113%2=11112和1113被调度到的主机都发生变化,这样会导致会话丢失
3.3、一致性hash
一致性哈希算法的核心思想是将哈希值空间组织成一个虚拟的环形空间(通常称为一致性哈希环),并按照哈希值的大小顺序将节点和数据映射到这个环上。
算法:
-
后端服务器哈希环点keyA=hash(后端服务器虚拟ip)%(2^32)
-
客户机哈希环点key1=hash(client_ip)%(2^32) 得到的值在[0---4294967295]之间
-
将keyA和key1都放在hash环上,将用户请求调度到离key1最近的keyA对应的后端服务器
节点的增加:新节点加入时,只需将其哈希值映射到环上,并将环上部分数据重新分配到新节点。
节点的减少:节点移除时,只需将该节点上的数据重新分配到其顺时针方向的下一个节点。
当某一台后端服务器下线后,就是节点移除了,就只需要将该电商的数据重新分配到其顺时针方向的下一个节点。如图中当keyB下线了,其附近的key2和key4就会按照顺时针去到keyC节点上。
一致性hash配置
listen webserver
bind *:80
mode http
balance source
hash-type consistent
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3
server sorry 192.168.217.100:8080 backup
3.4、uri算法
3.4.1、uri算法
HAProxy 对请求的 URI 进行哈希计算,生成一个哈希值。根据哈希值对后端服务器的总权重取模,将请求分配到特定的后端服务器
默认是静态算法,也可以通过hash-type指定map-based和consistent,来定义使用取模法还是一致性 hash
注意:
URI 的范围:
uri
算法可以基于 URI 的路径部分或整个 URI(包括查询字符串)进行哈希计算。-
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>左半部分:/<path>;<params>整个uri:/<path>;<params>?<query>#<frag>
仅支持 HTTP 模式:
uri
算法仅适用于 HTTP 模式(mode http
),不支持 TCP 模式。动态调整:使用一致性哈希算法时,后端服务器的增减对请求分配的影响较小
测试
3.4.2、url-param算法
#假设:url = http://www.timinglee.com/foo/bar/index.php?key=value#则:host = "www.timinglee.com"url_param = "key=value
核心原理
提取请求 URL 中指定的查询参数(如
?user=123
中的user
)。对该参数的值进行哈希计算(支持一致性哈希)。
根据哈希值与后端服务器权重取模,决定请求路由到哪台服务器。
相同参数值始终路由到同一台服务器(会话保持效果)。
url_param配置示例
listen webserver
bind *:80
mode http
balance url_param name
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3
server sorry 192.168.217.100:8080 backup
url_param一致性hash配置示例
listen webserver
bind *:80
mode http
balance url-param
hash-type consistent
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3
server sorry 192.168.217.100:8080 backup
[root@clietn ~]# curl 192.168.217.100/index.html?name=timinglee
RS1 192.168.217.10 index3
[root@clietn ~]# curl 192.168.217.100/index.html?name=timinglee
RS1 192.168.217.10 index3
[root@clietn ~]# curl 192.168.217.100/index.html?name=lee
RS1 192.168.217.20 index3
[root@clietn ~]# curl 192.168.217.100/index.html?name=lee
RS1 192.168.217.20 index3
3.5 hdr
HAProxy 中的 hdr 算法 是一种基于 HTTP 请求头部字段值 进行哈希计算的负载均衡算法,适用于 HTTP 模式(mode http),常用于实现基于特定头部(如 User-Agent
、Authorization
、X-Forwarded-For
等)的会话保持或流量分发。
配置
hdr取模算法
listen webserver
bind *:80
mode http
balance hdr(User-Agent)
hash-type consistent
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1
server sorry 192.168.217.100:8080 backup
hdr一致性hash算法
listen webserver
bind *:80
mode http
balance hdr(User-Agent)
hash-type consistent
server web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1
server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1
server sorry 192.168.217.100:8080 backup
测试
[root@client ~]# curl -vA "firefox" 172.25.254.100
[root@client ~]# curl -vA "sougou" 172.25.254.100
-v:启用详细模式(verbose),会显示请求头、响应头、连接过程等调试信息。
-A "firefox":设置 User-Agent 为 "firefox"
172.25.254.100:请求的目标地址(默认使用 http:// 协议,端口 80)。
算法总结
算法关键字 | 适用模式 | 调度依据 | 会话保持 | 一致性哈希 | 典型使用场景 | 备注说明 |
---|---|---|---|---|---|---|
roundrobin | http/tcp | 轮询 + 权重 | 否 | 否 | 通用无状态服务 | 默认算法 |
static-rr | http/tcp | 静态权重轮询 | 否 | 否 | 后端节点固定、无故障摘除 | 不重新分发 |
leastconn | http/tcp | 当前连接数最少 | 否 | 否 | 长连接/数据库/SSH | 动态权重 |
first | http/tcp | 按服务器顺序填满 | 否 | 否 | 短连接批处理任务 | 先满后用 |
source | http/tcp | 客户端源 IP 哈希 | 是 | 是 | 会话保持、内网 NAT 出口 | 需 hash-type consistent |
uri | http | 完整 URI 哈希(路径+参数) | 是 | 是 | CDN、缓存、静态资源 | 需 hash-type consistent |
url_param <name> | http | 指定查询参数值哈希 | 是 | 是 | API 分流、AB 测试 | 需 hash-type consistent |
hdr(<name>) | http | 指定请求头值哈希 | 是 | 是 | 按 User-Agent、Token、Region 分流 | 需 hash-type consistent |