配置文件整體結構
global-->defaults-->listen/frontend/backend
| global | 全局配置，進程級配置，通常和操作系統配置有關 |
| defaults | 默認引用到f/b/l中，若在f/b/l中有相同參數配置，defaults相同參數配置會被覆蓋 |
| listen | 1.3版本後就簡單的設置個status查看頁面 |
| frontend | 前端虛擬節點，vip |
| backend | 後端服務器集羣，rip |
重要參數詳解
global
| log 127.0.0.1 local0 info | 全局日誌配置，local0是日誌設備，info表示日誌級別（err、warning、info、debug 4中可選）。這個配置表示：使用127.0.0.1的rsyslog服務中的local0日誌設備，記錄日誌等級爲info。 vim /etc/rsyslog.cfg $ModLoad imudp $UDPServerRun 514 local0.* /var/log/haproxy.log vim/etc/sysconfig/rsyslog SYSLOGD_OPTIONS="-r -m 0 -c 2" /etc/init.d/rsyslogrestart | ||||
chroot /usr/share/haproxy | 修改haproxy的工作目錄至指定的目錄並在放棄權限之前執行chroot()操作，可以提升haproxy的安全級別，不過需要注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限。 | ||||
user haproxy group haproxy | 設置運行Haproxy進程的用戶和組，也可使用uid/gid代替。 | ||||
daemon | 設置Haproxy進程後臺運行，默認運行模式。 | ||||
nbproc 2 | 設置Haproxy啓動時可創建的進程數，此參數要求必須將Haproxy運行模式設置爲daemon模式，默認情況下只啓動一個進程。一般只在單進程僅能打開少數文件描述符的場景中才使用多進程模式！！使用多進程時建議小於cpu核心數，如：有兩顆6核cpu，就<=2*6。創建多個進程，可減少每個進程的任務隊列，但是過多的進程可能會導致進程崩潰。 | ||||
pidfile /var/run/haproxy.pid | 指定Haproxy進程的pid文件。啓動進程的用戶，必須有訪問此文件的權限！！ | ||||
defaults
mode http | 設置Haproxy實例默認的運行模式（tcp、http、health三種模式可選） tcp模式：在此模式下客戶端和服務器端之間將建立一個全雙工的連接，不會對7層報文做任何類型的檢查，默認爲tcp模式，經常用於ssl、ssh、smtp等應用。 http模式：在此模式下，客戶端請求在轉發至後端服務器之前會被深度分析，所有不與RFC格式兼容的請求都會被拒絕。 health模式：此模式基本已廢。 |
option httplog | 啓用日誌記錄http詳細請求，可以由此看到client請求的是backend的哪個rs，默認是不記錄的。 |
| option httpclose | disable keep-alive |
| option abortonclose | 當服務器負載很高的時候，自動結束掉當前隊列處理時間比較長的連接 |
option dontlognull | 啓用該項，日誌中將不會記錄空連接，所謂空連接就是在上游的負載均衡或者監控系統爲了探測該服務是否存活可用時需要定期的連接或者獲取某一固定的組件或頁面，或者探測掃描端口是否監聽等動作被稱爲空連接。 官方提示：如果上游沒有其他負載均衡器的話，建議不要使用該參數。 |
retries3 | 設置連接後端服務器的失敗重試次數，如果連接失敗的次數超過這裏的設置值，Haproxy會將對應的後端服務器標記爲不可用，次參數也可在後面部分進行設置。 |
option redispatch | 當使用了cookie時，haproxy將會將請求的後端服務器的serverID插入到cookie中，以保證會話的session持久性，而此時，後端服務器宕機，但是客戶端的cookie不會刷新，設置此參數，將會將客戶請求強制定向到另外一個後端server上，以保證服務的正常。 |
timeout connect 5000 | 成功連接到一臺服務器的最長等待時間，默認單位爲ms，也可用其他時間單位代替。 |
timeout client 50000 | 連接客戶端發送數據時最長等待時間 |
timeout server 50000 | 服務器迴應客戶端數據發送的最長等待時間。 |
配置文件中的一些關鍵字詳解
| bind *：80 | 此指令僅能用於frontend和listen區段，用於定義一個或幾個監聽的套接字。 <address>：可選選項，其可以爲主機名、IPv4地址、IPv6地址或*；省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的所有IPv4地址；<port_range>：可以是一個特定的TCP端口，也可是一個端口範圍(如5005-5010)，代理服務器將通過指定的端口來接收客戶端請求；需要注意的是，每組監聽的套接字<address:port>在同一個實例上只能使用一次，而且小於1024的端口需要有特定權限的用戶才能使用，這可能需要通過uid參數來定義；<interface>：指定物理接口的名稱，僅能在Linux系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，而且只有管理有權限指定綁定的物理接口； |
| maxconn 2048 | 設定一個前端的最大併發連接數，因此，其不能用於backend區段。對於大型站點來說，可以儘可能提高此值以便讓haproxy管理連接隊列，從而避免無法應答用戶請求。當然，此最大值不能超出“global”段中的定義。此外，需要留心的是，haproxy會爲每個連接維持兩個緩衝，每個緩衝的大小爲8KB，再加上其它的數據，每個連接將大約佔用17KB的RAM空間。這意味着經過適當優化後，有着1GB的可用RAM空間時將能維護40000-50000併發連接。 如果爲<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用內存，這可能會帶來意想不到的結果；因此，將其設定了一個可接受值方爲明智決定。其默認爲2000。 |
| option forwardfor | HAProxy工作於反向代理模式，其發往服務器的請求中的客戶端IP均爲HAProxy主機的地址而非真正客戶端的地址，這會使得服務器端的日誌信息記錄不了真正的請求來源，“X-Forwarded-For”首部則可用於解決此問題。HAProxy可以向每個發往服務器的請求上添加此首部，並以客戶端IP爲其value。 |
| default_backend | 在沒有匹配的”use_backend”規則時爲實例指定使用的默認後端，因此，其不可應用於backend區段。在”frontend”和”backend”之間進行內容交換時，通常使用”use-backend”定義其匹配規則；而沒有被規則匹配到的請求將由此參數指定的後端接收。 <backend>：指定使用的後端的名稱； |
balance
--定義負載均衡算法，可用於“defaults”、“listen”和“backend”。用於在負載均衡場景中挑選一個server，其僅應用於持久信息不可用的條件下或需要將一個連接重新派發至另一個服務器時。
支持的算法有：
| roundrobin | 基於權重進行輪叫，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重可以在運行時進行調整，不過，在設計上，每個後端服務器僅能最多接受4128個連接；並支持慢啓動。 |
| static-rr | 基於權重進行輪叫，與roundrobin類似，但是爲靜態方法，在運行時調整其服務器權重不會生效；不過，其在後端服務器連接數上沒有限制；不支持慢啓動，在高負荷的情況下，服務器重新上線時會立即被分配大量連接。 |
| leastconn | 適用於長連接的會話，新的連接請求被派發至具有最少連接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的， 可以在運行時調整其權重； |
| source | 將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器；這可以使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不同的服務器；常用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可以使用hash-type修改此特性； |
server<name><address>[:port][param*]
--爲後端聲明一個server，因此，不能用於defaults和frontend區段。
| <name> | 爲此服務器指定的內部名稱，其將出現在日誌及警告信息中；如果設定了”http-send-server-name”，它還將被添加至發往此服務器的請求首部中； |
| <address> | 此服務器的的IPv4地址，也支持使用可解析的主機名，只不過在啓動時需要解析主機名至相應的IPv4地址； |
| [:port] | 指定將連接請求所發往的此服務器時的目標端口，其爲可選項；未設定時，將使用客戶端請求時的同一相端口； |
| [param*] | 爲此服務器設定的一系參數；其可用的參數非常多，具體請參考官方文檔中的說明，下面僅說明幾個常用的參數； 服務器或默認服務器參數： |
| -->backup | 設定爲備用服務器，僅在負載均衡場景中的其它server均不可用於啓用此server； |
| -->check | 啓動對此server執行健康狀態檢查，其可以藉助於額外的其它參數完成更精細的設定，如： |
| ---->inter<delay> | 設定健康狀態檢查的時間間隔，單位爲毫秒，默認爲2000；也可以使用fastinter和downinter來根據服務器端狀態優化此時間延遲； |
| ---->rise<count> | 設定健康狀態檢查中，某離線的server從離線狀態轉換至正常狀態需要成功檢查的次數； |
| ---->fall<count> | 確認server從正常狀態轉換爲不可用狀態需要檢查的次數； |
| -->cookie<value> | 爲指定server設定cookie值，此處指定的值將在請求入站時被檢查，第一次爲此值挑選的server將在後續的請求中被選中，其目的在於實現持久連接的功能； |
| -->maxconn<count> | 指定此服務器接受的最大併發連接數；如果發往此服務器的連接數目高於此處指定的值，其將被放置於請求隊列，以等待其它連接被釋放； haproxy 有n個進程，每個支持m個連接，後端有x個服務器，每個最大支持y個連接，則 n*m <= x*y，如果後端服務器支持排隊，則n*m <= x*（y+z），z爲每個服務器的排隊隊列 |
| -->maxqueue | 設定請求隊列的最大長度； |
| -->redir<prefix> | 啓用重定向功能，將發往此服務器的GET和HEAD請求均以302狀態碼響應；需要注意的是，在prefix後面不能使用/，且不能使用相對地址，以免造成循環 |
| -->weight<count> | 權重，默認爲1，最大值爲256，0表示不參與負載均衡（不被調度） |