一、靜態算法
按照事先定義好的規則輪詢公平調度,不關心后端服務器的當前負載、連接數和響應速度 等,且無法實時修改權重(只能為0和1,不支持其它值),只能靠重啟HAProxy生效。(不管后端死活)
1.1、static-rr:基于權重的輪詢調度
不支持運行時利用socat進行權重的動態調整(只支持0和1,不支持其它值)
不支持端服務器慢啟動
其后端主機數量沒有限制,相當于LVS中的 wrr
**慢啟動**是指在服務器剛剛啟動上不會把他所應該承擔的訪問壓力全部給它,而是先給一部分,當沒 問題后在給一部分
listen webserverbind *:80mode http
# balance roundrobinbalance static-rrserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1server sorry 192.168.217.100:8080 backup
效果
1.2、first
根據服務器在列表中的位置,自上而下進行調度
其只會當第一臺服務器的連接數達到上限,新請求才會分配給下一臺服務
其會忽略服務器的權重設置
不支持用socat進行動態修改權重,可以設置0和1,可以設置其它值但無效
listen webserverbind *:80mode httpbalance firstserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1server sorry 192.168.217.100:8080 backup
權重RS2是3一般會一點給,但first會忽略權重,讓寫在前面的RS1得到的請求更多,要等RS1連接上限了才會分配給其他
二、動態算法
基于后端服務器狀態進行調度適當調整,
新請求將優先調度至當前負載較低的服務器
權重可以在haproxy運行時動態調整無需重啟
2.1、roundrobin
listen webserverbind *:80mode httpbalance roundrobinserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3server sorry 192.168.217.100:8080 backup
2.2、leastconn
加權的最少連接的動態
listen webserverbind *:80mode httpbalance leastconnserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3server sorry 192.168.217.100:8080 backup
三、其他算法
3.1、source?
listen webserverbind *:80mode httpbalance sourceserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3server sorry 192.168.217.100:8080 backup
3.2、map-basse取模法
取模就是計算兩個數相除之后的余數比如當源hash值時1111,1112,1113,三臺服務器a b c的權重均為1,即abc的調度標簽分別會被設定為 0 1 2(1111%3=1,1112%3=2,1113%3=0)1111 ----- > nodeb1112 ------> nodec1113 ------> nodea如果a下線后,權重數量發生變化1111%2=1,1112%2=0,1113%2=11112和1113被調度到的主機都發生變化,這樣會導致會話丟失
?3.3、一致性hash
一致性哈希算法的核心思想是將哈希值空間組織成一個虛擬的環形空間(通常稱為一致性哈希環),并按照哈希值的大小順序將節點和數據映射到這個環上。
算法:
- 后端服務器哈希環點keyA=hash(后端服務器虛擬ip)%(2^32)
- 客戶機哈希環點key1=hash(client_ip)%(2^32) 得到的值在[0---4294967295]之間
- 將keyA和key1都放在hash環上,將用戶請求調度到離key1最近的keyA對應的后端服務器
節點的增加:新節點加入時,只需將其哈希值映射到環上,并將環上部分數據重新分配到新節點。
節點的減少:節點移除時,只需將該節點上的數據重新分配到其順時針方向的下一個節點。
當某一臺后端服務器下線后,就是節點移除了,就只需要將該電商的數據重新分配到其順時針方向的下一個節點。如圖中當keyB下線了,其附近的key2和key4就會按照順時針去到keyC節點上。
一致性hash配置
listen webserverbind *:80mode httpbalance sourcehash-type consistentserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3server sorry 192.168.217.100:8080 backup
3.4、uri算法
3.4.1、uri算法
HAProxy 對請求的 URI 進行哈希計算,生成一個哈希值。根據哈希值對后端服務器的總權重取模,將請求分配到特定的后端服務器
默認是靜態算法,也可以通過hash-type指定map-based和consistent,來定義使用取模法還是一致性 hash
注意:
URI 的范圍:
uri
算法可以基于 URI 的路徑部分或整個 URI(包括查詢字符串)進行哈希計算。- <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>左半部分:/<path>;<params>整個uri:/<path>;<params>?<query>#<frag>
僅支持 HTTP 模式:
uri
算法僅適用于 HTTP 模式(mode http
),不支持 TCP 模式。動態調整:使用一致性哈希算法時,后端服務器的增減對請求分配的影響較小
測試
3.4.2、url-param算法
#假設:url = http://www.timinglee.com/foo/bar/index.php?key=value#則:host = "www.timinglee.com"url_param = "key=value
核心原理
提取請求 URL 中指定的查詢參數(如
?user=123
中的user
)。對該參數的值進行哈希計算(支持一致性哈希)。
根據哈希值與后端服務器權重取模,決定請求路由到哪臺服務器。
相同參數值始終路由到同一臺服務器(會話保持效果)。
url_param配置示例
listen webserverbind *:80mode httpbalance url_param nameserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3server sorry 192.168.217.100:8080 backupurl_param一致性hash配置示例
listen webserverbind *:80mode httpbalance url-paramhash-type consistentserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 3server sorry 192.168.217.100:8080 backup
[root@clietn ~]# curl 192.168.217.100/index.html?name=timinglee
RS1 192.168.217.10 index3
[root@clietn ~]# curl 192.168.217.100/index.html?name=timinglee
RS1 192.168.217.10 index3
[root@clietn ~]# curl 192.168.217.100/index.html?name=lee
RS1 192.168.217.20 index3
[root@clietn ~]# curl 192.168.217.100/index.html?name=lee
RS1 192.168.217.20 index3
3.5 hdr
HAProxy 中的 hdr 算法 是一種基于 HTTP 請求頭部字段值 進行哈希計算的負載均衡算法,適用于 HTTP 模式(mode http),常用于實現基于特定頭部(如 User-Agent
、Authorization
、X-Forwarded-For
等)的會話保持或流量分發。
配置
hdr取模算法
listen webserverbind *:80mode httpbalance hdr(User-Agent)hash-type consistentserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1server sorry 192.168.217.100:8080 backuphdr一致性hash算法
listen webserverbind *:80mode httpbalance hdr(User-Agent)hash-type consistentserver web1 192.168.217.10:80 check inter 3s fall 5 rise 3 weight 1server web2 192.168.217.20:80 check inter 3s fall 5 rise 3 weight 1server sorry 192.168.217.100:8080 backup
測試
[root@client ~]# curl -vA "firefox" 172.25.254.100
[root@client ~]# curl -vA "sougou" 172.25.254.100-v:啟用詳細模式(verbose),會顯示請求頭、響應頭、連接過程等調試信息。
-A "firefox":設置 User-Agent 為 "firefox"
172.25.254.100:請求的目標地址(默認使用 http:// 協議,端口 80)。
算法總結
算法關鍵字 | 適用模式 | 調度依據 | 會話保持 | 一致性哈希 | 典型使用場景 | 備注說明 |
---|---|---|---|---|---|---|
roundrobin | http/tcp | 輪詢 + 權重 | 否 | 否 | 通用無狀態服務 | 默認算法 |
static-rr | http/tcp | 靜態權重輪詢 | 否 | 否 | 后端節點固定、無故障摘除 | 不重新分發 |
leastconn | http/tcp | 當前連接數最少 | 否 | 否 | 長連接/數據庫/SSH | 動態權重 |
first | http/tcp | 按服務器順序填滿 | 否 | 否 | 短連接批處理任務 | 先滿后用 |
source | http/tcp | 客戶端源 IP 哈希 | 是 | 是 | 會話保持、內網 NAT 出口 | 需 hash-type consistent |
uri | http | 完整 URI 哈希(路徑+參數) | 是 | 是 | CDN、緩存、靜態資源 | 需 hash-type consistent |
url_param <name> | http | 指定查詢參數值哈希 | 是 | 是 | API 分流、AB 測試 | 需 hash-type consistent |
hdr(<name>) | http | 指定請求頭值哈希 | 是 | 是 | 按 User-Agent、Token、Region 分流 | 需 hash-type consistent |