1. Toy模板网首页
  2. > Toy博客

HAProxy 调度算法介绍

9月前 作者：墨烦信息 分类：Toy博客 阅读(23) 违法举报

这篇具有很好参考价值的文章主要介绍了HAProxy 调度算法介绍。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

HAProxy 调度算法介绍

HAProxy 的调度算法比较多，在没有设置 mode 或者其它选项时，HAProxy 默认对
后端服务器使用 roundrobin 算法来分配请求处理。对后端服务器指明使用的算法
时使用balance关键字，该关键字可在listen和backend中出现。在 HAProxy
运行时支持动态调整后端服务器权重、并且考虑后端服务器负载等情况的算法，我们
称之为动态算法；相反，不能动态调整后端服务器权重也不考虑服务器负载的
算法叫静态算法。指定调度策略的典型配置如下：

backend srv_group1
    mode http
    log global
    # balance <algorithm> [<arguments>]
    balance static-rr
    server web1 ip:port weight 2 check inter 300000ms fall 2 rise 5

调度算法官方文档说明

本文介绍 HAProxy 算法的同时，使用一台 HAProxy 服务器和四台后端服务器来验证各
调度算法的效果。另外，客户端使用172.20.2.195 client-node1，使用该客户端访
问 HAProxy 服务器(http://172.20.2.189:8080)来验证。

HAProxy 服务器
172.20.2.189 ubuntu-suosuoli-node1
系统:Ubuntu1804
四台后端服务器
172.20.2.37 node1
172.20.2.43 node2
172.20.2.44 node3
172.20.2.45 node4
系统都为 CentOS7.7
客户端
172.20.2.195 client-node1
系统为 CentOS7.7

准备环境

root@ubuntu-suosuoli-node1:~# vim /etc/ansible/ansible.cfg
......
[backend]
172.20.2.37
172.20.2.43
172.20.2.44
172.20.2.45
......
root@ubuntu-suosuoli-node1:~# ansible backend -m shell -a "nginx -t"
172.20.2.43 | SUCCESS | rc=0 >>
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

172.20.2.45 | SUCCESS | rc=0 >>
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

172.20.2.37 | SUCCESS | rc=0 >>
nginx: the configuration file /apps/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /apps/nginx/conf/nginx.conf test is successful

172.20.2.44 | SUCCESS | rc=0 >>
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

root@ubuntu-suosuoli-node1:~# ansible backend -m shell -a "nginx -s reload"
172.20.2.37 | SUCCESS | rc=0 >>


172.20.2.45 | SUCCESS | rc=0 >>


172.20.2.43 | SUCCESS | rc=0 >>


172.20.2.44 | SUCCESS | rc=0 >>

root@ubuntu-suosuoli-node1:~# ansible backend -a "hostname"
172.20.2.43 | SUCCESS | rc=0 >>
node2

172.20.2.44 | SUCCESS | rc=0 >>
node3

172.20.2.45 | SUCCESS | rc=0 >>
node4

172.20.2.37 | SUCCESS | rc=0 >>
node1

使用的核心配置

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    nbproc 2
    cpu-map 1 0
    cpu-map 2 1
    stats socket /run/haproxy/admin.sock2 mode 660 level admin expose-fd listeners
    #stats socket /run/haproxy/admin.sock1 mode 660 level admin expose-fd listeners process 1
    #stats socket /run/haproxy/admin.sock2 mode 660 level admin expose-fd listeners process 2
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    option  http-keep-alive
    timeout connect 300000ms
    timeout client  300000ms
    timeout server  300000ms
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

listen stats
    mode http
    bind 172.20.2.189:9999
    stats enable
    log global
    stats uri    /haproxy_status
    stats auth   haadmin:stevenux

frontend  WEB_PORT_8080
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    # balance roundrobin 默认使用该调度策略
    option forwardfor
    server node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5

访问 WEB 管理界面http://172.20.2.189:9999/haproxy_status
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QFbYRf6R-1692491218897)(png/2020-01-11-19-40-48.png)]

一.静态调度算法

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

HAProxy 运行时，要动态修改服务器权重，需要安装额外的工具socat。Socat 是 Linux
下的命令行工具，全名叫 Socket CAT，Socat 的主要工作原理是建立一个双向的通道，
并在这个通道传输比特流。其支持众多协议和链接方式。如 IP、TCP、UDP、IPv6、Socket
文件等。由于其功能强大，可以有多种用途，由于其可以转发 TCP 流，甚至有人将它配置为
防火墙。

# Centos安装
yum install socat -y

# 此处使用Ubuntu1804
root@ubuntu-suosuoli-node1:~# apt-cache madison socat
     socat | 1.7.3.2-2ubuntu2 | http://mirrors.aliyun.com/ubuntu bionic/main amd64 Packages
     socat | 1.7.3.2-2ubuntu2 | https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic/main amd64 Packages
     socat | 1.7.3.2-2ubuntu2 | http://mirrors.aliyun.com/ubuntu bionic/main Sources
root@ubuntu-suosuoli-node1:~# apt install socat
root@ubuntu-suosuoli-node1:~# socat -V
socat by Gerhard Rieger and contributors - see www.dest-unreach.org  # 这是它官网，作者应该是个极简主义者
socat version 1.7.3.2 on Apr  4 2018 10:06:49
......

# 获取后端服务器node3的权重可以这样做
root@ubuntu-suosuoli-node1:~# find / -name admin.sock
/run/haproxy/admin.sock
root@ubuntu-suosuoli-node1:~# echo "get weight web_prot_http_nodes/node3" | socat stdio /run/haproxy/admin.sock
3 (initial 3)

# 设置没某个后端服务器的权重可以这样，但是我用的是static-rr算法，不可以动态调整权重。只接受0或者1
# 0就表示不参与请求处理，1表示参与
root@ubuntu-suosuoli-node1:~# echo "set weight web_prot_http_nodes/node3 6" | socat stdio /run/haproxy/admin.sock
Backend is using a static LB algorithm and only accepts weights '0%' and '100%'.

BTW:socat 官网
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yb4V8Ncy-1692491218898)(png/2020-01-12-14-35-26.png)]

1.1 static-rr

static roundrobin:静态轮询调度策略，使用基于权重的轮询调度策略。权重
在配置文件中指定后不可动态更改和后端服务器慢启动，此调度策略对后端服务
器最大数量没有限制。

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance static-rr
    option forwardfor
    server node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80 weight 2 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80 weight 2 check inter 3000 fall 3 rise 5

client-node1 上测试效果

[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 ; sleep 0.1 ; done
node1 172.20.2.37
node2 172.20.2.43
node4 172.20.2.45
node2 172.20.2.43
node3 172.20.2.44
node4 172.20.2.45
node1 172.20.2.37
node2 172.20.2.43
......

# 44此访问，被调度的比例接近1:2:1:2的权重值
[root@client-node1 ~]# cat static-rr.log | wc -l
44
[root@client-node1 ~]# cat static-rr.log | sort | uniq -c
      8 node1 172.20.2.37
     15 node2 172.20.2.43
      7 node3 172.20.2.44
     14 node4 172.20.2.45

1.2 first

first:根据服务器在列表中的位置，自上而下进行调度(不人为的设定，从上到
下各台服务器的 id 会自动增加，第一台服务器的 id 为 1)，但是其只会当第一
台服务器的连接数达到上限(maxconn 参数)，新请求才会分配给下一台服务，
因此 HAProxy 会忽略服务器的权重值，这样比较适合长会话的协议如：RDP[^1]
和 IMAP。不指定maxconn参数使用该调度策略是没有意义的(懂我意思吗?)。
实现该调度算法的实际用途是在比较空闲的时间段关闭某些服务器以使用最少的服
务器提供服务，节约成本。

如果需要人为指定 id，则可以在server server_name ip:port指令后面加上
id <idnumber>id 号必须是正整数。

RDP 协议介绍

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance first
    option forwardfor
    server node1 172.20.2.37:80 maxconn 2 weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80           weight 2 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80 maxconn 2 weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80           weight 2 check inter 3000 fall 3 rise 5

client-node1 上测试

# 在两个窗口同时访问HAProxy
[root@client-node1 ~]# tty
/dev/pts/0
[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 ; done
...
[root@client-node1 ~]# tty
/dev/pts/1
[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 ; done
node1 172.20.2.37
node1 172.20.2.37
node2 172.20.2.43
......
node1 172.20.2.37
node1 172.20.2.37
node2 172.20.2.43
......
# 可以看到，在某些时间几乎同时有两个以上的请求到达node1，这时HAProxy
# 就会调度node2处理多出的请求

二.动态调度算法

2.1 roundrobin

roundrobin该算法是默认使用的调度策略。该算法会根据每个后端服务器的
权重weight依次将请求分发到后端服务器。当后端服务器的处理性能比较均
衡的分布时，使用该算法比较好。在该算法使用时，可以动态调整后端服务器
的权重，以便调整整个服务器组的性能。由于设计的限制，每个后端服务器组
最多只能定义 4095 个活动服务器。该 roudrobin 算法支持慢启动(slow
start)，表示新加入的服务器会在一段时间内逐渐增加工作负载(转发量)。

验证 roundrobin 调度策略的配置如下

listen stats
    mode http
    bind 172.20.2.189:9999
    stats enable
    log global
    stats uri    /haproxy_status
    stats auth   haadmin:stevenux

frontend  WEB_PORT_8080
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    # balance roundrobin 默认使用该调度策略
    option forwardfor
    server node1 172.20.2.37:80 weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80 weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80 weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80 weight 1 check inter 3000 fall 3 rise 5

在client-node1多次访问http://172.20.2.189:8080验证

[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 ; sleep 3 ; done
node4 172.20.2.45
node1 172.20.2.37
node2 172.20.2.43
node3 172.20.2.44
node4 172.20.2.45
node1 172.20.2.37
node2 172.20.2.43
^C
# 配置指明后端服务器的权重weight都为1，所以后端服务器被轮流调度处理请求

更改服务器的权重

root@ubuntu-suosuoli-node1:~# echo "get weight web_prot_http_nodes/node1" | socat stdio /run/haproxy/admin.sock
1 (initial 1)

root@ubuntu-suosuoli-node1:~# echo "get weight web_prot_http_nodes/node2" | socat stdio /run/haproxy/admin.sock
1 (initial 1)

root@ubuntu-suosuoli-node1:~# echo "get weight web_prot_http_nodes/node3" | socat stdio /run/haproxy/admin.sock
1 (initial 1)

root@ubuntu-suosuoli-node1:~# echo "get weight web_prot_http_nodes/node4" | socat stdio /run/haproxy/admin.sock
1 (initial 1)

# 更改权重
root@ubuntu-suosuoli-node1:~# echo "set weight web_prot_http_nodes/node2 2" | socat stdio /run/haproxy/admin.sock

root@ubuntu-suosuoli-node1:~# echo "set weight web_prot_http_nodes/node3 3" | socat stdio /run/haproxy/admin.sock

root@ubuntu-suosuoli-node1:~# echo "set weight web_prot_http_nodes/node4 4" | socat stdio /run/haproxy/admin.sock

# 查看是否生效
root@ubuntu-suosuoli-node1:~# echo "get weight web_prot_http_nodes/node3" | socat stdio /run/haproxy/admin.sock
3 (initial 1)

再次测试

[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 ;sleep 0.01; done
node4 172.20.2.45
node3 172.20.2.44
node4 172.20.2.45
node2 172.20.2.43
node3 172.20.2.44
node4 172.20.2.45
node1 172.20.2.37
node4 172.20.2.45
node3 172.20.2.44
......

# 统计81次访问
[root@client-node1 ~]# cat statis.log | wc -l
81
[root@client-node1 ~]# cat statis.log | sort | uniq -c
      8 node1 172.20.2.37
     16 node2 172.20.2.43
     24 node3 172.20.2.44
     33 node4 172.20.2.45

# 可以看到各个服务器被调度的比例接近权重node1:node2:node3:node4=1:2:3:4
# 实际为node1:node2:node3:node4=8:16:24:33

2.2 leastconn

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

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance leastconn
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5

三.其它算法

这些算法无法严格的分为动态或者静态算法，可以作为静态算法也可可以通过选项调整
为动态算法。

3.1 source

source调度策略为source IP hash(源地址哈希)，基于客户端源地址 hash
并将请求转发到后端服务器，默认为静态方式即取模方式，但是可以通过 hash-type
支持的选项更改，后续同一个源地址请求将被转发至同一个后端 web 服务器，比较
适用于 session 保持/缓存业务等场景。

源 IP 地址被 HASH 并除以正在运行的服务器的总权重值，取其结果的摸，得到一
个索引，以指定哪个服务器将接收请求。这确保了只要没有服务器宕机或恢复，相
同的客户端 IP 地址将始终到达相同的服务器。如果运算结果由于运行的服务器数量
的变化而发生变化，许多客户端请求将被定向到其它台服务器。该算法通常用于 TCP
模式，其中不可以插入 cookie 信息。它也可以在 Internet 上使用，为拒绝会话
cookie 的客户端提供最佳的粘性。默认情况下，这个算法是静态的，这意味着动态
地更改服务器的权重不会有任何影响，但是可以使用"hashtype"关键字来更改。

hash-type <method>用来指定 hash 类型，类型可以是map-based或者consistent

hash-type map-based # 不指定时，默认使用该哈希方法
hash-type consistent
map-based哈希方法
使用 map-based 哈希方法时，哈希表(哈希的结果)是包含所有活动服务器的静态
数组。该哈希方法会考虑服务器权重。但是在服务器运行时权重发生变化会被忽略。
核心是按照服务器在数组中的位置来选择调度的服务器，所以当服务器有上线或者下
线时，总权重会发生变化，哈希也就变化了，这会导致大部分的连接将会重新被调度
到不同的服务器。这种调度算法不支持慢启动也不适合在使用缓存的场景使用。
consistent一致性哈希方法
使用 consistent 一致性哈希方法时，哈希表中每个服务器对应多个哈希值(这些
对应于同一个服务器的哈希值和该服务器的名称或者 ID 有关联)，这个哈希表使用
树结构(某种数据结构)来组织。HAProxy 会在该树结构上查找哈希键，并选中最合适
的值。该哈希方法支持动态修改服务器权重，所以其支持慢启动。使用该调度策略的
优势是，当某个服务器停用或者再次启用时，只有和该服务器相关的哈希信息会被移
除。当某个服务器加入服务器组时，只有一部分连接会被重新分配，这使得一致性哈
希方法是使用缓存时的理想调度策略。

map-based哈希方法配置

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance source
    # hash-type map-based  # 可写可不写
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5

在 client-node1 访问验证

[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 ;sleep 1; done
node4 172.20.2.45
node4 172.20.2.45
node4 172.20.2.45
......

在 172.20.1.1 访问验证
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SlWTvcYj-1692491218898)(png/2020-01-12-18-00-29.png)]

consistent一致性哈希方法配置

listen stats
        mode tcp
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode tcp
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance source
    hash-type consistence # 使用一致性哈希方法
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5`

3.2 uri

uri调度算法会对 URI 的左侧部分(问号前面的部分)或者对整个 URI 进行哈希，
并使用活动服务器的总权重值除以该哈希值。计算结果决定了将请求调度到哪台服
务器。该调度算法常常在使用代理缓存时使用。也可以通过 map-based 和
consistent 定义使用取模法还是一致性 hash。

http://example.org/absolute/URI/with/absolute/path/to/resource.txt  #URI/URL
ftp://example.org/resource.txt   #URI/URL
/relative/URI/with/absolute/path/to/resource.txt   #URI
# 注意：URL是URI的子集

配置示例

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance uri
    #hash-type map-based
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5

访问测试

[root@client-node1 ~]# curl http://172.20.2.189:8080/index.html
node3 172.20.2.44
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html
index1-node4-172.20.2.45

3.3 url_param

url_param 对用户请求的 url 中的 params 部分中的参数 name 作 hash
计算，并除以服务器总权重，根据计算结果派发至某挑出的服务器；通常用
于追踪用户，以确保来自同一个用户的请求始终发往同一个 real server。
其亦可以使用hash-type指定一致性哈希方法。另外，如果找不到 URL 中
问号选项后的参数，则使用 roundrobin 算法。

对于 url_param 中的哈希对象(参数)，可以用一个 URL 来说明：

假设
URL = http://www.suosuoli.cn/foo/bar/index.php?key1=value1&key2=value2
那么
host = "www.suosuoli.cn"
url_param = "key1=value1&key2=value2" # 该字符串就是要进行哈希运算的对象

url_param调度策略配置示例

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance url_param name,gender     # 支持对单个或多个url_param进行hash
    # hash-type consistent  # 使用一致性hash方法
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5

访问测试

# 未带参数，都被调度到node1
[root@client-node1 ~]# curl http://172.20.2.189:8080/index.html
node1 172.20.2.37
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html
index1-node2-172.20.2.43

# 找不到参数则使用roudrobin轮询策略
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html?name=jack
index1-node3-172.20.2.44
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html?name=jack
index1-node4-172.20.2.45
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html?name=jack
index1-node1--172.20.2.37
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html?name=jack
index1-node2-172.20.2.43
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html?name=jack
index1-node3-172.20.2.44
[root@client-node1 ~]# curl http://172.20.2.189:8080/index1.html?name=jack
index1-node4-172.20.2.45

3.4 hdr

针对用户每个 http 头部(header)请求中的指定信息做 hash，此处由 name 指定
的 http 首部将会被取出并做 hash 计算，然后由服务器总权重相除以后派发至某
挑出的服务器，假如无有效的值，则会使用默认的轮询调度。

hdr调度策略配置

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance hdr(User-Agent)  # 使用客服端版本等信息进行哈希运算
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5

访问测试

[root@client-node1 ~]# curl -V
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.36 zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets
[root@client-node1 ~]# curl http://172.20.2.189:8080
node4 172.20.2.45
[root@client-node1 ~]# curl http://172.20.2.189:8080
node4 172.20.2.45
[root@client-node1 ~]# curl http://172.20.2.189:8080
node4 172.20.2.45
[root@client-node1 ~]# curl http://172.20.2.189:8080

Chrome 浏览器测试
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VllpvcMV-1692491218899)(png/2020-01-12-21-05-14.png)]
FireFox 浏览器测试
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-919Z4GWd-1692491218899)(png/2020-01-12-21-06-52.png)]

可以看到不同的客户端的请求被调度到不同的后端服务器。

3.5 rdp-cookie

rdp(windows 远程桌面协议)-cookie 用于对 windows 远程桌面的反向代理，
主要是使用 cookie 保持来会话；此调度算法专门适用于 windows 远程桌面
连接场景。当连接到后端服务器后，会生成一个 cookie，下次相同的 cookie
连接时，还会被调度到同一台后端服务器，适用于后端多服务器场景。

rdp-cookie配置示例

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode tcp
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   tcp
    balance rdp-cookie
    hash-type consistence
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5

注：如果跨网段，HAProxy 主机需要开启路由器转发功能/etc/sysctl.conf；

net.ipv4.ip_forward = 1 #必须开启ip转发功能

该算法只在四层，是不分析到用户请求的应用层信息的，只分析到传输层，所以
HAProxy 会基于端口号做转发，所以需要开启路由器转发功能。

3.6 random

该算法在 1.9 版本增加，其基于一个随机数作为一致性 hash 的 key，随机负载
平衡对于大型服务器场或经常添加和删除服务器的场景非常有用，因为它可以避免
在这种情况下由 roundrobin 或 leastconn 导致的锤击效应。

random调度策略配置

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   http
    balance random
    option forwardfor
    server node1 172.20.2.37:80  weight 1 check inter 3000 fall 3 rise 5
    server node2 172.20.2.43:80  weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80  weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80  weight 1 check inter 3000 fall 3 rise 5

访问测试

[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 ;sleep 1; done
node2 172.20.2.43
node1 172.20.2.37
node4 172.20.2.45
node1 172.20.2.37
node1 172.20.2.37
node4 172.20.2.45
node2 172.20.2.43
node4 172.20.2.45
^C

[root@client-node1 ~]# while : ; do curl 172.20.2.189:8080 >> random.log ; done
.....
[root@client-node1 ~]# cat random.log | wc -l
1147
[root@client-node1 ~]# cat random.log | sort | uniq -c
    346 node1 172.20.2.37
    201 node2 172.20.2.43
    266 node3 172.20.2.44
    333 node4 172.20.2.45
# 可以看到各个服务器处理的请求数量没有规律，随机的(懂我意思吗？)

四.各算法使用场景

4.1 总结

算法 支持的协议 静态/动态
static-rr tcp/http 静态
first tcp/http 静态
roundrobin tcp/http 动态
leastconn tcp/http 动态
random tcp/http 动态
source tcp/http 取决于 hash_type 是否 consistent
uri ttp 取决于 hash_type 是否 consistent
url_param ttp 取决于 hash_type 是否 consistent
hdr http 取决于 hash_type 是否 consistent
rdp-cookie tcp 取决于 hash_type 是否 consistent

4.2 各算法使用场景

算法 使用场景
first 使用较少，节约成本
static-rr 做了 session 共享的 web 集群
roundrobin 做了 session 共享的 web 集群
random 做了 session 共享的 web 集群
leastconn 数据库
source 基于客户端公网 IP 的会话保持
uri--------------->http 缓存服务器，CDN 服务商，蓝汛、百度、阿里云、腾讯
url_param--------->http 缓存服务器，CDN 服务商，蓝汛、百度、阿里云、腾讯
hdr 基于客户端请求报文头部做下一步处理
rdp-cookie 很少使用

五.四层与七层负载

在 HAProxy 或者 Nginx 等软件涉及到代理和负载均衡等概念时常常会引出四层和
七层负载、四层和七层流量等概念。实际上这里的四层和七层就对于网络协议栈中
ISO 标准的四层和七层。

层级 协议
七 应用层 HTTP/HTTPS/FTP.所以七层代理或者七层负载主要负载处理 HTTP 协议
六 表示层
五 会话层
四 传输层 TCP/UDP.所以四层转发或者四层负载主要处理 TCP 或 UDP 协议
三 网络层 IP
二 数据链路层 ARP/RARP
一 物理层

处理七层负载时主要涉及 HTTP 协议的请求头，请求体和请求方法等概念。
处理四层负载主要是 TCP 协议，涉及 IP 地址和端口等概念。

5.1 四层负载

在四层负载设备中，把 client 发送的报文目标地址(原来是负载均衡设备的 IP
地址)，根据均衡设备设置的选择 web 服务器的规则选择对应的 web 服务器 IP
地址，这样 client 就可以直接跟此服务器建立 TCP 连接并发送数据。

5.2 七层负载

七层负载均衡服务器起了一个反向代理服务器的作用，服务器建立一次 TCP 连接
要三次握手，而 client 要访问 webserver 要先与七层负载设备进行三次握手
后建立 TCP 连接，把要访问的报文信息发送给七层负载均衡；然后七层负载均衡
再根据设置的均衡规则选择特定的 webserver，然后通过三次握手与此台
webserver 建立 TCP 连接，然后 webserver 把需要的数据发送给七层负载均衡
设备，负载均衡设备再把数据发送给 client；所以，七层负载均衡设备起到了代
理服务器的作用。

六.IP 透传

IP 透传实际上就是指将客户端的 IP 发送给后端服务器，默认后端服务器是不知道
请求来自哪个客户端的。HAProxy 可以在四层或者七层将客户端的 IP 传给后端
服务器，以便做访问和日志分析。

6.1 四层 IP 透传配置

listen stats
        mode http
        bind 172.20.2.189:9999
        stats enable
        log global
        stats uri    /haproxy_status
        stats auth   haadmin:stevenux

frontend  WEB_PORT_80
    bind 172.20.2.189:8080
    mode http
    use_backend  web_prot_http_nodes

backend web_prot_http_nodes
    mode   tcp
    balance random
    option forwardfor
    server node1 172.20.2.37:80 send-proxy weight 1 check inter 3000 fall 3 rise 5 # 加send-proxy就可以
    server node2 172.20.2.43:80 send-proxy weight 1 check inter 3000 fall 3 rise 5
    server node3 172.20.2.44:80 send-proxy weight 1 check inter 3000 fall 3 rise 5
    server node4 172.20.2.45:80 send-proxy weight 1 check inter 3000 fall 3 rise 5

# 后端Nginx配置：
http {
    ......
log_format  main  '"$http_x_forwarded_For" - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" ';
server {

        listen       80 proxy_protocol;  # 增加选项proxy_protocol
        #listen       80;
        server_name  localhost;
......
        access_log  logs/host.access.log  main;
    }
}

6.2 七层 IP 透传配置

当 haproxy 工作在七层的时候，如何透传客户端真实 IP 至后端服务器？

6.2.1 HAProxy 配置

# haproxy 配置：
defaults
option  forwardfor

# 或者：
option forwardfor header X-Forwarded-xxx # 自定义传递IP参数,后端web服务器写X-Forwarded-xxx，

# 如果写
option forwardfor  # 则后端服务器web格式为X-Forwarded-For

listen配置示例：
listen  web_host
  bind 192.168.7.101:80
  mode http
  log global
  balance  random
  server web1  192.168.7.103:80 weight 1  check inter 3000 fall 2 rise 5
  server web2  192.168.7.104:80 weight 1  check inter 3000 fall 2 rise 5

6.2.2 web 服务器日志格式配置

配置 web 服务器，以记录负载均衡透传的客户端 IP 地址

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

# tomcat 配置：
pattern='%{X-Forwarded-For}i %l %T %t &quot;%r&quot; %s %b &quot;%{User-Agent}i&quot;'/>

# nginx 日志格式：
log_format  main  '"$http_x_forwarded_For" - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" ';

访问测试文章来源地址https://www.toymoban.com/news/detail-669541.html

# 172.20.1.1为客户端地址
[root@node1 ~]# tail -f /apps/nginx/logs/access.log
"172.20.2.195" - - [13/Jan/2020:19:01:38 +0800] "GET / HTTP/1.1" 200 18 "-" "curl/7.29.0"
"172.20.1.1" - - [13/Jan/2020:19:01:49 +0800] "GET /index1.html HTTP/1.1" 200 26 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0"
"172.20.1.1" - - [13/Jan/2020:19:01:52 +0800] "GET /index1.html HTTP/1.1" 200 26 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0"
"172.20.1.1" - - [13/Jan/2020:19:01:55 +0800] "GET /index1.html HTTP/1.1" 200 26 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0"
"172.20.1.1" - - [13/Jan/2020:19:02:22 +0800] "GET /index1.html HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0"
......

到了这里，关于HAProxy 调度算法介绍的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包 赞助服务器费用

相关文章

  • 集群、负载均衡集群、高可用集群简介，LVS模式和haproxy/nginx模式拓扑介绍

    集群、负载均衡集群、高可用集群简介，LVS模式和haproxy/nginx模式拓扑介绍

    目录 一.集群的定义 1.定义 2.分类 （1）负载均衡集群（LBC/LB） （2）高可用集群（HAC） 二.使用集群的意义 1.高性价比和性能比 2.高可用性 3.可伸缩性强 4.持久和透明性高 三.常见的两种集群模式拓扑 1.LVS（-DR）集群模式 （1）工作架构 （2）LVS下的相关术语 （3）LVS的工作模式

    2024年02月13日
    浏览(40)
  • （学习笔记-调度算法）进程调度算法

    （学习笔记-调度算法）进程调度算法

    进程调度算法也称 CPU 调度算法，毕竟进程是由 CPU 调度的。 当 CPU 空闲时，操作系统就选择内存中标的某个 [就绪状态] 的进程，将其分配给 CPU。 什么时候会发生CPU调度呢？通常有以下情况： 当进程从运行状态转换到等待状态 当进程从运行状态转换到就绪状态 当进程从等待

    2024年02月11日
    浏览(41)
  • 【调度算法】并行机调度问题遗传算法

    【调度算法】并行机调度问题遗传算法

    m台相同的机器，n个工件，每个工件有1道工序，可按照任意的工序为每个工件分配一台机器进行加工 工件 A B C D E F G H I 工件编号 0 1 2 3 4 5 6 7 8 加工时间 4 7 6 5 8 3 5 5 10 到达时间 3 2 4 5 3 2 1 8 6 交货期 10 15 30 24 14 13 20 18 10 设备数目：3 最小化交货期总延时时间 记机器数为 m ，从

    2024年02月05日
    浏览(54)
  • 操作系统调度算法--高响应比优先调度算法解析

    操作系统调度算法--高响应比优先调度算法解析

      高响应比优先调度算法（Highest Response Radio Next，HRRN）是一种对CPU中央控制器响应比的分配的算法。HRRN是介于FCFS（先来先服务算法）与SJF（短作业优先算法）之间的折中算法。FCFS算法所考虑的只是作业等待时间，而忽视了作业的运行时间（类似我们在生活中排队买东西）。

    2023年04月18日
    浏览(43)
  • 操作系统有关进程调度算法（含先来先服务，短作业优先，优先级调度算法和时间片轮转调度算法）

    操作系统有关进程调度算法（含先来先服务，短作业优先，优先级调度算法和时间片轮转调度算法）

    本文采用的进程调度算法有：先来先服务，短作业优先，优先级调度算法和时间片轮转调度算法。 针对这四种算法，我采用的是建立数组结构体，如： 先来先服务（FCFS）调度算法是一种最简单的调度算法，该算法既可用于作业调度，也可用于进程调度。采用FCFS算法，每次从

    2024年02月03日
    浏览(59)

  • OpenCL任务调度基础介绍

    当前，科学计算需求急剧增加，基于CPU-GPU异构系统的异构计算在科学计算领域得到了广泛应用，OpenCL由于其跨平台特性在异构计算领域渐为流行，其调度困难的问题也随之暴露，传统的OpenCL任务调度需要在编码阶段确定调度方案，这种人工调度难度高、适应性差、效率低下、

    2024年02月05日
    浏览(71)
  • Cinder调度之Filter介绍

    Cinder调度之Filter介绍

    AvailabilityZoneFilter : 按可用区过滤后端。 CapacityFilter : 基于卷后端的容量利用率的容量过滤器。 CapabilitiesFilter : 基于volume type中的extra specs(例如最常用的volume_backend_name) 除此三个常用的Filter外，还有DifferentBackendFilter，SameBackendFilter, DriverFilter, InstanceLocalityFilter, JsonFilter, RetryFi

    2024年02月06日
    浏览(34)
  • 操作系统进程调度算法——先来先服务、时间片轮转、优先级调度算法

    操作系统进程调度算法——先来先服务、时间片轮转、优先级调度算法

    （1）算法内容： 先来先服务调度算法是一种最简单的调度算法，可以应用于高级调度也可以运用于低级调度。高级调度时，FCFS调度算法按照作业进入后备作业队列的先后顺序选择作业进入内存，即先进入后备作业队列的作业被优先选择进入内存，然后为选中的作业创建进程

    2023年04月21日
    浏览(41)
  • 磁盘调度算法之先来先服务(FCFS)，最短寻找时间优先(SSTF)，扫描算法(SCAN，电梯算法)，LOOK调度算法

    磁盘调度算法之先来先服务(FCFS)，最短寻找时间优先(SSTF)，扫描算法(SCAN，电梯算法)，LOOK调度算法

    寻找时间（寻道时间） Ts:在读/写数据前，将磁头移动到指定磁道所花的时间。 ① 启动磁头臂 是需要时间的。假设耗时为s; ② 移动磁头 也是需要时间的。假设磁头匀速移动，每跨越一个磁道耗时为m，总共需要跨越n条磁道。 则寻道时间 T s = s + m ∗ n Ts =s + m*n T s = s + m ∗

    2024年02月08日
    浏览(45)

  • 【调度算法】快速非支配排序算法

    这段代码实现的是快速非支配排序算法（Fast Non-dominated Sorting Algorithm）。 算法输入和输出： 这个函数的输入是两个列表 values1 和 values2 ，分别表示多目标优化问题中每个解在两个目标函数下的取值。输入的两个列表应该具有相同长度，即每个解在两个目标函数下均有取值。

    2024年02月07日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包