haproxy调度算法

调度算法

balance： 指明对后端服务器的调度算法，配置在listen或backend

1.静态

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

• static-rr：基于权重的轮询调度，不支持权重的运行时调整及后端服务器慢启动，其后端主机数量没有限制
• first：根据服务器在列表中的位置，自上而下进行调度，但是其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务，因此会忽略服务器的权重设置。

2.动态

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

需要打开sock文件
先创建/var/lib/haproxy文件夹，修改配置，重启服务

stats socket /var/lib/haproxy/haproxy.sock mode 600 level admin

• roundrobin：基于权重的轮询动态调度算法，支持权重的运行时调整，不等于lvs 的rr，支持慢启动即新加的服务器会逐渐增加转发数，每个后端backend中最多支持4095个server，此为默认调度算法，server 权重设置 weight
一旦重启，就会失效

• leastconn： 加权的最少连接的动态，支持权重的运行时调整和慢启动，即当前后端服务器连接最少的优先调度，比较适合长连接的场景使用，比如MySQL等场景。mode为tcp 四层

3.调度算法-source

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

hash-type选项

• map-based：取模法，基于服务器权重的hash数组取模，该hash是静态的即不支持在线调整权重，不支持慢启动，其对后端服务器调度均衡，缺点是当服务器的总权重发生变化时，即有服务器上线或下线，都会因权重发生变化而导致调度结果整体改变， hash（o）mod n

• consistent：一致性哈希，该hash是动态的，支持在线调整权重，支持慢启动，优点在于当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动。

listen web_prot_http_nodes
 bind 192.168.7.101:80
 mode http
 
 balance source
 hash-type consistent
 log global
 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

一致性hash

4.调度算法-uri

uri：基于对用户请求的uri做hash并将请求转发到后端指定服务器
• map-based：取模法
• consistent：一致性哈希
uri 统一资源标识符,是一个用于标识某一互联网资源名称的字符串

listen web_prot_http_nodes
	 bind 192.168.7.101:80
	 mode http #不支持tcp，会切换到tcp的roundrobin负载模式
	 
	 balance uri
	 hash-type consistent
	 log global
	 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

5.调度算法url_param

url_param：
对用户请求的url中的部分中的参数name作hash计算，并由服务器总权重相除以后派发至某挑出的服务器；通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个Backend Server

假设url = http://www.qcq.com/foo/bar/index.php?nice=1
则：
host = “www.qcq.com”
url_param = ‘nice=1’

listen web_prot_http_nodes
	 bind 192.168.7.101:80
	 mode http #不支持tcp，会切换到tcp的roundrobin负载模式
	 
	 balance url_param name #基于参数name做hash
	 hash-type consistent
	 log global
	 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

6.调度算法-hdr

也就是相同的浏览器，会调度到相同的后端服务器上
hdr()：针对用户每个http头部(header)请求中的指定信息做hash，此处由指定的http首部将会被取出并做hash计算，然后由服务器总权重相除以后派发至某挑出的服务器，假如无有效的值，则会被轮询调度

hdr( Cookie、 User-Agent、host )

 listen web_prot_http_nodes
	 bind 192.168.7.101:80
	 mode http
	 
	 balance hdr(User-Agent)
	 hash-type consistent
	 
	 log global
	 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

7.调度算法- rdp-cookie

rdp-cookie对远程桌面的负载，使用cookie保持会话
rdp-cookie()
示例：

listen RDP
	 bind 192.168.7.101:3389
	 balance rdp-cookie
	 mode tcp
	 server rdp0 172.18.139.20:3389 check fall 3 rise 5 inter 2000 weight 1
	 server rdp1 172.18.139.21:3389 check fall 3 rise 5 inter 2000 weight 1



 基于iptables实现目标地址转换：
 iptables -t nat -A PREROUTING -d 192.168.7.101 -p tcp --dport 3389 -j DNAT --to-destination 
172.18.139.20:3389
 iptables -t nat -A POSTROUTING -s 192.168.0.0/21 -j SNAT --to-source 192.168.7.101

算法总结

四层
roundrobin ，做过session共享用的最多的调度算法（默认）
leastconn，用于后端非服务器Mysql
statir-rr 静态熏晕，等于roundrobin
first很少用
source 后端服务器没有做session共享，还要实现会话保持
rdp-cookie 用户Windows远程桌面
七层
uri和url_param一般用于CDN厂商（缓存场景）
hdr-基于请求头部指定的信息做调度