Haproxy支持的調度算法

目前haproxy支持的負載均衡算法有以下8

1.roundrobin

動態加權輪詢算法,支持權重的運行時調整及慢啓動機制;最大支持4095個後端主機;在服務器的處理時間平均分配的狀況下這是最流暢和公平的算法。該算法是動態的,對於實例啓動慢的服務器權重會在運行中調整。

2.leastconn

最小鏈接數算法,鏈接數最少的服務器優先接收鏈接。建議用於長會話場景中使用,例如LDAP、SQL等協議,而不適合短會話協議。如HTTP.該算法是動態的,對於實例啓動慢的服務器權重會在運行中調整。算法

3.static-rr

靜態輪詢算法,不支持權重的運行時調整和慢啓動機制。每一個服務器根據權重輪流使用,相似roundrobin。另外,它對服務器的數量沒有限制。

4source

源地址哈希算法,對請求源IP地址進行哈希;後端

取模法:將源地址hash計算後除以服務器總權重,服務器變更會影響全局調度效果;根據結果進行分配。只要服務器正常,同一個客戶端IP地址老是訪問同一個服務器。若是哈希的結果隨可用服務器數量而變化,那麼客戶端會定向到不一樣的服務器;該算法默認是靜態的,因此運行時修改服務器的權重是無效的,可是算法會根據「hash-type」的變化作調整。數組

該算法通常用於不能插入cookie的Tcp模式。它還能夠用於廣域網上爲拒絕使用會話cookie的客戶端提供最有效的粘連;緩存

一致性hash:服務器變更僅影響局部調度;動態調度;服務器

五、uri

表示根據請求的URI左端(問號以前)或整個URI作hash進行哈希計算,並與服務器的總權重相除後根據結果派發至某挑選出的後端主機。只要服務器正常,以最大限度的提升緩存的命中率。cookie

做用是可以將對同一個uri的請求始終發往一個後端主機;適用於後端爲緩存服務器和反病毒代理的場景; 該算法默認是靜態的,因此運行時修改服務器的權重是無效的,可是算法會根據「hash-type」的變化作調整。該算法只能用於HTTP後端。數據結構

6url_param

在HTTP GET請求的查詢串中查找<param>中指定的URL參數的值作hash計算,並與服務器的總權重相除後派發至某挑選出的後端主機;基本上能夠鎖定使用特製的URL到特定的負載均衡器節點的要求;負載均衡

此算法經常使用來追蹤請求中的用戶標識,以確保來自同一個用戶的請求始終發往同一個後端主機;ide

該算法默認是靜態的,因此運行時修改服務器的權重是無效的,可是算法會根據「hash-type」的變化作調整。url

7hdr(name)

對於每一個http請求,此處由<name>指定的http首部會被取出;若是此首部沒有有效值,則用roundrobin代替;不然,對其值進行hash計算,並與服務器的總權重相除後派發至某挑選出的後端主機;

該算法默認是靜態的,因此運行時修改服務器的權重是無效的,可是算法會根據「hash-type」的變化作調整。

8rdp-cookiename

爲每一個進來的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保持一致;

相關文章
相關標籤/搜索