haproxy调度算法详解二

uri

基于对用户请求的uri做hash并将请求转发到后端指定服务器，也可以通过map-based和consistent定义使用取模法还是一致性hash。

http://example.org/absolute/URI/with/absolute/path/to/resource.txt #URI/URL；对于网络来讲既是URL也是URI
ftp://example.org/resource.txt   #URI/URL
/relative/URI/with/absolute/path/to/resource.txt   #URI；对于服务器来讲，只是URI

uri 一致性hash配置

根据uri做hash运算，用于缓存服务器

listen yewu-service-80
bind 192.168.38.37:80
mode http
balance uri             #根据用户请求的uri进行调度；uri是属于应用层，所以mode后面的协议类型必须为http协议
hash-type consistent
option forwardfor
server web1 192.168.38.27:80 weight 1 check inter 3000 fall 3 rise 5
server web2 192.168.38.47:80 weight 1 check inter 3000 fall 3 rise 5

url_param

url_param对用户请求的url中的params部分中的参数name（根据用户URL请求中的参数，也就是把指定的key取出来，对key的值作hash运算）作hash计算，并且除以服务器总权重以后派发至某台后端服务器；通常用于追踪用户，以确保来自同一个用户的请求始终发往同一个real server

假设url = http://www.xxx.com/foo/bar/index.php?k1=v1&&k2=v2
host = "www.xxx.com"
url_param = "k1=v1&k2=v2"

url_param取模法

示例：

listen yewu-service-80
bind 192.168.38.37:80
mode http
balance url_param name
option forwardfor
server web1 192.168.38.27:80 weight 1 check inter 3000 fall 3 rise 5
server web2 192.168.38.47:80 weight 1 check inter 3000 fall 3 rise 5

url_param一致性hash

示例：

listen yewu-service-80
bind 192.168.38.37:80
mode http
balance url_param name,age           #支持对单个及多个url_param值hash
hash-type consistent
option forwardfor
server web1 192.168.38.27:80 weight 1 check inter 3000 fall 3 rise 5
server web2 192.168.38.47:80 weight 1 check inter 3000 fall 3 rise 5 

注：如果请求时是两个参数，则有可能对第一个参数做hash，也有可能对第二个参数做hash，只会对一个参数做hash运算，所以尽可能请求时指定一个参数。

hdr

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

hdr取模法

listen yewu-service-80
bind 192.168.38.37:80
mode http
balance hdr(User-Agent)      #根据用户的浏览器类型做hash运算，然后与后端服务器的总权重相除，进行调度        
option forwardfor
server web1 192.168.38.27:80 weight 1 check inter 3000 fall 3 rise 5
server web2 192.168.38.47:80 weight 1 check inter 3000 fall 3 rise 5

一致性hash

listen yewu-service-80
bind 192.168.38.37:80
mode http
balance hdr(User-Agent)
hash-type consistent              
option forwardfor
server web1 192.168.38.27:80 weight 1 check inter 3000 fall 3 rise 5
server web2 192.168.38.47:80 weight 1 check inter 3000 fall 3 rise 5

rdp-cookie

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

rdp-cookie一致性hash

listen RDP
bind 192.168.38.37:3389  #rdp协议端口默认是3389
mode tcp                 #必须基于TCP协议做目标端口转发功能
balance rdp-cookie
hash-type consistent
option forwardfor
server web1 192.168.37.98:3389 weight 1 check inter 3000 fall 3 rise 5

注：跨网段，需要开启路由器转发功能；vim /etc/sysctl.conf；TCP是不分析到用户请求的应用层信息，只分析到传输层，所以haproxy会基于端口号做转发，所以需要开启路由器转发功能；rdp-cookie也支持取模法。

基于iptables实现rdp-cookie

iptables -t nat -A PREROUTING -d 192.168.38.37 -p tcp --dport 63389 -j DNAT --to-destination 172.18.2.100:3389
iptables -t nat -A POSTROUTING -s 192.168.38.0/24 -j SNAT --to-source 192.168.38.37

random

在1.9版本开始增加一个叫做random的负载平衡算法，其基于一个随机数（用户请求时分配一个随机数）作为一致性hash的key，随机负载平衡对于大型服务器场或经常添加或删除服务器非常有用，因为它可以避免在这种情况下由roundrobin或leastconn导致的锤击效应；random属于动态算法，支持慢启动等。

示例：

listen yewu-service-80
bind 192.168.38.37:80
mode http
balance random
server web1 192.168.38.27:80 weight 1 check inter 3000 fall 3 rise 5
server web2 192.168.38.47:80 weight 1 check inter 3000 fall 3 rise 5

算法总结

static-rr---->tcp/http 静态
first-------->tcp/http 静态

roundrobin--->tcp/http 动态
leastconn---->tcp/http 动态
random------->tcp/http 动态

source------->tcp/http
Uri---------->http
url_param---->http    动、静算法取决于hash_type是否consistent；要想实现算法，必须是http方式；TCP反向代理也可使用，但是会转换成roundrobin算法
hdr---------->http
rdp-cookie--->tcp

各算法使用场景

first              #使用较少

static-rr          #做了session共享的web集群
roundrobin
random

leastconn          #数据库
source             #基于客户端公网IP的会话保持；但是一个局域网都用一个公网IP，会造成调度不均匀

Uri--------->http  #缓存服务器，CDN服务商
url_param--->http 

hdr                #基于客户端请求报文头部做下一步处理

rdp-cookie         #很少使用

来源：https://www.cnblogs.com/dongzhanyi123/p/12180079.html