roundrobin

HAProxy各种调度算法介绍

HAProxy调度算法介绍

HAProxy的调度算法⽐较多，在没有设置mode或者其它选项时，HAProxy默认对

后端服务器使⽤roundrobin算法来分配请求处理。对后端服务器指明使⽤的算法

时使⽤balance关键字，该关键字可在listen和backend中出现。在HAProxy

运⾏时⽀持动态调整后端服务器权重、并且考虑后端服务器负载等情况的算法，我们

称之为动态算法；相反，不能动态调整后端服务器权重也不考虑服务器负载的

算法叫静态算法。指定调度策略的典型配置如下：

backendsrv_group1

modehttp

logglobal

#balance[]

balancestatic-rr

rverweb1ip:portweight2checkinter300000msfall2ri5

HAProxy服务器

172.20.2.189ubuntu-suosuoli-node1

系统:Ubuntu1804

四台后端服务器

172.20.2.37node1

172.20.2.43node2

172.20.2.44node3

172.20.2.45node4

系统都为CentOS7.7

客户端

172.20.2.195client-node1

系统为CentOS7.7

准备环境

root@ubuntu-suosuoli-node1:~#vim/etc/ansible/

......

[backend]

172.20.2.37

172.20.2.43

172.20.2.44

172.20.2.45

......

root@ubuntu-suosuoli-node1:~#ansiblebackend-mshell-a"nginx-t"

172.20.2.43|SUCCESS|rc=0>>

nginx:theconfigurationfile/etc/nginx/ntaxisok

nginx:configurationfile/etc/nginx/stissuccessful

172.20.2.45|SUCCESS|rc=0>>

nginx:theconfigurationfile/etc/nginx/ntaxisok

nginx:configurationfile/etc/nginx/stissuccessful

172.20.2.37|SUCCESS|rc=0>>

nginx:theconfigurationfile/apps/nginx/conf/ntaxisok

nginx:configurationfile/apps/nginx/conf/stissuccessful

172.20.2.44|SUCCESS|rc=0>>

nginx:theconfigurationfile/etc/nginx/ntaxisok

nginx:configurationfile/etc/nginx/stissuccessful

root@ubuntu-suosuoli-node1:~#ansiblebackend-mshell-a"nginx-sreload"

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:~#ansiblebackend-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/loglocal0

log/dev/loglocal1notice

chroot/var/lib/haproxy

nbproc2

cpu-map10

cpu-map21

statssocket/run/haproxy/2mode660leveladminexpo-fdlisteners

#statssocket/run/haproxy/1mode660leveladminexpo-fdlistenersprocess1

#statssocket/run/haproxy/2mode660leveladminexpo-fdlistenersprocess2

statstimeout30s

urhaproxy

grouphaproxy

daemon

#DefaultSSLmateriallocations

ca-ba/etc/ssl/certs

crt-ba/etc/ssl/private

#See:/#rver=haproxy&rver-version=2.0.3&config=intermediate

ssl-default-bind-ciphersECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-R

SA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES

256-GCM-SHA384

ssl-default-bind-ciphersuitesTLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

ssl-default-bind-optionsno-sslv3no-tlsv10no-tlsv11no-tls-tickets

defaults

logglobal

modehttp

optionhttplog

optiondontlognull

optionhttp-keep-alive

timeoutconnect300000ms

timeoutclient300000ms

timeoutrver300000ms

errorfile400/etc/haproxy/errors/

errorfile403/etc/haproxy/errors/

errorfile408/etc/haproxy/errors/

errorfile500/etc/haproxy/errors/

errorfile502/etc/haproxy/errors/

errorfile503/etc/haproxy/errors/

errorfile504/etc/haproxy/errors/

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_8080

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

#balanceroundrobin默认使⽤该调度策略

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

⼀.静态调度算法

静态算法：按照事先定义好的规则轮询公平调度，不关⼼后端服务器的当前负载、链接数

和相应速度等，且⽆法实时修改权重，只能靠重启HAProxy⽣效。

HAProxy运⾏时，要动态修改服务器权重，需要安装额外的⼯具socat。Socat是Linux

下的命令⾏⼯具，全名叫SocketCAT，Socat的主要⼯作原理是建⽴⼀个双向的通道，

并在这个通道传输⽐特流。其⽀持众多协议和链接⽅式。如IP、TCP、UDP、IPv6、Socket

⽂件等。由于其功能强⼤，可以有多种⽤途，由于其可以转发TCP流，甚⾄有⼈将它配置为

防⽕墙。

#Centos安装

yuminstallsocat-y

#此处使⽤Ubuntu1804

root@ubuntu-suosuoli-node1:~#apt-cachemadisonsocat

socat|1.7.3.2-2ubuntu2|/ubuntubionic/mainamd64Packages

socat|1.7.3.2-2ubuntu2|/ubuntubionic/mainamd64Packages

socat|1.7.3.2-2ubuntu2|/ubuntubionic/mainSources

root@ubuntu-suosuoli-node1:~#aptinstallsocat

root@ubuntu-suosuoli-node1:~#socat-V

#这是它官⽹，作者应该是个极简主义者

socatversion1.7.3.2onApr4201810:06:49

......

#获取后端服务器node3的权重可以这样做

root@ubuntu-suosuoli-node1:~#find/-

/run/haproxy/

root@ubuntu-suosuoli-node1:~#echo"getweightweb_prot_http_nodes/node3"|socatstdio/run/haproxy/

3(initial3)

#设置没某个后端服务器的权重可以这样，但是我⽤的是static-rr算法，不可以动态调整权重。只接受0或者1

#0就表⽰不参与请求处理，1表⽰参与

root@ubuntu-suosuoli-node1:~#echo"tweightweb_prot_http_nodes/node36"|socatstdio/run/haproxy/

BackendisusingastaticLBalgorithmandonlyacceptsweights'0%'and'100%'.

BTW:

1.1static-rr

staticroundrobin:静态轮询调度策略，使⽤基于权重的轮询调度策略。权重

在配置⽂件中指定后不可动态更改和后端服务器慢启动，此调度策略对后端服务

器最⼤数量没有限制。

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balancestatic-rr

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight2checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight2checkinter3000fall3ri5

client-node1上测试效果

[root@client-node1~]#while:;docurl172.20.2.189:8080;sleep0.1;done

node1172.20.2.37

node2172.20.2.43

node4172.20.2.45

node2172.20.2.43

node3172.20.2.44

node4172.20.2.45

node1172.20.2.37

node2172.20.2.43

......

#44此访问，被调度的⽐例接近1:2:1:2的权重值

[root@client-node1~]#|wc-l

44

[root@client-node1~]#|sort|uniq-c

8node1172.20.2.37

15node2172.20.2.43

7node3172.20.2.44

14node4172.20.2.45

1.2first

first:根据服务器在列表中的位置，⾃上⽽下进⾏调度(不⼈为的设定，从上到

下各台服务器的id会⾃动增加，第⼀台服务器的id为1)，但是其只会当第⼀

台服务器的连接数达到上限(maxconn参数)，新请求才会分配给下⼀台服务，

因此HAProxy会忽略服务器的权重值，这样⽐较适合长会话的协议如：RDP

和IMAP。不指定maxconn参数使⽤该调度策略是没有意义的(懂我意思吗?)。

实现该调度算法的实际⽤途是在⽐较空闲的时间段关闭某些服务器以使⽤最少的服

务器提供服务，节约成本。

如果需要⼈为指定id，则可以在rverrver_nameip:port指令后⾯加上

idid号必须是正整数。

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balancefirst

optionforwardfor

rvernode1172.20.2.37:80maxconn2weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight2checkinter3000fall3ri5

rvernode3172.20.2.44:80maxconn2weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight2checkinter3000fall3ri5

client-node1上测试

#在两个窗⼝同时访问HAProxy

[root@client-node1~]#tty

/dev/pts/0

[root@client-node1~]#while:;docurl172.20.2.189:8080;done

...

[root@client-node1~]#tty

/dev/pts/1

[root@client-node1~]#while:;docurl172.20.2.189:8080;done

node1172.20.2.37

node1172.20.2.37

node2172.20.2.43

......

node1172.20.2.37

node1172.20.2.37

node2172.20.2.43

......

#可以看到，在某些时间⼏乎同时有两个以上的请求到达node1，这时HAProxy

#就会调度node2处理多出的请求

⼆.动态调度算法

2.1roundrobin

roundrobin该算法是默认使⽤的调度策略。该算法会根据每个后端服务器的

权重weight依次将请求分发到后端服务器。当后端服务器的处理性能⽐较均

衡的分布时，使⽤该算法⽐较好。在该算法使⽤时，可以动态调整后端服务器

的权重，以便调整整个服务器组的性能。由于设计的限制，每个后端服务器组

最多只能定义4095个活动服务器。该roudrobin算法⽀持慢启动(slow

start)，表⽰新加⼊的服务器会在⼀段时间内逐渐增加⼯作负载(转发量)。

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

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_8080

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

#balanceroundrobin默认使⽤该调度策略

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

[root@client-node1~]#while:;docurl172.20.2.189:8080;sleep3;done

node4172.20.2.45

node1172.20.2.37

node2172.20.2.43

node3172.20.2.44

node4172.20.2.45

node1172.20.2.37

node2172.20.2.43

^C

#配置指明后端服务器的权重weight都为1，所以后端服务器被轮流调度处理请求

更改服务器的权重

root@ubuntu-suosuoli-node1:~#echo"getweightweb_prot_http_nodes/node1"|socatstdio/run/haproxy/

1(initial1)

root@ubuntu-suosuoli-node1:~#echo"getweightweb_prot_http_nodes/node2"|socatstdio/run/haproxy/

1(initial1)

root@ubuntu-suosuoli-node1:~#echo"getweightweb_prot_http_nodes/node3"|socatstdio/run/haproxy/

1(initial1)

root@ubuntu-suosuoli-node1:~#echo"getweightweb_prot_http_nodes/node4"|socatstdio/run/haproxy/

1(initial1)

#更改权重

root@ubuntu-suosuoli-node1:~#echo"tweightweb_prot_http_nodes/node22"|socatstdio/run/haproxy/

root@ubuntu-suosuoli-node1:~#echo"tweightweb_prot_http_nodes/node33"|socatstdio/run/haproxy/

root@ubuntu-suosuoli-node1:~#echo"tweightweb_prot_http_nodes/node44"|socatstdio/run/haproxy/

#查看是否⽣效

root@ubuntu-suosuoli-node1:~#echo"getweightweb_prot_http_nodes/node3"|socatstdio/run/haproxy/

3(initial1)

再次测试

[root@client-node1~]#while:;docurl172.20.2.189:8080;sleep0.01;done

node4172.20.2.45

node3172.20.2.44

node4172.20.2.45

node2172.20.2.43

node3172.20.2.44

node4172.20.2.45

node1172.20.2.37

node4172.20.2.45

node3172.20.2.44

......

#统计81次访问

[root@client-node1~]#|wc-l

81

[root@client-node1~]#|sort|uniq-c

8node1172.20.2.37

16node2172.20.2.43

24node3172.20.2.44

33node4172.20.2.45

#可以看到各个服务器被调度的⽐例接近权重node1:node2:node3:node4=1:2:3:4

#实际为node1:node2:node3:node4=8:16:24:33

2.2leastconn

leastconn加权的最少连接的动态，⽀持权重的运⾏时调整和慢启动，即当前后端

服务器连接最少的优先调度(新客户端连接)，⽐较适合长连接的场景使⽤，⽐如

MySQL等场景。

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balanceleastconn

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

三.其它算法

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

为动态算法。

3.1source

source调度策略为sourceIPhash(源地址哈希)，基于客户端源地址hash

并将请求转发到后端服务器，默认为静态⽅式即取模⽅式，但是可以通过hash-type

⽀持的选项更改，后续同⼀个源地址请求将被转发⾄同⼀个后端web服务器，⽐较

适⽤于ssion保持/缓存业务等场景。

源IP地址被HASH并除以正在运⾏的服务器的总权重值，取其结果的摸，得到⼀

个索引，以指定哪个服务器将接收请求。这确保了只要没有服务器宕机或恢复，相

同的客户端IP地址将始终到达相同的服务器。如果运算结果由于运⾏的服务器数量

的变化⽽发⽣变化，许多客户端请求将被定向到其它台服务器。该算法通常⽤于TCP

模式，其中不可以插⼊cookie信息。它也可以在Internet上使⽤，为拒绝会话

cookie的客户端提供最佳的粘性。默认情况下，这个算法是静态的，这意味着动态

地更改服务器的权重不会有任何影响，但是可以使⽤"hashtype"关键字来更改。

hash-type⽤来指定hash类型，类型可以是map-bad或者consistent

hash-typemap-bad#不指定时，默认使⽤该哈希⽅法

hash-typeconsistent

map-bad哈希⽅法

使⽤map-bad哈希⽅法时，哈希表(哈希的结果)是包含所有活动服务器的静态

数组。该哈希⽅法会考虑服务器权重。但是在服务器运⾏时权重发⽣变化会被忽略。

核⼼是按照服务器在数组中的位置来选择调度的服务器，所以当服务器有上线或者下

线时，总权重会发⽣变化，哈希也就变化了，这会导致⼤部分的连接将会重新被调度

到不同的服务器。这种调度算法不⽀持慢启动也不适合在使⽤缓存的场景使⽤。

consistent⼀致性哈希⽅法

使⽤consistent⼀致性哈希⽅法时，哈希表中每个服务器对应多个哈希值(这些

对应于同⼀个服务器的哈希值和该服务器的名称或者ID有关联)，这个哈希表使⽤

树结构(某种数据结构)来组织。HAProxy会在该树结构上查找哈希键，并选中最合适

的值。该哈希⽅法⽀持动态修改服务器权重，所以其⽀持慢启动。使⽤该调度策略的

优势是，当某个服务器停⽤或者再次启⽤时，只有和该服务器相关的哈希信息会被移

除。当某个服务器加⼊服务器组时，只有⼀部分连接会被重新分配，这使得⼀致性哈

希⽅法是使⽤缓存时的理想调度策略。

map-bad哈希⽅法配置

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balancesource

#hash-typemap-bad#可写可不写

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

在client-node1访问验证

[root@client-node1~]#while:;docurl172.20.2.189:8080;sleep1;done

node4172.20.2.45

node4172.20.2.45

node4172.20.2.45

......

在172.20.1.1访问验证

consistent⼀致性哈希⽅法配置

listenstats

modetcp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modetcp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balancesource

hash-typeconsistence#使⽤⼀致性哈希⽅法

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5`

3.2uri

uri调度算法会对URI的左侧部分(问号前⾯的部分)或者对整个URI进⾏哈希，

并使⽤活动服务器的总权重值除以该哈希值。计算结果决定了将请求调度到哪台服

务器。该调度算法常常在使⽤代理缓存时使⽤。也可以通过map-bad和

consistent定义使⽤取模法还是⼀致性hash。

/absolute/URI/with/absolute/path/to/#URI/URL

ftp:///#URI/URL

/relative/URI/with/absolute/path/to/#URI

#注意：URL是URI的⼦集

配置⽰例

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balanceuri

#hash-typemap-bad

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

访问测试

[root@client-node1~]#curl172.20.2.189:8080/

node3172.20.2.44

[root@client-node1~]#curl172.20.2.189:8080/

index1-node4-172.20.2.45

3.3url_param

url_param对⽤户请求的url中的params部分中的参数name作hash

计算，并除以服务器总权重，根据计算结果派发⾄某挑出的服务器；通常⽤

于追踪⽤户，以确保来⾃同⼀个⽤户的请求始终发往同⼀个realrver。

其亦可以使⽤hash-type指定⼀致性哈希⽅法。另外，如果找不到URL中

问号选项后的参数，则使⽤roundrobin算法。

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

假设

URL=/foo/bar/?key1=value1&key2=value2

那么

host=""

url_param="key1=value1&key2=value2"#该字符串就是要进⾏哈希运算的对象

url_param调度策略配置⽰例

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balanceurl_paramname,gender#⽀持对单个或多个url_param进⾏hash

#hash-typeconsistent#使⽤⼀致性hash⽅法

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

访问测试

#未带参数，都被调度到node1

[root@client-node1~]#curl172.20.2.189:8080/

node1172.20.2.37

[root@client-node1~]#curl172.20.2.189:8080/

index1-node2-172.20.2.43

#找不到参数则使⽤roudrobin轮询策略

[root@client-node1~]#curl172.20.2.189:8080/?name=jack

index1-node3-172.20.2.44

[root@client-node1~]#curl172.20.2.189:8080/?name=jack

index1-node4-172.20.2.45

[root@client-node1~]#curl172.20.2.189:8080/?name=jack

index1-node1--172.20.2.37

[root@client-node1~]#curl172.20.2.189:8080/?name=jack

index1-node2-172.20.2.43

[root@client-node1~]#curl172.20.2.189:8080/?name=jack

index1-node3-172.20.2.44

[root@client-node1~]#curl172.20.2.189:8080/?name=jack

index1-node4-172.20.2.45

3.4hdr

针对⽤户每个http头部(header)请求中的指定信息做hash，此处由name指定

的http⾸部将会被取出并做hash计算，然后由服务器总权重相除以后派发⾄某

挑出的服务器，假如⽆有效的值，则会使⽤默认的轮询调度。

hdr调度策略配置

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balancehdr(Ur-Agent)#使⽤客服端版本等信息进⾏哈希运算

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

访问测试

[root@client-node1~]#curl-V

curl7.29.0(x86_64-redhat-linux-gnu)libcurl/7.29.0NSS/3.36zlib/1.2.7libidn/1.28libssh2/1.4.3

Protocols:dictfileftpftpsgopherhttphttpsimapimapsldapldapspop3pop3srtspscpsftpsmtpsmtpstelnettftp

Features:AsynchDNSGSS-NegotiateIDNIPv6LargefileNTLMNTLM_WBSSLlibzunix-sockets

[root@client-node1~]#curl172.20.2.189:8080

node4172.20.2.45

[root@client-node1~]#curl172.20.2.189:8080

node4172.20.2.45

[root@client-node1~]#curl172.20.2.189:8080

node4172.20.2.45

[root@client-node1~]#curl172.20.2.189:8080

Chrome浏览器测试

FireFox浏览器测试

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

3.5rdp-cookie

rdp(windows远程桌⾯协议)-cookie⽤于对windows远程桌⾯的反向代理，

主要是使⽤cookie保持来会话；此调度算法专门适⽤于windows远程桌⾯

连接场景。当连接到后端服务器后，会⽣成⼀个cookie，下次相同的cookie

连接时，还会被调度到同⼀台后端服务器，适⽤于后端多服务器场景。

rdp-cookie配置⽰例

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modetcp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modetcp

balancerdp-cookie

hash-typeconsistence

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

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

_forward=1#必须开启ip转发功能

该算法只在四层，是不分析到⽤户请求的应⽤层信息的，只分析到传输层，所以

HAProxy会基于端⼝号做转发，所以需要开启路由器转发功能。

3.6random

该算法在1.9版本增加，其基于⼀个随机数作为⼀致性hash的key，随机负载

平衡对于⼤型服务器场或经常添加和删除服务器的场景⾮常有⽤，因为它可以避免

在这种情况下由roundrobin或leastconn导致的锤击效应。

random调度策略配置

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modehttp

balancerandom

optionforwardfor

rvernode1172.20.2.37:80weight1checkinter3000fall3ri5

rvernode2172.20.2.43:80weight1checkinter3000fall3ri5

rvernode3172.20.2.44:80weight1checkinter3000fall3ri5

rvernode4172.20.2.45:80weight1checkinter3000fall3ri5

访问测试

[root@client-node1~]#while:;docurl172.20.2.189:8080;sleep1;done

node2172.20.2.43

node1172.20.2.37

node4172.20.2.45

node1172.20.2.37

node1172.20.2.37

node4172.20.2.45

node2172.20.2.43

node4172.20.2.45

^C

[root@client-node1~]#while:;docurl172.20.2.189:8080>>;done

.....

[root@client-node1~]#|wc-l

1147

[root@client-node1~]#|sort|uniq-c

346node1172.20.2.37

201node2172.20.2.43

266node3172.20.2.44

333node4172.20.2.45

#可以看到各个服务器处理的请求数量没有规律，随机的(懂我意思吗？)

四.各算法使⽤场景

4.1总结

算法⽀持的协议静态/动态

static-rrtcp/http静态

firsttcp/http静态

roundrobintcp/http动态

leastconntcp/http动态

randomtcp/http动态

sourcetcp/http取决于hash_type是否consistent

urittp取决于hash_type是否consistent

url_paramttp取决于hash_type是否consistent

hdrhttp取决于hash_type是否consistent

rdp-cookietcp取决于hash_type是否consistent

4.2各算法使⽤场景

算法使⽤场景

first使⽤较少，节约成本

static-rr做了ssion共享的web集群

roundrobin做了ssion共享的web集群

random做了ssion共享的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要访问webrver要先与七层负载设备进⾏三次握⼿

后建⽴TCP连接，把要访问的报⽂信息发送给七层负载均衡；然后七层负载均衡

再根据设置的均衡规则选择特定的webrver，然后通过三次握⼿与此台

webrver建⽴TCP连接，然后webrver把需要的数据发送给七层负载均衡

设备，负载均衡设备再把数据发送给client；所以，七层负载均衡设备起到了代

理服务器的作⽤。

六.IP透传

IP透传实际上就是指将客户端的IP发送给后端服务器，默认后端服务器是不知道

请求来⾃哪个客户端的。HAProxy可以在四层或者七层将客户端的IP传给后端

服务器，以便做访问和⽇志分析。

6.1四层IP透传配置

listenstats

modehttp

bind172.20.2.189:9999

statnable

logglobal

statsuri/haproxy_status

statsauthhaadmin:stevenux

frontendWEB_PORT_80

bind172.20.2.189:8080

modehttp

u_backendweb_prot_http_nodes

backendweb_prot_http_nodes

modetcp

balancerandom

optionforwardfor

rvernode1172.20.2.37:80nd-proxyweight1checkinter3000fall3ri5#加nd-proxy就可以

rvernode2172.20.2.43:80nd-proxyweight1checkinter3000fall3ri5

rvernode3172.20.2.44:80nd-proxyweight1checkinter3000fall3ri5

rvernode4172.20.2.45:80nd-proxyweight1checkinter3000fall3ri5

#后端Nginx配置：

http{

......

log_formatmain'"$http_x_forwarded_For"-$remote_ur[$time_local]"$request"'

'$status$body_bytes_nt"$http_referer"'

'"$http_ur_agent"';

rver{

listen80proxy_protocol;#增加选项proxy_protocol

#listen80;

rver_namelocalhost;

......

access_loglogs/n;

}

}

6.2七层IP透传配置

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

6.2.1HAProxy配置

#haproxy配置：

defaults

optionforwardfor

#或者：

optionforwardforheaderX-Forwarded-xxx#⾃定义传递IP参数,后端web服务器写X-Forwarded-xxx，

#如果写

optionforwardfor#则后端服务器web格式为X-Forwarded-For

listen配置⽰例：

listenweb_host

bind192.168.7.101:80

modehttp

logglobal

balancerandom

rverweb1192.168.7.103:80weight1checkinter3000fall2ri5

rverweb2192.168.7.104:80weight1checkinter3000fall2ri5

6.2.2web服务器⽇志格式配置

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

#apache配置：

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

#tomcat配置：

pattern='%{X-Forwarded-For}i%l%T%t"%r"%s%b"%{Ur-Agent}i"'/>

#nginx⽇志格式：

log_formatmain'"$http_x_forwarded_For"-$remote_ur[$time_local]"$request"'

'$status$body_bytes_nt"$http_referer"'

'"$http_ur_agent"';

访问测试

#172.20.1.1为客户端地址

[root@node1html]#tail-f/apps/nginx/logs/

"172.20.1.1"--[12/Jan/2020:22:16:51+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:51+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:52+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:52+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:52+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:52+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:52+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:53+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:53+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

"172.20.1.1"--[12/Jan/2020:22:16:53+0800]"GET/HTTP/1.1"3040"-""Mozilla/5.0(WindowsNT10.0;Win64;x64;rv:72.0)Gecko/20100101Firefox/7

2.0"

......

脚注

1.。