何謂代理？
所謂的代理一般分爲兩種，即正向代理和反向代理。正向代理可以實現讓不同的主機通過代理服務器使用同一個地址和Internet上的其他主機通信，通常在一個局域網內只有一個公網IP時都需要用到正向代理，而反向代理則實現的是將來自不同主機的請求發送給後端的其他服務器就行處理，而自己不負責具體如何去處理。
HAProxy介紹
HAProxy是一款基於Linux平臺且開源的反向代理實現軟件，同時支持虛擬主機，可以提供高可用性、負載均衡以及基於TCP和HTTP應用的代理。HAProxy特別適用於負載特別大的web站點，這些站點通常又需要回話保持或七層處理。HAProxy運行在當前的硬件上，完全可以支持數萬計的併發連接。
並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上。
HAProxy實現了一種事件驅動, 單一進程模型，此模型支持非常大的併發連接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制，很少能處理數千併發連接。事件驅動模型因爲在有更好的資源和時間管理的用戶空間(User-Space) 實現所有這些任務，所以沒有這些問題。此模型的弊端是，在多核系統上，這些程序通常擴展性較差。這就是爲什麼他們必須進行優化以 使每個CPU時間片(Cycle)做更多的工作。
HAProxy實現反向代理的一些配置實例
接下來將通過配置HAProxy的形式介紹HAProxy的配置。
實驗地址規劃
主機 | IP | 用途 |
A | 192.168.2.240/24 | 安裝HAProxy |
B | 192.168.2.241/24 | 安裝HTTPD |
B | 192.168.2.242/24 | 安裝HTTPD |
準備工作：
在主機A上安裝好HAProxy，主機B上安裝好HTTPD，
配置好yum源後可直接使用yum安裝，併爲主機B配置兩個地址，在此就不再贅述
例1：將來自客戶端的請求反向代理至後端兩個不同的web-server
（1）配置虛擬主機
註釋主配置文件/etc/http/conf/httpd.conf中的DocumentRoot項，然後在/etc/http/conf.d/中新建文件virtual.conf文件，並添加如下內容
<VirtualHost 192.168.2.241:80>
DocumentRoot /var/www/test1
ServerName www.test1.com
</VirtualHost>
<VirtualHost 192.168.2.242:80>
DocumentRoot /var/www/test2
ServerName www.test2.com
</VirtualHost>
新建虛擬主機目錄，並提供虛擬主機主頁面文件
[root@localhost ~]# mkdir /var/www/test1
[root@localhost ~]# mkdir /var/www/test2
[root@localhost ~]# echo "this is test1" >/var/www/test1/index.html
[root@localhost ~]# echo "this is test2" >/var/www/test2/index.html
（2）配置主機A，編輯HAProxy主配置文件如下
frontend testservers *:80
use_backend web1
backend web1
balance roundrobin
server web1 192.168.2.241:80
server web2 192.168.2.242:80
註釋：配置項說明
frontend ：用於定義前端監聽的套接字，用戶訪問服務器時就是通過這些套接字與服務器通信
use_backend：指定使用哪個後端作爲響應，通常後端會通過backend來配置一個或者一組服務器，用來響應前端代理過來的請求
backend：定義後端一系列服務器，通常可以通過名字引用，當前端的frontend接收進請求後就會把客戶端的請求發給響應的backend
balance：指定調度算法，調度算法有以下幾類
roundrobin：和lvs中的rr類似，不過該調度算法可在server後面加上相應的權重，加上權重後則成爲基於權重的輪詢調度算法，類似於wrr
static-rr：該算法和roundrobin一樣，可基於權重做輪詢，但是roundrobin是動態調度算法，可動態更新服務器的權重，並實時應用，而static-rr則是靜態的，不會實時應用服務器權重。
leastconn：最少連接調度算法，該算法會把客戶端的請求發給後端負載最小的服務器，該算法是動態算法，會實時根據每臺服務器權重進行計算，然後動態判斷請求的去向。
source:該算法根會據請求的源地址進行hash計算的結果，把請求轉發給後端服務器，基於該調度算法，來自同一客戶端IP的請求會始終被髮往後端的同一臺服務器。不過，當後端服務器宕機或添加了新的服務器時，許多的請求可能會被髮往與之間請求不同的服務器，常用語負載均衡無cookie功能的基於TCP的協議，默認爲動態，可通過hash-type修改
hash-type：指定hash算法的類型，後可跟如下兩個選項
map-based：取模算法（靜態）
constraint：一致性hash算法（動態）
uri：對uri的左半部分（“？”標記之前的部分）進行hash運算。並由服務器的總權重相除後派發至某匹配的服務器。
<scheme>：//<user>：<password>@<host>:<port>/<path>;<params>？<query>#<frag>
params：參數，
query：如何向數據庫發起查詢請求
frag：片段
url_param：通過<argument>爲URL指定的參數在每個HTTP GET請求中將會被索引，通過找到了指定的參數且其通過等於號“=”被賦予一個值。那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器，可以使用hash_type指定hash算法類型
her（<name>）：對於每個HTTP請求，通過<name>指定的HTTP首部將會被檢索，如果對於那個的首部沒有出現或其沒有有效值，則使用輪詢算法對其想用請求進行調度。此算法默認爲靜態，可以使用hash_type修改此特性。
例2：開啓haproxy狀態頁，並要求基於用戶認證後才能訪問
編輯配置文件/etc/haproxy/haproxy.cfg，在backend段內添加如下配置項：
stats enable
stats uri /haproxy-stats
stats realm Haproxy Statistics
stats hide-version
stats scope .
stats auth zhangsan:adminadmin
stats auth lisi:adminadmin
重啓或重讀配置文件測試
註釋：
stats enable #：啓用狀態頁功能
stats uri /haproxy-stats #：設定狀態頁的訪問路徑
stats realm please-input-secreate #:顯示認證提示信息
stats hide-version #:影藏首部信息
stats scope . #：啓用統計報告，並限制統計報告的區域
stats auth zhangsan:adminadmin #：添加認證用戶
stats auth lisi:adminadmin #：添加認證用戶
例3：開啓HAProxy日誌記錄功能
編輯配置文件在frontend段內添加如下參數
log 127.0.0.1:514 local2
編輯rsyslog配置文件把如下兩項的前面#去掉
$ModLoad imudp
$UDPServerRun 514
重啓rsyslog和haproxy服務即可
註釋：
log：記錄日誌，可以放在不同frontend或者backend中，用於記錄不同實例的日誌
格式：log <address><facility>[<level>[<minlevel>]]
adrress：使用的日誌服務器的地址
facility：指定某個日誌設施，用於後端日誌服務器記錄日誌時調用
level：定義日誌級別，對日誌信息進行過濾
minlevel：定義所需記錄日誌的最小級別
其他選項都是圍繞其後端代理設置展開，可參考官方文檔：http://cbonte.github.io/haproxy-dconv/configuration-1.4.html