摘要：單進程事件驅動模型顯著降低了上下文切換的開銷及內存占用。指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。啟用統計報告并限定報告的區段，不能用于區段。如果的確有這種問題，可以使用來返回狀態碼給客戶端。

http://ju.outofmemory.cn/entry/218244
http://www.cnblogs.com/gtms/p/6790939.html
http://www.92to.com/bangong/2016/08-24/9737822.html
http://blog.sina.com.cn/s/blog_704836f40102vrt0.html
http://blog.csdn.net/jinshiyill/article/details/50824352

  HAProxy主要提供兩個功能：http協議反向代理(不提供緩存功能)、基于tcp層的負載均衡(如https、MySQL協議)。適用于需要會話保持或七層處理的且負載特別大的站點。可支持數以萬計的并發連接。
  代理作用：web緩存（加速）、反向代理、內容路由（根據流量及內容類型等將請求轉發至特定服務器）、轉碼器；
  HAProxy基于一種事件驅動(event-driven)、單一進程模型和ebtree彈性二叉樹機制。
  多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，很少能處理數千并發連接。事件驅動模型有更好的資源和時間管理的用戶端(User-Space) 實現所有這些任務，所以并發響應能特別大。但在多核系統上此模型通常擴展性較差

  HAProxy借助于OS上幾種常見的技術來實現性能的最大化。
      單進程、事件驅動模型顯著降低了上下文切換的開銷及內存占用。
      O(1)事件檢查器(eventchecker)允許其在高并發連接中對任何連接的任何事件實現即時探測。
      在任何可用的情況下，單緩沖(singlebuffering)機制能以不復制任何數據的方式完成讀寫操作，這會節約大量的CPU時鐘周期及內存帶寬；
      借助于Linux 2.6 (>=2.6.27.19)上的splice()系統調用，HAProxy可以實現零復制轉發(Zero-copy forwarding)，在Linux3.5及以上的OS中還可以實現零復制啟動(zero-starting)；
       內存分配器在固定大小的內存池中可實現即時內存分配，這能夠顯著減少創建一個會話的時長；
       樹型存儲：側重于使用作者多年前開發的彈性二叉樹，實現了以O(log(N))的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少連接隊列；
      優化的HTTP首部分析：優化的首部分析功能避免了在HTTP首部分析過程中重讀任何內存區域；
      精心地降低了昂貴的系統調用，大部分工作都在用戶空間完成，如時間讀取、緩沖聚合及文件描述符的啟用和禁用等；

1.4版本——提供較好的彈性：衍生于1.2版本，并提供了額外的新特性，其中大多數是期待已久的。
客戶端側的長連接(client-side keep-alive)
TCP加速(TCP speedups)
響應池(response buffering)
RDP協議
基于源的粘性(source-based stickiness)
更好的統計數據接口(a much better stats interfaces)
更詳細的健康狀態檢測機制(more verbose health checks)
基于流量的健康評估機制(traffic-based health)
支持HTTP認證
服務器管理命令行接口(server management from the CLI)
基于ACL的持久性(ACL-based persistence)
日志分析器

 1.3版本——內容交換和超強負載：衍生于1.2版本，并提供了額外的新特性。

內容交換(content switching)：基于任何請求標準挑選服務器池；
ACL：編寫內容交換規則；
負載均衡算法(load-balancing algorithms)：更多的算法支持；
內容探測(content inspection)：阻止非授權協議；
透明代理(transparentproxy)：在linux系統上允許使用客戶端IP直接連入服務器；
內核TCP拼接(kernel TCPsplicing)：無copy方式在客戶端和服務端之間轉發數據以實現數G級別的數據速率；
分層設計(layereddesign)：分別實現套接字、TCP、HTTP處理以提供更好的健壯性、更快的處理機制及便捷的演進能力；
快速、公平調度器(fast and fairscheduler)：為某些任務指定優先級可實現理好的QoS；
會話速率限制(session rate limiting)：適用于托管環境；
注意：

  1)1.1、1.2、1.3的poll和epoll機制對性能影響
      1.1l版本默認使用的polling系統為select()，其處理的文件數達數千個時性能便會急劇下降。
      1.2和1.3版本默認的為poll()，在有些操作系統上可會也會有性能方面的問題，但在Solaris上表現相當不錯。
      HAProxy1.3在Linux 2.6及打了epoll補丁的Linux2.4上默認使用epoll，在FreeBSD上使用kqueue，這兩種機制在任何負載上都能提供恒定的性能表現。
 2) 高性能選型方案

Linux 2.6.32及之后版本上運行HAProxy 1.4；
打了epoll補丁的Linux2.4上運行HAProxy 1.4；
FreeBSD上運行HAProxy1.4；
Solaris10上運行HAProxy 1.4；

 3)splice()調用機制
        在較新版本的Linux2.6(>=2.6.27.19)上，HAProxy還能夠使用splice()系統調用在接口間無復制地轉發任何數據，甚至可以達到10Gbps的性能。

[root@localhost~]# yum install -y haproxy
主配置文件：/etc/haproxy/haproxy.cfg
主程序：/usr/sbin/haproxy

 實例一：

frontend  main *:5000
   acl url_static       path_beg       -i /static /images /JavaScript/stylesheets
   acl url_static       path_end       -i .jpg .gif .png .css .js
   use_backend static          if url_static
   default_backend             app
backendstatic
   balance    roundrobin
   server     static 127.0.0.1:4331 check
backendapp
   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

   實例二：

frontendmain
bind  *:80
default_backendwebsrvs
backendwebsrvs
balanceroundrobin
server web1 172.16.49.102:80 check
server web2 172.16.49.103:80 check

定義負載均衡算法，可用于"defaults"、"listen"和"backend"配置段

    ① roundrobin，表示簡單的輪詢，這個是負載均衡基本都具備的；
    ② static-rr，表示根據權重，選擇 server 的邏輯最為簡單
    ③ leastconn，表示最少連接者先處理
    ④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制類似，用其作為解決session問題的一種方法
    ⑤ ri，表示根據請求的URI；
    ⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name；
    ⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；

    ⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定并哈希每一次TCP請求。

注意

    (1)當使用uri算法時，第一次請求一個URL分發到一個主機，則之后再次請求相同URL則使用一臺主機響應。當第一次請求之后，若響應該請求的主機服務出現故障，則haproxy或將其調度到其他主機，此主機修復后再次調度回來
      (2)URI：統一資源標識符；格式如下：
    ://:@:/;?#
    方案://用戶:密碼@主機:端口/路徑;參數(鍵值數據、可以多個參數字段)?查詢語句#片段顯示

  格式：hash-type 
     定義用于將hash碼映射至后端服務器的方法；不能用于frontend區段；可用方法有map-based和consistent
  說明：

定義一個或者幾個監聽的套接字、只能用于frontend， listen;
    bind[
]: [, ...]
    bind[
]: [, ...] interface         

為frontend指明使用的默認后端；default_backend
實例：
use_backend dynamic if url_dyn
use_backend static if url_css url_img extension_img
default_backend dynamic

注意：use_backend: 條件式后端調用；

server :port；用于為后端聲明一個server
：名稱，標識符
[:port]：設定后端真實服務器監聽的端口和地址
[param*]：參數
backup: 設定為備用服務器，僅在負載均衡場景中的其它server均不可用于啟用此server；
check:健康狀態檢測；
inter：檢測時間間隔；單位為ms, 默認為2000;
rise：設定健康狀態檢查中，某離線的server從離線狀態轉換至正常狀態需要成功檢查的次數；
fall：確認server從正常狀態轉換為不可用狀態需要檢查的次數；
cookie ：為指定server設定cookie值，用于實現持久連接的功能；
maxconn:此服務接受的并發連接的最大數量；
maxqueue:請求隊列的最大長度；
observe:根據流量判斷后端server的健康狀態；
weight #: 指定權重，#默認為1，最大為256；0表示不被調度；
redir: 重定向；所有發往此服務器的請求均以302響應；

注意：
   健康監測的方式有多種，具體服務可能檢測方法的配置指令不同；此處為后端http服務時的健康狀態的檢測方法，在defaults配置段定義了" option httpchk "。
"httpchk"、"smtpchk"、"mysql-check"、"pgsql-check"、"ssl-hello-chk"
實例：基于瀏覽器cookie實現sessionsticky(會話綁定)

backendwebsrvs

  balance    roundrobin
  cookie SERVERID insert    # 報文首部插入標識
  server web1 172.16.49.102:80 check weight 1 cookie websrv1     # cookie綁定名稱參數標識
  server web2 172.16.49.103:80 check weight 3 cookie websrv2

注釋：每個server有自己惟一的cookie標識、在backend中定義為用戶請求調度完成后操縱其cookie

(1) capture requestheader

      格式：capture request header  len 
      捕獲并記錄指定的請求首部最近一次出現時的第一個值，僅能用于“frontend”和“listen”區段
    ：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出現在首部中的格式相同，比如大寫首字母。需要注意的是，記錄在日志中的是首部對應的值，而非首部名稱。
    ：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。

注意：

  可以捕獲的請求首部的個數沒有限制，但每個捕獲最多只能記錄64個字符。為了保證同一個frontend中日志格式的統一性，首部捕獲僅能在frontend中定義。

(2)captureresponse header；捕獲并記錄響應首部，其格式和要點同請求首部。

     格式：capture response header  len 

1.配置監控頁信息
(1)stats enable

         啟用基于程序編譯時默認設置的統計報告，不能用于“frontend”區段。

(2)stats hide-version

      啟用統計報告并隱藏HAProxy版本報告，不能用于“frontend”區段。

(3)stats realm

      格式：stats realm 
        ：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用于提示用戶輸入一個用戶名和密碼。
  啟用統計報告并高精認證領域，不能用于“frontend”區段。haproxy在讀取realm時會將其視作一個單詞，因此，中間的任何空白字符都必須使用反斜線進行轉義。此參數僅在與“statsauth”配置使用時有意義。

(4)stats scope

      stats scope { | "." }
       ：可以是“listen”、“frontend”或“backend”區段的名稱，而“.”則表示statsscope語句所定義的當前區段。
     啟用統計報告并限定報告的區段，不能用于“frontend”區段。當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，所有其它區段的信息將被隱藏。如果需要顯示多個區段的統計報告，此語句可以定義多次。需要注意的是，區段名稱檢測僅僅是以字符串比較的方式進行，它不會真檢測指定的區段是否真正存在。

(5)stats auth

       格式：stats auth :
：授權進行訪問的用戶名；
：此用戶的訪問密碼，明文格式；
      啟用帶認證的統計報告功能并授權一個用戶帳號，其不能用于“frontend”區段。

(6)stats admin

      格式：stats admin {if | unless } 
     在指定的條件滿足時啟用統計報告頁面的管理級別功能，它允許通過web接口啟用或禁用服務器。

(1)在配置文件/etc/haproxy/haproxy.cfg中配置代理和監控配置信息
listenstatistics

bind  *:9090
stats  enable
stats  hide-version
stats uri /haproxyadmin?stats 
stats realm  "HAPorxyStatistics"
stats auth admin:xuding
stats admin if TRUE  

(2)訪問URL：http://172.16.49.101:9090/hap...

(3)此時即可進入管理頁面進行對后端服務器的管理和頁面監控數據監控

說明：

errorfile:使用haproxy主機本地文件進行響應；
errorloc,errorloc302: 使用指定的url進行響應，響應狀態碼為302；不適用于GET以外的其它請求方法；
errorloc303：返回303狀態碼；

    格式：errorfile  

在用戶請求不存在的頁面時，返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼；可用于所有段中。

  請求錯誤時，返回一個HTTP重定向至某URL的信息；可用于所有配置段中。
    errorloc 
    errorloc302 
       ：指定對HTTP的哪些狀態碼返回指定的頁面；這里可用的狀態碼有200、400、403、408、500、502、503和504；
       ：Location首部中指定的頁面位置的具體路徑，可以是在當前服務器上的頁面的相對路徑，也可以使用絕對路徑；需要注意的是，如果URI自身錯誤時產生某特定狀態碼信息的話，有可能會導致循環定向；

這兩個關鍵字都會返回302狀態嗎，這將使得客戶端使用同樣的HTTP方法獲取指定的URL，對于非GET廣場法的場景(如POST)來說會產生問題，因為返回客戶的URL是不允許使用GET以外的其它方法的。如果的確有這種問題，可以使用errorloc303來返回303狀態碼給客戶端。

    errorloc303  ；請求錯誤時，返回一個HTTP重定向至某URL的信息給客戶端；可用于所有配置段中。
     ：指定對HTTP的哪些狀態碼返回指定的頁面；這里可用的狀態碼有400、403、408、500、502、503和504；
     ：Location首部中指定的頁面位置的具體路徑，可以是在當前服務器上的頁面的相對路徑，也可以使用絕對路徑；需要注意的是，如果URI自身錯誤時產生某特定狀態碼信息的話，有可能會導致循環定向；