本文目錄：
1. 配置haproxy需要考慮的事情
2. 配置haproxy提供反向代理功能

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連接只是為了調度轉發，保證持有合適cookie的客戶端請求能調度到同一後端，完全可以為其它客戶端的請求調度也使用這個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頁面返回內容大致如此：

回到Linux系列文章大綱：http://www.cnblogs.com/f-ck-need-u/p/7048359.html
回到網站架構系列文章大綱：http://www.cnblogs.com/f-ck-need-u/p/7576137.html
回到資料庫系列文章大綱：http://www.cnblogs.com/f-ck-need-u/p/7586194.html
轉載請註明出處：http://www.cnblogs.com/f-ck-need-u/p/8540805.html

註：若您覺得這篇文章還不錯請點擊右下角推薦，您的支持能激發作者更大的寫作熱情，非常感謝！