haproxy是一個非常優秀的負載均衡工具，它的特性非常豐富，功能也非常非常強大，要想好好使用它，將它的功能和效能挖掘出來，多多閱讀官方手冊是必不可少的。

本文提供一個簡單的配置示例，後面將分別開文章詳細解釋它的配置檔案、cookie會話保持、stick table的功能、haproxy主主模型的複製(replication)、抵禦攻擊等等。

1. 配置haproxy需要考慮的事情

儘管haproxy大多數配置選項都可以採用預設配置，但有些選項，特別是關於實際需求、連線數和超時時間相關的選項必須獨立配置。

大致總結了下以下幾點需要考慮的問題：

1. haproxy支援5種http事務模型。一般只會選擇其中兩種：
   • (1).當後端為靜態web或靜態快取伺服器時，使用http-keep-alive
     模型，由於響應速度快，頻繁建立tcp連線的代價比較大；
   • (2).當後端為動態應用程式伺服器或者靜態但傳輸的資源物件體積較大時，使用http-server-close模型，因為響應速度相對較慢，佔用空閒連線的資源比建立tcp連線的代價更大。
2. haproxy反向代理的排程演算法優先順序是低於cookie的，因此當一個連線已經保持了會話，排程演算法對該連線就無效。只有新的連線請求或者長連線已經失效時，才會使用排程演算法進行排程。在排程演算法的選擇上，如果不考慮伺服器效能差距的話：
   • (1).如果後端會話時間比較長(mysql)，建議使用leastconn，因為排程過程中，後端釋放連線時動盪不大，比較穩定。
   • (2).如果後端是靜態web，建議使用roundrobin演算法。
   • (3).如果後端需要保持會話資訊，但又不使用cookie時，可以使用源地址hash演算法source，保證將同一客戶端引導到同一後端伺服器上。如果使用cookie，則可以使用roundrobin或leastconn演算法。源地址hash演算法，一般只在沒有辦法的時候但又要排程到同一後端伺服器時，才作為最後手段。
   • (4).如果配置了session共享，則對於haproxy來說，動態資源的請求是"無狀態"的，可以使用roundrobin演算法或leastconn。
   • (5).如果後端是快取伺服器，為了保證命中率，建議使用uri演算法，同時將hash-type設定為consistent方法(一致性hash)，保證後端快取伺服器down掉後對客戶端的影響足夠小。
3. haproxy是單程序、事件驅動模型的軟體，單程序下工作效率已經非常好，不建議開啟的多程序/多例項。
4. maxconn指令控制最大併發連線數，可以在多處設定，設定位置不同，代表意義不同：
   • (1).設定在global段或frontend/listen/defaults段的maxconn代表的是和客戶端(即frontend)的最大連線併發數；其中global段的值是硬限制，frontend/listen/defaults段的maxconn值不能超過global段的值。
   • (2).設定在server指令中時，代表的是haproxy和某臺後端伺服器維持的最大併發連線數。
   • (3).前端的最大併發數(即global段的maxconn)可以根據記憶體來估算，haproxy為每個連線維持兩個快取區，每個大致16K左右，加上一些額外資料，共約33-34K左右，因此理論上1G的空閒記憶體能維持2W-2.5W個純HTTP的併發連線(只是理論上)，如果代理的是https，則允許的最大併發數量要小的多。前端maxconn預設值為2000，非常有必要將其增加幾倍。一般代理純http服務時，如果後端能處理及時，這裡設定20000以上都不會有什麼問題。以上只是大致估算代理能力，實際設定時必須根據後端處理能力以及haproxy自身能力設定前端maxconn，否則將前端接進來後端也無法立即處理。
   • (4).後端所有伺服器的maxconn值之和應接近前端的maxconn值，計算兩者差距時，還需要考慮後端的等待佇列長度maxqueue。其中和靜態web伺服器的maxconn可以設定大一些。
5. 開啟haproxy和後端的連線重用功能。當某客戶端的請求到來後，haproxy和後端某伺服器建立一個TCP連線，並將請求排程到該伺服器上，該客戶端後續的請求也會通過該TCP連線轉發給後端(假設沒有采用關閉後端連線的http事務模型)。但在響應後和該客戶端的下一個請求到來前，這個連線是空閒的。和後端建立的TCP連線只是為了排程轉發，免去後續再次建立tcp連線的消耗。它完全可以為其它客戶端的請求排程也使用這個TCP連線，保證TCP連線資源不浪費。可以使用http-reuse strategy_name指令設定連線重用的策略，而預設策略禁用連線重用。
   • (1).never：這是預設設定。表示禁用連線重用，因為老版本的haproxy認為來源不同的請求不應該共享同一個後端連線。
   • (2).safe：這是建議使用的策略。"安全"策略下，haproxy為客戶端的每個第一個請求都單獨建立一個和後端的TCP連線，但是後續的請求則會重用和該後端的空閒TCP連線。這樣的轉發不僅提高了資源使用率，還保持了keep-alive的功能。因此，safe策略配合http-keep-alive事務模式比http-server-close事務模式更高效，無論後端是靜態、快取還是動態應用伺服器。
   • (3).aggressive：一種激進的策略，該策略的haproxy會重用空閒TCP連線來轉發大多數客戶端的第一次請求。之所以是大多數而不是所有，是因為haproxy會挑選那些已經被重用過至少一次的連線(即從建立開始轉發過至少兩次，不管源是否是同一客戶端)進行重用，因為haproxy認為只有這樣的連線才具有重用能力。
   • (4).always：它將總是為第一個請求重用空閒連線。當後端是快取伺服器時，這種策略比safe策略的效能要高許多，因為這樣的請求行為都是一樣的，且可以共享同一連線來獲取資源。不過不建議使用這種策略，因為大多數情況下，它和aggressive的效能是一樣的，但是卻帶來了很多風險。
     　
     因此，為了效能的提升，將它設定為safe或aggressive吧，同時再將http事務模型設定為http-keep-alive。
6. 對於haproxy是否開啟cookie以及stick table相關功能的設定必須嚴加考慮，它直接影響排程演算法的選擇和負載均衡的效能。不過如果後端應用程式伺服器共享了session，haproxy可以不用設定會話粘性相關的選項。
7. haproxy的預設配置檔案中關於超時時間的設定應該修改，不少項設定都很不合理。
8. 建議開啟haproxy的X-Forwarded-For選項，使得後端伺服器能夠記錄客戶端的真實源IP地址。
9. 建議開啟haproxy的狀態頁面，並設定訪問許可權。

為了實現Haproxy完善的功能，上面幾個問題是遠遠不夠的，但可以在邊使用haproxy過程中邊增加功能使其不斷完美。

2. 配置haproxy提供反向代理功能

假如要實現這樣的環境：haproxy反向代理4個nginx節點，nginx1和nginx2結合php提供動態web服務，nginx3和nginx4提供靜態web服務。如下圖：

由於預設配置檔案中和超時時間相關的設定比較不合理，所以建議修改這些時間。另外還有些建議開啟或關閉的的項也儘量開啟或關閉。

預設配置如下：

global
    log         127.0.0.1 local2      # 需要設定/etc/rsyslog.conf加上local2裝置的日誌記錄級別和日誌路徑
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000                  # 這是前段對外的最大連線數。代理http時，1G空閒記憶體承載20000以上沒大問題
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats  # 開啟動態檢視、管理haproxy的狀態檔案
                                         # 另外建議設定spread-checks全域性項，且百分比建議為2-5之間
defaults
    mode                    http         # 7層http代理，另有4層tcp代理
    log                     global
    option                  httplog      # 在日誌中記錄http請求、session資訊等
    option                  dontlognull  # 不要在日誌中記錄空連線
    option http-server-close             # 後端為動態應用程式建議使用http-server-close，後端為靜態建議使用http-keep-alive
    option forwardfor       except 127.0.0.0/8  # haproxy將在發往後端的請求中加上"X-Forwarded-For"首部欄位
    option                  redispatch   # 當某後端down掉使得haproxy無法轉發攜帶cookie的請求到該後端時，將其轉發到別的後端上
    timeout http-request    10s     # 此為等待客戶端傳送完整請求的最大時長，應該設定較短些防止洪水攻擊，如設定為2-3秒
                                    # haproxy總是要求一次請求或響應全部發送完成後才會處理、轉發，
    timeout queue           1m      # 請求在佇列中的最大時長，1分鐘太長了。設定為10秒都有點長，10秒請求不到資源客戶端會失去耐心
    timeout connect         10s     # haproxy和服務端建立連線的最大時長，設定為1秒就足夠了。區域網內建立連線一般都是瞬間的
    timeout client          1m      # 和客戶端保持空閒連線的超時時長，在高併發下可稍微短一點，可設定為10秒以儘快釋放連線
    timeout server          1m      # 和服務端保持空閒連線的超時時長，區域網內建立連線很快，所以儘量設定短一些，特別是併發時，如設定為1-3秒
    timeout http-keep-alive 10s     # 和客戶端保持長連線的最大時長。優先順序高於timeout http-request高於timeout client
    timeout check           10s     # 和後端伺服器成功建立連線後到最終完成檢查的時長(不包括建立連線的時間，只是讀取到檢查結果的時長)，
                                    # 可設定短一點，如1-2秒
    maxconn                 3000    # 預設和前段的最大連線數，但不能超過global中的maxconn硬限制數

所以修改後建議配置為如下：

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     20000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats
    spread-checks 2
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    timeout http-request    2s
    timeout queue           3s
    timeout connect         1s
    timeout client          10s
    timeout server          2s
    timeout http-keep-alive 10s
    timeout check           2s
    maxconn                 18000 

frontend http-in
    bind             *:80
    mode             http
    log              global
    capture request  header Host len 20
    capture request  header Referer len 60
    acl url_static   path_beg  -i /static /images /stylesheets
    acl url_static   path_end  -i .jpg .jpeg .gif .png .ico .bmp .css .js
    acl url_static   path_end  -i .html .htm .shtml .shtm .pdf .mp3 .mp4 .rm .rmvb .txt
    acl url_static   path_end  -i .zip .rar .gz .tgz .bz2 .tgz

    use_backend      static_group   if url_static
    default_backend  dynamic_group

backend static_group
    balance            roundrobin
    option             http-keep-alive
    http-reuse         safe
    option httpchk     GET /index.html
    http-check expect  status 200
    server staticsrv1  192.168.100.62:80 check rise 1 maxconn 5000
    server staticsrv2  192.168.100.63:80 check rise 1 maxconn 5000

backend dynamic_group
    cookie appsrv insert nocache
    balance roundrobin
    option http-server-close
    option httpchk     GET /index.php
    http-check expect  status 200
    server appsrv1 192.168.100.60:80  check rise 1 maxconn 3000 cookie appsrv1
    server appsrv2 192.168.100.61:80  check rise 1 maxconn 3000 cookie appsrv2

listen report_stats
        bind *:8081
        stats enable
        stats hide-version
        stats uri    /hastats
        stats realm  "pls enter your name"
        stats auth   admin:admin
        stats admin  if TRUE

上面的配置中：

• (1).靜態請求將分配給static_group並進行roundrobin排程，同時通過獲取index.html來做健康狀況檢查，此外還設定了haproxy和後端連線重用的功能。
• (2).動態請求將分配給dynamic_group並進行roundrobin排程，但是向響應報文中插入了一個cookie，保證被排程過的服務端和客戶端能保持會話。此外還設定了通過獲取index.php來做健康狀況檢查。

最後配置nginx和php+php-fpm。

yum -y install nginx php php-fpm

為了區分，分別為nginx1/nginx2的index.php、nginx3/nginx4的index.html檔案中加入響應的主機來源提示，並在php檔案中設定cookie項。其中index.php的內容參考如下：

<h1>response from webapp 192.168.100.60</h1>
<?php
    session_start();
    echo "Server IP: "."<font color=red>".$_SERVER['SERVER_ADDR']."</font>"."<br>";
    echo "Server Name: "."<font color=red>".$_SERVER['SERVER_NAME']."</font>"."<br>";
    echo "SESSIONNAME: "."<font color=red>".session_name()."</font>"."<br>";
    echo "SESSIONID: "."<font color=red>".session_id()."</font>"."<br>";
?>

測試。其中php頁面返回內容大致如此：