欢迎光临
我们一直在努力
        找回密码
当前位置：171主机测评 > 服务器技术 > 正文

haproxy的调度算法

2026-01-29 分类：服务器技术 阅读(53) 评论(0)

haproxy的调度算法

**什么是算法？**算法就是决定了haproxy服务器收到的客户请求“分配给谁”，算法的核心目标包括：

  • 均衡后端服务器负载（避免某台服务器过载）；
  • 优先选择性能更好的服务器；
  • 支持会话保持（如用户登录状态绑定到特定服务器）；
  • 适配后端服务器的特性（如静态资源服务器、动态应用服务器）。

haproxy的算法分为三种，静态算法，动态算法，混合算法。

  • HAProxy通过固定参数 balance 指明对后端服务器的调度算法
  • balance参数可以配置在listen或backend选项中。
  • 混合算法可以根据参数在静态和动态算法中相互转换。

静态算法

静态算法有着一下共同的特点：

  • 不支持运行时利用socat进行权重的动态调整（只能为0和1，不支持其他值），只能靠重启haproxy生效。
  • 不支持慢启动

    • [!NOTE]

    慢启动是指在服务器刚刚启动上不会把他所应该承担的访问压力全部给它，而是先给一部分，当没问题后在给一部分。

    1.static-rr

    • 基于权重的轮询调度
    • 不支持运行时利用socat进行权重的动态调整(只支持0和1,不支持其它值)
    • 不支持端服务器慢启动
    • 其后端主机数量没有限制，相当于LVS中的 wrr

    算法表现示例：

    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance static-rr
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试
    [Administrator.DESKTOP-VJ307M3] ➤ for i in {1..10}; do curl 172.25.254.100; done
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10

    #检测是否支持热更新
    [root@haproxy ~]# echo "get weight webcluster/haha" | socat stdio /var/lib/haproxy/stats
    2 (initial 2)

    [root@haproxy ~]# echo "set weight webcluster/haha 1 " | socat stdio /var/lib/haproxy/stats Backend is using a static LB algorithm and only accepts weights '0%' and '100%'

    2.first

    • 根据服务器在列表中的位置，自上而下进行调度
    • 其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务
    • 其会忽略服务器的权重设置
    • 不支持用socat进行动态修改权重,可以设置0和1,可以设置其它值但无效
    • 特点鲜明，只有当第一台服务器满载“累死”才到下一台服务器。

    算法表现示例：

    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance first
    server hehe 192.168.0.10:80 maxconn 1 check inter 3s fall 3 rise 5 weight 1#设置最大连接数为1来观察实验
    server haha 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 2

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试：在一个shell中执行持续访问
    [Administrator.DESKTOP-VJ307M3] ➤ while true; do curl
    172.25.254.100; done
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    ......
    #在其他shell中建立持续访问并观察
    Administrator.DESKTOP-VJ307M3] ➤ while true; do curl 172.25.254.100; done
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    ......

    image-20260125121238280

    动态算法

    共同特点：

  • 可以利用socat工具在运行时进行权重与上下线的动态调整无需重启服务
  • 基于后端服务器的负载情况结合算法来调整调度情况
  • 支持慢启动

    • 1.roundrobin

    • 与static-rr基本一致

    • 持运行时利用socat进行权重的动态调整

    • 支持慢启动

    • 其每个后端backend中最多支持4095个real server

    • roundrobin为默认调度算法,此算法使用广泛

    算法表现示例：

    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance roundrobin
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试
    [Administrator.DESKTOP-VJ307M3] ➤ for i in {1..10}; do curl 172.25.254.100; done
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10

    #支持动态权重更新
    [root@haproxy ~]# echo "get weight webcluster/haha" | socat stdio /var/lib/haproxy/stats
    2 (initial 2)

    [root@haproxy ~]# echo "set weight webcluster/haha 1 " | socat stdio /var/lib/haproxy/stats
    [root@haproxy ~]# echo "get weight webcluster/haha" | socat stdio /var/lib/haproxy/stats
    1 (initial 2)

    #效果
    [Administrator.DESKTOP-VJ307M3] ➤ for i in {1..10}; do curl 172.25.254.100; done
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10

    2.leastconn

    • leastconn加权的最少连接的动态，相当于lvs的wlc
    • 支持权重的运行时调整和慢启动，即:根据当前连接最少的后端服务器而非权重进行优先调度(新客户 端连接)
    • 比较适合长连接的场景使用，比如：MySQL等场景。
    • 计算Overhead=(activeconns x 256+inactiveconns)/weigh

    算法表现示例：

    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance leastconn
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    [Administrator.DESKTOP-VJ307M3] ➤ for i in {1..10}; do curl 172.25.254.100; done
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20
    webserver1 – 192.168.0.10
    webserver2 – 192.168.0.20

    混合算法

    混合算法即可作为静态算法，又可以通过选项成为动态算法

    在了解混合算法之前先了解map-based 取模法与一致性hash

    map-based取模法

    • map-based：取模法，对source地址进行hash计算，再基于服务器总权重的取模，最终结果决定将此请 求转发至对应的后端服务器。
    • 此方法是静态的，即不支持在线调整权重，不支持慢启动，可实现对后端服务器均衡调度
    • 缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因总权重发生变化而导致调度结果 整体改变
    • hash-type 指定的默值为此算法

    理解例子：

    [!NOTE]

    所谓取模运算，就是计算两个数相除之后的余数，10%7=3, 7%4=3

    map-based算法：基于权重取模，hash(source_ip)%所有后端服务器相加的总权重

    比如当源hash值时1111，1112，1113，三台服务器a b c的权重均为1
    即abc的调度标签分别会被设定为 0 1 2（1111%3=1，1112%3=2，1113%3=0）
    1111 —– > nodea
    1112 ——> nodeb
    1113 ——> nodec
    如果a下线后，权重数量发生变化
    1111%2=1，1112%2=0，1113%2=1
    1112和1113被调度到的主机都发生变化，这样会导致会话丢失

    对此一致性哈希，可以减小扩容缩容的影响

    一致性hash

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

    计算算法与原理：

    1、后端服务器哈希环点keyA=hash(后端服务器虚拟ip)%(2^32)
    2、客户机哈希环点key1=hash(client_ip)%(2^32） 得到的值在[0—4294967295]之间
    3、将keyA和key1都放在hash环上，将用户请求调度到离key1最近的keyA对应的后端服务器

    image-20260128084510828

    hash对象到后端服务器的映射关系：

    image-20260128084700057

    后端服务器在线与离线的调度方式：

    image-20260128084754928

    理解例子：

    步骤 1：构建哈希环
    哈希环范围：0 ~ 2^32 – 1（简化为 0 ~ 100 便于理解）。
    步骤 2：服务器映射（虚拟节点）
    s1 权重 2 → 生成 2 个虚拟节点：
    192.168.1.10:80#1 → 哈希值 = 20
    192.168.1.10:80#2 → 哈希值 = 60
    s2 权重 1 → 生成 1 个虚拟节点：
    192.168.1.11:80#1 → 哈希值 = 80
    虚拟节点在环上的位置：20 (s1) → 60 (s1) → 80 (s2) → 100/0（环闭合）。
    步骤 3：请求映射
    URI /static/img/logo.png → 哈希值 = 70；
    从 70 的位置顺时针找，第一个虚拟节点是 80 (s2) → 请求分发到 s2。
    步骤 4：服务器下线的影响（核心优势）
    如果 s2 下线：
    哈希环上的 80 (s2) 节点被移除；
    原哈希值 70 的请求，顺时针找到的下一个节点是 20 (s1) → 仅该请求的映射关系改变；
    其他请求（如哈希值 = 50 → 60 (s1)、哈希值 = 90 → 20 (s1)）的映射关系完全不变；
    对比普通哈希：若 s2 下线，总权重从 3 变 2，所有请求的取模结果都变，映射关系 100% 改变。

    1.source

    源地址hash，基于用户源地址hash并将请求转发到后端服务器，后续同一个源地址请求将被转发至同一 个后端web服务器。此方式当后端服务器数据量发生变化时，会导致很多用户的请求转发至新的后端服务器。

    默认为静态方式，但是可以通过hash-type支持的选项更改这个算法一般是在不插入Cookie的TCP 模式下使用，也可给拒绝会话cookie的客户提供最好的会话粘性，适用于session会话保持但不支持 cookie和缓存的场景源地址有两种转发客户端请求到后端服务器的服务器选取计算方式，分别是取模法和一致性hash

    取模法实验示例：

    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance source
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试：

    image-20260128090516799

    一致性hash示例：

    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance source
    hash-type consistent#类型为一致性hash
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试：实验效果与取模法没什么区别，要有多个客户端实验才明显

    image-20260128090559448

    2.uri

    • 基于对用户请求的URI的左半部分或整个uri做hash，再将hash结果对总权重进行取模后
    • 根据最终结果将请求转发到后端指定服务器
    • 适用于后端是缓存服务器场景
    • 默认也是静态算法，也可以通过hash-type指定map-based和consistent，来定义使用取模法还是一致性 hash
    • 此算法只基于应用层，只支持mode http

    <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
    左半部分：/<path>;<params>
    整个uri：/<path>;<params>?<query>#<frag>

    由于使用取模法与一致性哈希的区别不明显因此直接使用一致性哈希来实验

    #主备实验环境
    [root@webserver1 ~]# echo RS1 – 192.168.0.10 > /var/www/html/index1.html
    [root@webserver1 ~]# echo RS1 – 192.168.0.10 > /var/www/html/index2.html
    [root@webserver2 ~]# echo RS2 – 192.168.0.20 > /var/www/html/index1.html
    [root@webserver2 ~]# echo RS2 – 192.168.0.20 > /var/www/html/index2.html

    #设定uri算法
    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance uri
    hash-type consistent
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试
    #不同的uri哈希出来的结果不一样调度到不一样的服务端上

    image-20260128091202270

    3.url_param

    url_param对用户请求的url中的 params 部分中的一个参数key对应的value值作hash计算，并由服务器总权重相除以后派发至某挑出的服务器,后端搜索同一个数据会被调度到同一个服务器，多用与电商

    通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个real server 如果无没key，将按roundrobin算法

    #假设：
    url = http://www.fjw.com/foo/bar/index.php?key=value
    host = "www.fjw.com"
    url_param = "key=value"

    由于使用取模法与一致性哈希的区别不明显因此直接使用一致性哈希来配置实验

    #设定url_param算法
    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance url_param name#key为name
    hash-type consistent
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试
    #更改name值就能实现不同的hash

    image-20260128092046153

    4.hdr

    针对用户每个http请求头部(header)请求中的指定信息做hash，

    此处被指定的http首部参数将会被取出并做hash计算，

    然后由服务器总权重取模以后派发至某挑出的服务器，如果无有效值，则会使用默认的轮询调度。

    image-20260128092533004

    可以对请求头部的参数进行指定hash

    由于使用取模法与一致性哈希的区别不明显因此直接使用一致性哈希来配置实验

    [root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
    listen webcluster
    bind *:80
    balance hdr（User-Agent）#对User-Agent进行哈希
    hash-type consistent
    server haha 192.168.0.10:80 check inter 3s fall 3 rise 5 weight 2
    server hehe 192.168.0.20:80 check inter 3s fall 3 rise 5 weight 1

    [root@haproxy ~]# systemctl restart haproxy.service

    #测试
    #curl -A 用于自定义请求的 User-Agent 字段
    #curl -H用于自定义指定请求curl -H "头部字段名: 字段值" 目标URL

    image-20260128092756526

    算法总结

    各种算法适配的模式

    #静态
    static-rr———>tcp/http
    first————->tcp/http
    #动态
    roundrobin——–>tcp/http
    leastconn———>tcp/http
    random————>tcp/http

    #以下静态和动态取决于hash_type是否consistent
    source————>tcp/http
    uri—————>http
    url_param———>http
    hdr—————>http

    各种算法使用场景

    first #使用较少
    static-rr #做了session共享的web集群
    roundrobin
    leastconn#数据库
    source

    #基于客户端公网IP的会话保持
    uri—————>http #缓存服务器，CDN服务商
    url_param———>http#可以实现session保持
    hdr #基于客户端请求报文头部做下一步处理

    在这里插入图片描述

    赞(0)
    未经允许不得转载：171主机测评 » haproxy的调度算法
    分享到： 更多 (0)
    标签：

    相关推荐

    评论 抢沙发

    取消

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址

    热门标签

    #人工智能(59590)#python(20193)#开发语言(16921)#java(15523)#运维(15401)#linux(14982)#大数据(14616)#服务器(13094)#算法(11811)#前端(10942)#网络(9401)#ai(8963)#数据库(8928)#c++(8192)#课程设计(6817)#学习(6800)#机器学习(6728)#区块链(5929)#OpenClaw(5394)#后端(5174)#spring boot(5019)#深度学习(4971)#c语言(4385)#毕业设计(4301)#数据结构(4207)#安全(4090)#docker(3942)#架构(3882)#javascript(3814)#大模型(3664)

    热门文章

    最新文章

    归档

    分类