一、haproyx簡介
HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的併發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中，同時可以保護你的web服務器不被暴露到網絡上。
HAProxy實現了一種事件驅動、單一進程模型，此模型支持非常大的併發連接數。多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，很少能處理數千併發連接。事件驅動模型因爲在有更好的資源和時間管理的用戶端(User-Space)實現所有這些任務，所以沒有這些問題。此模型的弊端是，在多核系統上，這些程序通常擴展性較差。這就是爲什麼他們必須進行優化以 使每個CPU時間片(Cycle)做更多的工作。
HAProxy是免費、極速且可靠的用於爲TCP和基於HTTP應用程序提供高可用、負載均衡和代理服務的解決方案，尤其適用於高負載且需要持久連接或7層處理機制的web站點。
二、haproxy工作位置
三、haproxy安裝及配置文件詳解
3.1 安裝haproxy
在CentOS 6.6 系統中HAProxy已經被收錄在安裝樹中了，在配置好yum源之後直接使用yum install haproxy就能實現安裝。
yum install haproxy -y
3.2 haproxy配置文件詳解
在安裝完haproxy程序之後使用rpm-ql haproxy查看安裝完所生成的文件，生成的文件比較的少，haproxy的配置文件在/etc/haproxy/haproxy.cfg。
[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg global #全局配置 log 127.0.0.1 local2 #日誌文件存放路徑，指明爲syslog服務器，最多可以定義兩個 chroot /var/lib/haproxy #haproxy的工作目錄 pidfile /var/run/haproxy.pid #pid文件存放位置 maxconn 4000 #設定每個haproxy進程所接受的最大併發連接數，其等同於命令行選項“-n”；“ulimit -n”自動計算的結果正是參照此參數設定的； user haproxy #指定haproxy身份運行haproxy程序 group haproxy #指定haproxy組身份運行haproxy程序 daemon #讓haproxy以守護進程的方式工作於後臺，其等同於“-D”選項的功能，當然，也可以在命令行中以“-db”選項將其禁用； stats socket /var/lib/haproxy/stats #指明haproxy運行時socket文件存放位置 defaults #提供frontend、backend、listen的公共配置信息段 mode http #haproxy的工作模式，有tcp和http log global #日誌文件從global承繼 option httplog #啓動記錄http請求、會話狀態和計時器的功能 option dontlognull #不記錄空日誌 option http-server-close #啓動和禁用服務器端關閉HTTP連接的功能，服務器連接關閉功能主要是在長連接上使用； option forwardfor except127.0.0.0/8 #允許在發往服務器的請求首部中插入“X-Forwarded-For”首部 option redispatch #開啓或禁用如果某一個連接發生了錯誤是不是需要重啓調度； retries 3 #重次次數 timeout http-request 10s #等待客戶端發送報文超時時長 timeout queue 1m #連接隊列等待的超時時長 timeout connect 10s #等待上游服務器響應haproxy發送報文過程的超時時間 timeout client 1m timeout server 1m timeout http-keep-alive 10s #設置保護連接的超時時間 timeout check 10s #設置健康狀態額外的超時時間 maxconn 3000 #設定一個前端的最大併發連接數，因此，其不能用於backend區段。 frontend main *:5000 #用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之建立連接。 acl url_static path_beg -i /static /images /javascript/stylesheets #定義一個ACL規則 acl url_static path_end -i .jpg .gif .png .css .js use_backend static ifurl_static #匹配ACL規則的將會使用“static”的後端服務器 default_backend app #在沒有匹配的"use_backend"規則時爲實例指定使用的默認後端 backend static #用於定義一系列“後端”服務器，代理將會將對應客戶端的請求轉發至這些服務器。 balance roundrobin #定義負載均衡調度算法 server static 127.0.0.1:4331check #爲後端聲明一個server，因此，不能用於defaults和frontend區段。“check”表示做健康狀態檢查 backend app balance roundrobin server app1 127.0.0.1:5001 check server app2 127.0.0.1:5002 check server app3 127.0.0.1:5003 check server app4 127.0.0.1:5004 check
3.3 負載均衡調度算法
| 類型 | 說明 |
| roundrobin | 基於權重進行輪叫，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重可以在運行時進行調整，不過，在設計上，每個後端服務器僅能最多接受4128個連接； |
static-rr | 基於權重進行輪叫，與roundrobin類似，但是爲靜態方法，在運行時調整其服務器權重不會生效；不過，其在後端服務器連接數上沒有限制； |
leastconn | 新的連接請求被派發至具有最少連接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，可以在運行時調整其權重； |
source | 將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器；這可以使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不同的服務器；常用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可以使用hash-type修改此特性； |
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.magedu.com來說，僅計算magedu字符串的hash值)以降低hash算法的運算量；此算法默認爲靜態的，不過其也可以使用hash-type修改此特性； |
四、haproxy配置實踐之啓動haproxy狀態統計報告頁面
4.1 啓動haproxy狀態統計報告
haproxy的狀態統計報告的功能非常的強大，可以標記後端服務器不可用，因此應該監聽在一個內網地址的特定端口上，在訪問此頁面時要進行認證，認證成功才能訪問。
在haproxy.cfg配置文件中添加如下內容：
listen stats mode http bind 172.16.9.84:7009 stats enable stats hide-version stats uri /haproxyadmin?stats stats realm HAProxy\Statistics stats auth admin:admin stats admin if TRUE
4.2 解釋狀態統計報告段配置信息
listen stats
modehttp
bind172.16.9.84:7009 #監聽在指定的套接字上
statsenable #開啓狀態統計報告
statshide-version #隱藏狀態統計報告中的haproxy版本信息
statsuri /haproxyadmin?stats #指定狀態統計報告的訪問URI地址
statsrealm HAProxy\ Statistics #認證時的提示信息，空格要使用“\”進行轉意
statsauth admin:admin #認證時的用戶名：密碼
statsadmin if TRUE #在指定的條件滿足時啓用統計報告頁面的管理級別功能，它允許通過web接口啓用或禁用服務器，不過，基於安全的角度考慮，統計報告頁面應該儘可能爲只讀的。
4.3 啓動haproxy
[root@node-04 ~]# service haproxy start Starting haproxy: [ OK ]
4.4 檢查監聽端口
[root@node-04 ~]# ss -tanp|grep 7009
LISTEN 0 128 172.16.9.84:7009 *:* users:(("haproxy",1465,7))4.5 訪問測試
在瀏覽器中輸入http://172.16.9.84:7009/haproxyadmin?stats進行訪問，在認證成功後的頁面如下
五、haproxy配置實踐之負載均衡Web服務
用戶請求haproxy反向代理服務器，實現負載均衡的效果，你也可以根據上面的調度算法根據業務的需求進行調整，實驗拓撲；
5.1 haproxy節點的配置內容
[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 frontend main *:80 default_backend websrvs listen stats modehttp bind172.16.9.84:7009 statsenable statshide-version statsuri /haproxyadmin?stats statsrealm HAProxy\ Statistics statsauth admin:admin statsadmin if TRUE backend websrvs balance roundrobin server web1 172.16.9.81:8080check server web2 172.16.9.83:8080check
5.2 各Web節點的測試頁面的內容
Web節點監聽在8080的端口上，如節點的測試頁面如下:
Web-01節點測試頁面：
<h1>Real Server node-01</h1>
Web-02節點測試頁面：
<h1>Real Server node-02</h1>
5.3 重新加載haproxy的配置信息
service haproxy reload
5.4 訪問測試
在瀏覽器http://172.16.9.84中訪問或使用curl命令進行測試，將會出現輪詢的效果
[root@node-04 haproxy]# curlhttp://172.16.9.84 <h1>Real Server node-01</h1> [root@node-04 haproxy]# curlhttp://172.16.9.84 <h1>Real Server node-02</h1>
六、haproxy配置實踐之基本Cookie綁定會話
在上面的配置中實現的在訪問Web服務器時能輪詢的訪問後端服務器，但在特定的場景中有時需要將用戶的會話保持至同一臺後端服務器時，就可以使用基本Cookie的會話綁定。
cookie爲當客戶端第一次訪問服務器時，服務器生成一個隨機的cookie，爲此用戶會話使用，用戶瀏覽器收到cookie信息以後，將會保存在自己瀏覽器緩存中，而後在向同一個站點請求任何資源時都會附加會話標識信息。
haproxy的cookie參數，是用於客戶端在後端的upstream服務器端之間通信時，如果upstream 設置了cookie給客戶端的話，haproxy是將會修改、添加在原有cookie的基礎上附加一些信息上去，以實現基本haproxy來追蹤客戶端的通信信息
6.1 修改haproxy.cfg文件中backned段的代碼
backend websrvs balance roundrobin cookie WEBID insert indirect nocache server web1 172.16.9.81:8080check cookie web1 server web2 172.16.9.83:8080check cookie web2
6.2 配置信息解釋
cookie WEBID insert indirect nocache
啓用基於cookie後端服務器黏性的功能，insert表示內插方式去將當前haproxy調度出來的WEBID信息插入到客戶端的cookie信息中去，並通知不要緩存用戶的敏感信息。
如果用戶請求時第一次被調度至web1服務器，web1會回一個cookie信息給客戶端，haproxy會把web1這個服務器自己的WEBID附加在cookie上，當客戶端第二次請求發出web資源請求時，haproxy通過分析就知道此前就是由web1這臺服務器響應的，所以haproxy就把此請求定向至web1。這樣haproxy就能追蹤此前每一個server作出的響應。
6.3 訪問測試
在瀏覽器中按F12打開開發人員工具，進行查看Cookie的信息，在瀏覽器輸入http://172.16.9.84/，當再次刷新時就被定位至同一臺RealServer了，查看Cookie信息中包含了在HAProxy插入的WEBID=XX的HTTP首部請求信息。
Cookie:pma_lang=zh_CN;pma_collation_connection=utf8_general_ci; pma_mcrypt_iv=fmN5yE3kUyc%3D;WEBID=web1
七、haproxy配置實踐之動靜分離
當客戶端請求靜態資源時haproxy將輪詢的把用戶的請求調度至後端服務器，請求的動態資源將調度至Web-02服務器上。
7.1 實驗拓撲
7.2 haproxy的配置信息
[root@node-04 haproxy]# egrep -v"#|^$" haproxy.cfg global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 frontend main *:80 acl url_dy path_end -i .php #ACL規則，以.php結尾的URL將會被匹配 use_backend dy if url_dy #匹配成功的將會調用“dy”後端服務器組 default_backend websrvs listen stats modehttp bind172.16.9.84:7009 statsenable statshide-version statsuri /haproxyadmin?stats statsrealm HAProxy\ Statistics statsauth admin:admin statsadmin if TRUE backend dy balance roundrobin server static172.16.9.83:8080 check backend websrvs balance roundrobin server web1 172.16.9.81:8080check server web2 172.16.9.83:8080check
7.3 後端服務器節點http頁面內容
web-01節點的內容
[root@node-01 html]# cat index.htmlindex.php <h1>Html Static Web-01</h1> <h1>Real Server node-01</h1>
web-02節點的內容
[root@node-03 html]# cat index.htmlindex.php <h1>Html Static Web-02</h1> <h1>Real Server node-02</h1>
7.4 重新加載haproxy配置文件
service haproxy reload
7.5 訪問測試
使用curl命令訪問測試，靜態資源的訪問，將會出現輪詢的效果：
[root@node-04 ~]# curl http://172.16.9.84/index.html <h1>Html Static Web-01</h1> [root@node-04 ~]# curlhttp://172.16.9.84/index.html <h1>Html Static Web-02</h1>
使用curl命令訪問測試，動態資源的訪問，將會始終調度至同一臺後端服務器的效果：
[root@node-04 ~]# curlhttp://172.16.9.84/index.php <h1>Real Server node-02</h1> [root@node-04 ~]# curl http://172.16.9.84/index.php <h1>Real Server node-02</h1>
小結：
haproxy的功能還遠遠不至上面列出的這些，更詳細的內容請參考官方文檔。
haproxy的連接數是受套接字數量的限制，所以併發數量有限，在haproxy的前端可以加一個LVS，在LVS後一個haproxy的集羣，通過LVS調度至不同的haproxy服務器上，以實現高併發的場景。