目前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保持一致；