上一篇文章我們簡單講解了有關haproxy的安裝與搭建，在這篇文章我們把haproxy配置檔案中使用到的關鍵詞一一介紹下。
<b>關注我微信ilanniweb</b>
<a href="http://s3.51cto.com/wyfs02/M01/71/CC/wKiom1XYTlWRc4yQAADlHUPQiPc408.jpg"></a>
<b>1</b><b>、關鍵詞balance</b>
balance用于定義負載均衡的算法，可用于defaults、listen和backend中。
balance使用方法如下：
balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
<algorithm>用于在負載均衡場景中挑選一個server，其僅應用于持久資訊不可用的條件下或需要将一個連接配接重新派發至另一個伺服器時。
balance支援的算法有：
roundrobin：基于權重進行輪詢，在伺服器的處理時間保持均勻分布時，這是最平衡、最公平的算法。此算法是動态的，這表示其權重可以在運作時進行調整。不過在設計上，每個後端伺服器僅能最多接受4128個連接配接。
source：将請求的源位址進行hash運算，并由後端伺服器的權重總數相除後派發至某比對的伺服器。這可以使得同一個用戶端IP的請求始終被派發至某特定的伺服器；不過，當伺服器權重總數發生變化時，如某伺服器當機或添加了新的伺服器，許多用戶端的請求可能會被派發至與此前請求不同的伺服器；常用于負載均衡無cookie功能的基于TCP的協定；其預設為靜态，不過也可以使用hash-type修改此特性。
static-rr：基于權重進行輪詢，與roundrobin類似，但是為靜态方法，在運作時調整其伺服器權重不會生效；不過，其在後端伺服器連接配接數上沒有限制。
leastconn：新的連接配接請求被派發至具有最少連接配接數目的後端伺服器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其并不太适用于較短會話的應用層協定，如HTTP；此算法是動态的，可以在運作時調整其權重。
uri：對URI的左半部分(“問題”标記之前的部分)或整個URI進行hash運算，并由伺服器的總權重相除後派發至某比對的伺服器；這可以使得對同一個URI的請求總是被派發至某特定的伺服器，除非伺服器的權重總數發生了變化；此算法常用于代理緩存或反病毒代理以提高緩存的命中率；需要注意的是，此算法僅應用于HTTP後端伺服器場景；其預設為靜态算法，不過也可以使用hash-type修改此特性。
url_param：通過<argument>為URL指定的參數在每個HTTP GET請求中将會被檢索；如果找到了指定的參數且其通過等于号“=”被賦予了一個值，那麼此值将被執行hash運算并被伺服器的總權重相除後派發至某比對的伺服器；此算法可以通過追蹤請求中的使用者辨別進而確定同一個使用者ID的請求将被送往同一個特定的伺服器，除非伺服器的總權重發生了變化；如果某請求中沒有出現指定的參數或其沒有有效值，則使用輪叫算法對相應請求進行排程；此算法預設為靜态的，不過其也可以使用hash-type修改此特性。
hdr(<name>)：對于每個HTTP請求，通過<name>指定的HTTP首部将會被檢索；如果相應的首部沒有出現或其沒有有效值，則使用輪叫算法對相應請求進行排程；其有一個可選選項“use_domain_only”，可在指定檢索類似Host類的首部時僅計算域名部分(比如通過www.ilanni.com來說，僅計算ilanni詞符串的hash值)以降低hash算法的運算量；此算法預設為靜态的，不過其也可以使用hash-type修改此特性；
<b>2</b><b>、關鍵詞bind</b>
bind僅能用于frontend和listen區段，用于定義一個或幾個監聽的套接詞。
bind使用方法如下：
bind [<address>]:<port_range> [, ...]
bind [<address>]:<port_range> [, ...] interface <interface>
<address>：可選選項，其可以為主機名、IPv4位址、IPv6位址或*。省略此選項、将其指定為*或0.0.0.0時，将監聽目前系統的所有IPv4位址。
<port_range>：可以是一個特定的TCP端口，也可是一個端口範圍(如5005-5010)，代理伺服器将通過指定的端口來接收用戶端請求。
需要注意的是，每組監聽的套接詞<address:port>在同一個執行個體上隻能使用一次，而且小于1024的端口需要有特定權限的使用者才能使用，這可能需要通過uid參數來定義。
<interface>：指定實體接口的名稱，僅能在Linux系統上使用。其不能使用接口别名，而僅能使用實體接口名稱，而且隻有管理有權限指定綁定的實體接口。
<b>3</b><b>、關鍵詞mode</b>
mode用于設定執行個體的運作模式或協定。當實作内容交換時，前端和後端必須工作于同一種模式(一般說來都是HTTP模式)，否則将無法啟動執行個體。
mode可被用與listen、defaults、frontend、backend區段。
mode使用方法如下：
mode { tcp|http|health }
tcp：執行個體運作于純TCP模式（即4層），在用戶端和伺服器端之間将建立一個全雙工的連接配接，且不會對7層封包做任何類型的檢查；此為預設模式，通常用于SSL、SSH、SMTP等應用。
http：執行個體運作于HTTP模式（即7層），用戶端請求在轉發至後端伺服器之前将被深度分析，所有不與RFC格式相容的請求都會被拒絕。
health：執行個體工作于health模式，其對入站請求僅響應“OK”資訊并關閉連接配接，且不會記錄任何日志資訊；此模式将用于響應外部元件的健康狀态檢查請求；目前此模式已經廢棄，因為tcp或http模式中的monitor關鍵詞可完成類似功能；
<b>4</b><b>、關鍵詞hash-type</b>
hash-type定義用于将hash碼映射至後端伺服器的方法；其不能用于frontend區段；可用方法有map-based和consistent，在大多數場景下推薦使用預設的map-based方法。
hash-type使用方法如下：
hash-type <method>
map-based：hash表是一個包含了所有線上伺服器的靜态數組。其hash值将會非常平滑，會将權重考慮在列，但其為靜态方法，對線上伺服器的權重進行調整将不會生效，這意味着其不支援慢速啟動。此外，挑選伺服器是根據其在數組中的位置進行的，是以，當一台伺服器當機或添加了一台新的伺服器時，大多數連接配接将會被重新派發至一個與此前不同的伺服器上，對于緩存伺服器的工作場景來說，此方法不甚适用。
consistent：hash表是一個由各伺服器填充而成的樹狀結構；基于hash鍵在hash樹中查找相應的伺服器時，最近的伺服器将被選中。此方法是動态的，支援在運作時修改伺服器權重，是以相容慢速啟動的特性。添加一個新的伺服器時，僅會對一小部分請求産生影響，是以，尤其适用于後端伺服器為cache的場景。不過，此算法不甚平滑，派發至各伺服器的請求未必能達到理想的均衡效果，是以，可能需要不時的調整伺服器的權重以獲得更好的均衡性。
<b>5</b><b>、關鍵詞log</b>
log為每個執行個體啟用事件和流量日志，是以可用于所有區段。每個執行個體最多可以指定兩個log參數，不過，如果使用了“log global”且"global"段已經定了兩個log參數時，多餘了log參數将被忽略。
log global
log <address> <facility> [<level> [<minlevel>]]
global：目前執行個體的日志系統參數同"global"段中的定義時，将使用此格式；每個執行個體僅能定義一次“log global”語句，且其沒有任何額外參數。
<address>：定義日志發往的位置，其格式之一可以為<IPv4_address:PORT>，其中的port為UDP協定端口，預設為514；格式之二為Unix套接詞檔案路徑，但需要留心chroot應用及使用者的讀寫權限。
<facility>：可以為syslog系統的标準facility之一。
<level>：定義日志級别，即輸出資訊過濾器，預設為所有資訊；指定級别時，所有等于或高于此級别的日志資訊将會被發送。
<b>6</b><b>、關鍵詞maxconn</b>
maxconn設定一個前端的最大并發連接配接數，是以，其不能用于backend區段。
maxconn使用方法如下：
maxconn <conns>
對于大型站點來說，可以盡可能提高此值以便讓haproxy管理連接配接隊列，進而避免無法應答使用者請求。當然，此最大值不能超出“global”段中的定義。此外，需要留心的是，haproxy會為每個連接配接維持兩個緩沖，每個緩沖的大小為8KB，再加上其它的資料，每個連接配接将大約占用17KB的RAM空間。這意味着經過适當優化後，有着1GB的可用RAM空間時将能維護40000-50000并發連接配接。
如果為<conns>指定了一個過大值，極端場景下，其最終占據的空間可能會超出目前主機的可用記憶體，這可能會帶來意想不到的結果；是以，将其設定了一個可接受值方為明智決定。其預設為2000。
<b>7</b><b>、關鍵詞default_backend</b>
default_backend定義在沒有比對的use_backend規則時為執行個體指定使用的預設後端伺服器，是以，其不可應用于backend區段。在frontend和backend之間進行内容交換時，通常使用use-backend定義其比對規則；而沒有被規則比對到的請求将由此參數指定的後端伺服器接收。
default_backend使用方法如下：
default_backend <backend>
<backend>：指定使用的後端的名稱。
使用案例：
use_backend dynamic if url_dyn
use_backend static if url_css url_img
default_backend dynamic
<b>8</b><b>、關鍵詞server</b>
server為後端聲明一個server，是以，不能用于defaults和frontend區段。
server使用方法如下：
server <name> <address>[:port] [param*]
<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 <maxconn>：指定此伺服器接受的最大并發連接配接數；如果發往此伺服器的連接配接數目高于此處指定的值，其将被放置于請求隊列，以等待其它連接配接被釋放；
maxqueue <maxqueue>：設定請求隊列的最大長度；
observe <mode>：通過觀察伺服器的通信狀況來判定其健康狀态，預設為禁用，其支援的類型有“layer4”和“layer7”，“layer7”僅能用于http代理場景；
一個标準的使用案例，如下：
server web1 192.168.5.171:8080 maxconn 1024 weight 3 check inter 2000 rise 2 fall 3
以上就是[param*]中比較經常使用的參數。
redir <prefix>：啟用重定向功能，将發往此伺服器的GET和HEAD請求均以302狀态碼響應；需要注意的是，在prefix後面不能使用/，且不能使用相對位址，以免造成循環；例如：
server srv1 192.168.5.174:80 redir http://imags.ilanni.com check
weight <weight>：權重，預設為1，最大值為256，0表示不參與負載均衡。
檢查方法：
option httpchk
option httpchk <uri>
option httpchk <method> <uri>
option httpchk <method> <uri> <version>：不能用于frontend段
例如：
backend https_relay
mode tcp
option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.ilanni.com
server apache1 192.168.1.1:443 check port 80
<b>9</b><b>、關鍵詞stats enable</b>
stats enable啟用基于程式編譯時預設設定的統計報告，stats enable不能用于frontend區段。隻要沒有另外的其它設定，它們就會使用如下的配置：
stats uri : /stats
stats realm : "HAProxy Statistics"
stats auth : no authentication
stats scope : no restriction
盡管stats enable一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于預設設定而帶來非期望的後果。下面是一個配置案例。
backend public_www
server websrv1 192.168.5.171:80
stats enable
stats hide-version
stats scope
stats uri /stats
stats realm Haproxy\ Statistics
stats auth admin:password
<b>10</b><b>、關鍵詞stats hide-version</b>
stats hide-version隐藏統計報告中haproxy版本号，不能用于frontend區段。預設情況下，統計頁面會顯示一些有用資訊，包括haproxy的版本号。
然而，向所有人公開haproxy的精确版本号是非常有風險的，因為它能幫助惡意使用者快速定位版本的缺陷和漏洞。
<b>11</b><b>、關鍵詞stats realm</b>
stats realm啟用統計報告并高精認證領域，不能用于“frontend”區段。
stats realm <realm>
haproxy在讀取realm時會将其視作一個單詞，是以，中間的任何空白詞符都必須使用反斜線進行轉義。此參數僅在與“stats auth”配置使用時有意義。
<realm>：實作HTTP基本認證時顯示在浏覽器中的領域名稱，用于提示使用者輸入一個使用者名和密碼。
<b>12</b><b>、關鍵詞stats scope</b>
stats scope啟用統計報告并限定報告的區段，不能用于frontend區段。
當指定此語句時，統計報告将僅顯示其列舉出區段的報告資訊，所有其它區段的資訊将被隐藏。如果需要顯示多個區段的統計報告，此語句可以定義多次。需要注意的是，區段名稱檢測僅僅是以詞符串比較的方式進行，它不會真檢測指定的區段是否真正存在。
stats scope { <name> | "." }
<name>：可以是一個listen、frontend或backend區段的名稱，而“.”則表示stats scope語句所定義的目前區段。
<b>13</b><b>、關鍵詞stats auth</b>
stats auth啟用帶認證的統計報告功能并授權一個使用者帳号，其不能用于frontend區段。
stats auth <user>:<passwd>
<user>：授權進行通路的使用者名；
<passwd>：此使用者的通路密碼，明文格式；
此語句将基于預設設定啟用統計報告功能，并僅允許其定義的使用者通路，其也可以定義多次以授權多個使用者帳号。可以結合“stats realm”參數在提示使用者認證時給出一個領域說明資訊。在使用非法使用者通路統計功能時，其将會響應一個“401 Forbidden”頁面。其認證方式為HTTP Basic認證，密碼傳輸會以明文方式進行，是以，配置檔案中也使用明文方式存儲以說明其非保密資訊故此不能相同于其它關鍵性帳号的密碼。
<b>14</b><b>、關鍵詞stats admin</b>
stats admin在指定的條件滿足時啟用統計報告頁面的管理級别功能，它允許通過web接口啟用或禁用伺服器，不過，基于安全的角度考慮，統計報告頁面應該盡可能為隻讀的。此外，如果啟用了HAProxy的多程序模式，啟用此管理級别将有可能導緻異常行為。
stats admin { if | unless } <cond>
目前來說，POST請求方法被限制于僅能使用緩沖區減去保留部分之外的空間，是以，伺服器清單不能過長，否則，此請求将無法正常工作。是以，建議一次僅調整少數幾個伺服器。下面是兩個案例，第一個限制了僅能在本機打開報告頁面時啟用管理級别功能，第二個定義了僅允許通過認證的使用者使用管理級别功能。
backend stats_localhost
stats admin if LOCALHOST
backend stats_auth
stats admin if TRUE
<b>15</b><b>、關鍵詞option httplog</b>
option httplog啟用記錄HTTP請求、會話狀态和計時器的功能。
option httplog [ clf ]
clf：使用CLF格式來代替HAProxy預設的HTTP格式，通常在使用僅支援CLF格式的特定日志分析器時才需要使用此格式。
預設情況下，日志輸入格式非常簡陋，因為其僅包括源位址、目标位址和執行個體名稱，而“option httplog”參數将會使得日志格式變得豐富許多，其通常包括但不限于HTTP請求、連接配接計時器、會話狀态、連接配接數、捕獲的首部及cookie、“frontend”、“backend”及伺服器名稱，當然也包括源位址和端口号等。
<b>16</b><b>、關鍵詞option logasap</b>
option logasap
啟用提前将HTTP請求記入日志，不能用于backend區段。
預設情況下，HTTP請求是在請求結束時進行記錄以便能将其整體傳輸時長和詞節數記入日志，由此，傳較大的對象時，其記入日志的時長可能會略有延遲。option logasap參數能夠在伺服器發送complete首部時即時記錄日志，隻不過，此時将不記錄整體傳輸時長和詞節數。此情形下，捕獲Content-Length響應首部來記錄傳輸的詞節數是一個較好選擇。下面是一個例子。
listen http_proxy 0.0.0.0:80
mode http
option httplog
log 172.16.100.9 local2
<b>17</b><b>、關鍵詞option forwardfor</b>
option forwardfor允許在發往伺服器的請求首部中插入“X-Forwarded-For”首部。即啟用擷取用戶端真實IP功能。
option forwardfor [ except <network> ] [ header <name> ] [ if-none ]
<network>：可選參數，當指定時，源位址為比對至此網絡中的請求都禁用此功能。
<name>：可選參數，可使用一個自定義的首部，如“X-Client”來替代“X-Forwarded-For”。有些獨特的web伺服器的确需要用于一個獨特的首部。
if-none：僅在此首部不存在時才将其添加至請求封包問道中。
haproxy工作于反向代理模式，其發往伺服器的請求中的用戶端IP均為haproxy主機的位址而非真正用戶端的位址，這會使得伺服器端的日志資訊記錄不了真正的請求來源，“X-Forwarded-For”首部則可用于解決此問題。haproxy可以向每個發往伺服器的請求上添加此首部，并以用戶端IP為其value。
需要注意的是，haproxy工作于隧道模式，其僅檢查每一個連接配接的第一個請求，是以，僅第一個請求封包被附加此首部。如果想為每一個請求都附加此首部，請確定同時使用了“option httpclose”、“option forceclose”和“option http-server-close”幾個option。
下面是一個例子。
frontend www
option forwardfor except 127.0.0.1
<b>18</b><b>、關鍵詞errorfile</b>
errorfile在使用者請求不存在的頁面時，傳回一個頁面檔案給用戶端而非由haproxy生成的錯誤代碼；可用于所有段中。
errorfile <code> <file>
<code>：指定對HTTP的哪些狀态碼傳回指定的頁面；這裡可用的狀态碼有200、400、403、408、500、502、503和504。
<file>：指定用于響應的頁面檔案。
errorfile 400 /etc/haproxy/errorpages/400badreq.http
errorfile 403 /etc/haproxy/errorpages/403forbid.http
errorfile 503 /etc/haproxy/errorpages/503sorry.http
<b>19</b><b>、關鍵詞errorloc和errorloc302</b>
errorloc <code> <url>
errorloc302 <code> <url>
請求錯誤時，傳回一個HTTP重定向至某URL的資訊；可用于所有配置段中。
<code>：指定對HTTP的哪些狀态碼傳回指定的頁面；這裡可用的狀态碼有200、400、403、408、500、502、503和504；
<url>：Location首部中指定的頁面位置的具體路徑，可以是在目前伺服器上的頁面的相對路徑，也可以使用絕對路徑；需要注意的是，如果URI自身錯誤時産生某特定狀态碼資訊的話，有可能會導緻循環定向；
需要留意的是，這兩個關鍵詞都會傳回302狀态嗎，這将使得用戶端使用同樣的HTTP方法擷取指定的URL，對于非GET法的場景(如POST)來說會産生問題，因為傳回客戶的URL是不允許使用GET以外的其它方法的。如果的确有這種問題，可以使用errorloc303來傳回303狀态碼給用戶端。
<b>20</b><b>、關鍵詞errorloc303</b>
errorloc303 <code> <url>
請求錯誤時，傳回一個HTTP重定向至某URL的資訊給用戶端，可用于所有配置段中。
<code>：指定對HTTP的哪些狀态碼傳回指定的頁面；這裡可用的狀态碼有400、403、408、500、502、503和504；
backend webserver
server 172.16.100.6 172.16.100.6:80 check maxconn 3000 cookie srv01
server 172.16.100.7 172.16.100.7:80 check maxconn 3000 cookie srv02
errorloc 403 /etc/haproxy/errorpages/sorry.htm
errorloc 503 /etc/haproxy/errorpages/sorry.htm
本文轉自 爛泥行天下 51CTO部落格，原文連結：http://blog.51cto.com/ilanni/1687145
![查找算法之二分查找查找算法之二分查找[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)