共計 2615 個字符，預計需要花費 7 分鐘才能閱讀完成。

本篇內容主要講解“haproxy 怎么配置文件 backend”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“haproxy 怎么配置文件 backend”吧!

配置示例：

backend htmpool
 mode http
 option redispatch
 option abortonclose
 balance static-rr
 cookie SESSION_COOKIE insert indirect nocache
 option httpchk GET /index.jsp
 server 237server 192.168.81.237:8080 cookie server1 weight 6 check inter 2000 rise 2 fall 3
 server iivey234 192.168.81.234:8080 cookie server2 weight 3 check inter 2000 rise 2 fall 3

這個部分通過 backend 關鍵字定義了一個名為“htmpool”的后端真實服務器組。下面介紹每個選項的含義。

option redispatch：此參數用于 cookie 保持的環境中。在默認情況下，HAProxy 會將其請求的后端服務器的 serverID 插入到 cookie 中，以保證會話的 SESSION 持久性。而如果后端的服務器出現故障，客戶端的 cookie 是不會刷新的，這就出現了問題。此時，如果設置此參數，就會將客戶的請求強制定向到另外一個健康的后端服務器上，以保證服務的正常。

option abortonclose：如果設置了此參數，可以在服務器負載很高的情況下，自動結束掉當前隊列中處理時間比較長的鏈接。

balance：此關鍵字用來定義負載均衡算法。目前 HAProxy 支持多種負載均衡算法，常用的有如下幾種：

roundrobin：是基于權重進行輪詢調度的算法，在服務器的性能分布比較均勻的時候，這是一種最公平、最合理的算法。此算法經常使用。

static-rr：也是基于權重進行輪詢的調度算法，不過此算法為靜態方法，在運行時調整其服務器權重不會生效。

source：是基于請求源 IP 的算法。此算法先對請求的源 IP 進行 hash 運算，然后將結果與后端服務器的權重總數相除后轉發至某個匹配的后端服務器。這種方式可以使同一個客戶端 IP 的請求始終被轉發到某特定的后端服務器。

leastconn：此算法會將新的連接請求轉發到具有最少連接數目的后端服務器。在會話時間較長的場景中推薦使用此算法，例如數據庫負載均衡等。此算法不適合會話較短的環境中，例如基于 HTTP 的應用。

uri：此算法會對部分或整個 URI 進行 hash 運算，再經過與服務器的總權重相除，最后轉發到某臺匹配的后端服務器上。

uri_param : 此算法會根據 URL 路徑中的參數進行轉發，這樣可保證在后端真實服務器數量不變時，同一個用戶的請求始終分發到同一臺機器上。

hdr(name) : 此算法根據 http 頭進行轉發，如果指定的 http 頭名稱不存在，則使用 roundrobin 算法進行策略轉發。

cookie：表示允許向 cookie 插入 SESSION_COOKIE，每臺服務器的 SERVERID 可在下面的 server 關鍵字中使用 cookie 關鍵字定義。

option httpchk：此選項表示啟用 HTTP 的服務狀態檢測功能。HAProxy 作為一款專業的負載均衡器，它支持對 backend 部分指定的后端服務節點的健康檢查，以保證在后端 backend 中某個節點不能服務時，把從 frotend 端進來的客戶端請求分配至 backend 中其他健康節點上，從而保證整體服務的可用性。

“optionhttpchk”的用法如下：

option httpchk method uri version

其中，各個參數的含義如下：

method：表示 HTTP 請求的方式，常用的有 OPTIONS、GET、HEAD 幾種方式。一般的健康檢查可以采用 HEAD 方式進行，而不是才采用 GET 方式，這是因為 HEAD 方式沒有數據返回，僅檢查 Response 的 HEAD 是不是 200 狀態。因此相對與 GET 來說，HEAD 方式更快，更簡單。

uri：表示要檢測的 URL 地址，通過執行此 URL，可以獲取后端服務器的運行狀態。在正常情況下將返回狀態碼 200，返回其他狀態碼均為異常狀態。

version：指定心跳檢測時的 HTTP 的版本號。

server：這個關鍵字用來定義多個后端真實服務器，不能用于 defaults 和 frontend 部分。

使用格式為：

server name address [:port] [param*]

其中，每個參數含義如下：

name：為后端真實服務器指定一個內部名稱，隨便定義一個即可。

address：后端真實服務器的 IP 地址或主機名。

port：指定連接請求發往真實服務器時的目標端口。在未設定時，將使用客戶端請求時的同一端口。

[param*]：為后端服務器設定的一系參數，可用參數非常多，這里僅介紹常用的一些參數：

check：表示啟用對此后端服務器執行健康狀態檢查。

inter：設置健康狀態檢查的時間間隔，單位為毫秒。

rise：設置從故障狀態轉換至正常狀態需要成功檢查的次數，例如。“rise 2”表示 2 次檢查正確就認為此服務器可用。

fall：設置后端服務器從正常狀態轉換為不可用狀態需要檢查的次數，例如，“fall 3”表示 3 次檢查失敗就認為此服務器不可用。

cookie：為指定的后端服務器設定 cookie 值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的后端服務器將在后續的請求中一直被選中，其目的在于實現持久連接的功能。上面的“cookie server1”表示 web1 的 serverid 為 server1。同理，“cookie server2”表示 web2 的 serverid 為 server2。

weight：設置后端真實服務器的權重，默認為 1，最大值為 256。設置為 0 表示不參與負載均衡。

backup：設置后端真實服務器的備份服務器，僅僅在后端所有真實服務器均不可用的情況下才啟用。

到此，相信大家對“haproxy 怎么配置文件 backend”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！