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 #很少使用