目前haproxy支持的负载均衡算法有如下8种
1.roundrobin
动态加权轮询算法，支持权重的运行时调整及慢启动机制；最大支持4095个后端主机；在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。
2.leastconn
最小连接数算法，连接数最少的服务器优先接收连接。建议用于长会话场景中使用，例如LDAP、SQL等协议，而不适合短会话协议。如HTTP.该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。
3.static-rr
静态轮询算法，不支持权重的运行时调整和慢启动机制。每个服务器根据权重轮流使用，类似roundrobin。另外，它对服务器的数量没有限制。
4、source
源地址哈希算法，对请求源IP地址进行哈希；
取模法：将源地址hash计算后除以服务器总权重,服务器变动会影响全局调度效果；根据结果进行分配。只要服务器正常，同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化，那么客户端会定向到不同的服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连；
一致性hash:服务器变动仅影响局部调度；动态调度;
5、uri
表示根据请求的URI左端（问号之前）或整个URI做hash进行哈希计算，并与服务器的总权重相除后根据结果派发至某挑选出的后端主机。只要服务器正常，以最大限度的提高缓存的命中率。
作用是能够将对同一个uri的请求始终发往一个后端主机；适用于后端为缓存服务器和反病毒代理的场景； 该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。该算法只能用于HTTP后端。
6、url_param
在HTTP GET请求的查询串中查找<param>中指定的URL参数的值做hash计算，并与服务器的总权重相除后派发至某挑选出的后端主机；基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求；
此算法常用来追踪请求中的用户标识，以确保来自同一个用户的请求始终发往同一个后端主机；
该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
7、hdr(name)
对于每个http请求，此处由<name>指定的http首部会被取出；如果此首部没有有效值，则用roundrobin代替；否则，对其值进行hash计算，并与服务器的总权重相除后派发至某挑选出的后端主机；
该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
8、rdp-cookie（name）
为每个进来的TCP请求查询并哈希RDPcookie<name>；
该机制用于退化的持久模式，可以使同一个用户或者同一个会话ID总是发送给同一台服务器。如果没有cookie，则使用roundrobin算法代替；
该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
————————————————————————————————————————————
hash-type算法类型：可作用于所有需要进行hash计算的算法中【可定义在defaults,listen,backend】,在balance 指令中选定与hash 有关的算法，都会受此影响。
hash-type <method> <function> <modifier>
<method>：map-based/consistent <function>:sdbm/djb2/wt6
默认采取的方法为map-based
< method > 如下：
map-based：取模法，hash数据结构是静态数组；该hash是静态的，不支持在线调整权重，不支持慢启动；
该算法调度平滑，后端服务器能够均匀承受负载;缺点也是明显的：当服务器的总权重发生变化时，即有服务器上线或下线，都会导致调度结果整体改变。如果想避免此种情况应采用consistent 方法；
consistent：一致性哈希，哈希的数据结构是“树”；该hash是动态的，支持在线调整权重，支持慢启动
每一个server 会在"树"中出现多次， 在树中查找hash key，并选择最近的server；
该方法的优点在于，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动。所以十分适合缓存服务器；
缺点：该算法不够平滑，很容易导致后端服务器负载不均衡。所以很有必要对服务器的权重以或者服务器ID进行调整；
为保持均匀负载，应该保证所有服务器ID保持一致；
