一、HAProxy簡介
（1）HAProxy 是一款提供高可用性、負載均衡以及基於TCP（第四層）和HTTP（第七層）應用的代理軟件，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。 HAProxy特別適用於那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的 併發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上。
（2）HAProxy 實現了一種事件驅動、單一進程模型，此模型支持非常大的併發連接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制，很少能處理數千併發連接。事件驅動模型因爲在有更好的資源和時間管理的用戶端(User-Space) 實現所有這些任務，所以沒有這些問題。此模型的弊端是，在多核系統上，這些程序通常擴展性較差。這就是爲什麼他們必須進行優化以 使每個CPU時間片(Cycle)做更多的工作。
（3）HAProxy 支持連接拒絕 : 因爲維護一個連接的打開的開銷是很低的，有時我們很需要限制攻擊蠕蟲（attack bots），也就是說限制它們的連接打開從而限制它們的危害。 這個已經爲一個陷於小型DDoS攻擊的網站開發了而且已經拯救
了很多站點，這個優點也是其它負載均衡器沒有的。
（4）HAProxy 支持全透明代理（已具備硬件防火牆的典型特點）: 可以用客戶端IP地址或者任何其他地址來連接後端服務器. 這個特性僅在Linux 2.4/2.6內核打了cttproxy補丁後纔可以使用. 這個特性也使得爲某特殊服務器處理部分流量同時又不修改服務器的地址成爲可能。
性能
HAProxy藉助於OS上幾種常見的技術來實現性能的最大化。
1，單進程、事件驅動模型顯著降低了上下文切換的開銷及內存佔用。
2，O(1)事件檢查器(event checker)允許其在高併發連接中對任何連接的任何事件實現即時探測。
3，在任何可用的情況下，單緩衝(single buffering)機制能以不復制任何數據的方式完成讀寫操作，這會節約大量的CPU時鐘週期及內存帶寬；
4，藉助於Linux 2.6 (>= 2.6.27.19)上的splice()系統調用，HAProxy可以實現零複製轉發(Zero-copy forwarding)，在Linux 3.5及以上的OS中還可以實現零複製啓動(zero-starting)；
5，內存分配器在固定大小的內存池中可實現即時內存分配，這能夠顯著減少創建一個會話的時長；
6，樹型存儲：側重於使用作者多年前開發的彈性二叉樹，實現了以O(log(N))的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少連接隊列；
7，優化的HTTP首部分析：優化的首部分析功能避免了在HTTP首部分析過程中重讀任何內存區域；
8，精心地降低了昂貴的系統調用，大部分工作都在用戶空間完成，如時間讀取、緩衝聚合及文件描述符的啓用和禁用等；
所有的這些細微之處的優化實現了在中等規模負載之上依然有着相當低的CPU負載，甚至於在非常高的負載場景中，5%的用戶空間佔用率和95%的系統空間佔用率也是非常普遍的現象，這意味着HAProxy進程消耗比系統空間消耗低20倍以上。因此，對OS進行性能調優是非常重要的。即使用戶空間的佔用率提高一倍，其CPU佔用率也僅爲10%，這也解釋了爲何7層處理對性能影響有限這一現象。由此，在高端系統上HAProxy的7層性能可輕易超過硬件負載均衡設備。
在生產環境中，在7層處理上使用HAProxy作爲昂貴的高端硬件負載均衡設備故障故障時的緊急解決方案也時長可見。硬件負載均衡設備在“報文”級別處理請求，這在支持跨報文請求(request across multiple packets)有着較高的難度，並且它們不緩衝任何數據，因此有着較長的響應時間。對應地，軟件負載均衡設備使用TCP緩衝，可建立極長的請求，且有着較大的響應時間。
目前haproxy支持的負載均衡算法有如下8種
1.roundrobin
動態加權輪詢算法，支持權重的運行時調整及慢啓動機制；最大支持4095個後端主機；在服務器的處理時間平均分配的情況下這是最流暢和公平的算法。該算法是動態的，對於實例啓動慢的服務器權重會在運行中調整。
2.leastconn
最小連接數算法，連接數最少的服務器優先接收連接。建議用於長會話場景中使用，例如LDAP、SQL等協議，而不適合短會話協議。如HTTP.該算法是動態的，對於實例啓動慢的服務器權重會在運行中調整。
3.static-rr
靜態輪詢算法，不支持權重的運行時調整和慢啓動機制。每個服務器根據權重輪流使用，類似roundrobin。另外，它對服務器的數量沒有限制。
4、source
源地址哈希算法，對請求源IP地址進行哈希；
取模法：將源地址hash計算後除以服務器總權重,服務器變動會影響全局調度效果；根據結果進行分配。只要服務器正常，同一個客戶端IP地址總是訪問同一個服務器。如果哈希的結果隨可用服務器數量而變化，那麼客戶端會定向到不同的服務器；該算法默認是靜態的，所以運行時修改服務器的權重是無效的，但是算法會根據“hash-type”的變化做調整。
該算法一般用於不能插入cookie的Tcp模式。它還可以用於廣域網上爲拒絕使用會話cookie的客戶端提供最有效的粘連；
一致性hash:服務器變動僅影響局部調度；動態調度;
5、uri
表示根據請求的URI左端（問號之前）或整個URI做hash進行哈希計算，並與服務器的總權重相除後根據結果派發至某挑選出的後端主機。只要服務器正常，以最大限度的提高緩存的命中率。
作用是能夠將對同一個uri的請求始終發往一個後端主機；適用於後端爲緩存服務器和反病毒代理的場景； 該算法默認是靜態的，所以運行時修改服務器的權重是無效的，但是算法會根據“hash-type”的變化做調整。該算法只能用於HTTP後端。
6、url_param
在HTTP GET請求的查詢串中查找中指定的URL參數的值做hash計算，並與服務器的總權重相除後派發至某挑選出的後端主機；基本上可以鎖定使用特製的URL到特定的負載均衡器節點的要求；
此算法常用來追蹤請求中的用戶標識，以確保來自同一個用戶的請求始終發往同一個後端主機；
該算法默認是靜態的，所以運行時修改服務器的權重是無效的，但是算法會根據“hash-type”的變化做調整。
7、hdr(name)
對於每個http請求，此處由指定的http首部會被取出；如果此首部沒有有效值，則用roundrobin代替；否則，對其值進行hash計算，並與服務器的總權重相除後派發至某挑選出的後端主機；
該算法默認是靜態的，所以運行時修改服務器的權重是無效的，但是算法會根據“hash-type”的變化做調整。
8、rdp-cookie（name）
爲每個進來的TCP請求查詢並哈希RDPcookie；
該機制用於退化的持久模式，可以使同一個用戶或者同一個會話ID總是發送給同一臺服務器。如果沒有cookie，則使用roundrobin算法代替；
該算法默認是靜態的，所以運行時修改服務器的權重是無效的，但是算法會根據“hash-type”的變化做調整。
二、安裝Haproxy
haproxy的IP：192.168.1.15
web1的IP：192.168.1.16
web2的IP：192.168.1.52
1.編譯安裝Haproxy
[root@localhost ~]# yum -y install pcre-devel bzip2-devel
//安裝依賴包，讓Haproxy服務支持正則表達式、解壓
[root@localhost ~]# tar zxf haproxy-1.5.19.tar.gz -C /usr/src
[root@localhost ~]# cd /usr/src/haproxy-1.5.19/
[root@localhost haproxy-1.5.19]# make TARGET=linux26 //表示是64系統
//正常解壓即可，但是這個軟件不需要配置。
[root@localhost haproxy-1.5.19]# make install
2.Haproxy服務配置
（1）建立Haproxy配置文件
[root@localhost haproxy-1.5.19]# mkdir /etc/haproxy
[root@localhost haproxy-1.5.19]# cp /usr/src/haproxy-1.5.19/examples/haproxy.cfg /etc/haproxy/
//將haproxy.cfg文件複製到配置文件目錄
（2）Haproxy配置項詳解
Haproxy 配置文件通常分爲三個部分：
global（全局配置）；
defaults（默認配置）；
listen（應用組件配置）
global（全局配置）通常有以下配置參數：
global
log 127.0.0.1 local #配置日誌記錄，local0爲日誌設備，默認存放到系統日誌
log 127.0.0.1 local1 notice #notice爲日誌級別，通常有24個級別
#log loghost local0 info
maxconn 4096 #最大連接數
chroot /usr/share/haproxy #該服務自設置的根目錄，一般需將此行註釋掉
uid 99 #用戶UID
gid 99 #用戶GID
daemon #守護進程模式
defaults（默認配置）一般會被應用組件繼承，如果在應用組件中沒有特別聲明，將安裝默認配置參數設置，常見的參數有：
defaults
log global #定義日誌爲global配置中的日誌定義
mode http #模式爲http
option httplog #採用http日誌格式記錄日誌
option dontlognull
retries 3 #檢查節點服務器失敗次數，連續達到三次失敗，則認爲節點不可用
redispatch #當服務器負載很高時，自動結束當前隊列處理比較久的連接
maxconn 2000 #最大連接數
contimeout 5000 #連接超時時間
clitimeout 50000 #客戶端超時時間
srvtimeout 50000 #服務器超時時間
listen（配置項）一般配置應用模塊參數：
listen appli4-backup 0.0.0.0:10004 #定義一個名爲appli4-backup的應用
option httpchk /index.html #檢查服務器的index.html文件
option persist #強制將請求發送到已經down掉的服務器，一般禁用此選項。
balance roundrobin #負載均衡調度算法使用輪詢算法
server inst1 192.168.1.16:80 check inter 2000 fall 3 #定義在線節點
server inst2 192.168.1.52:80 check inter 2000 fall 3 backup #定義備份節點
#注意：在以上定義備份節點的參數中，
#“check inter 2000”表示haproxy服務器和節點之間的一個心跳頻率，
#“fall 3”表示連續三次檢測不到心跳頻率則認爲該節點失效。
#節點配置後帶有“ backup”表示該節點只是個備份節點，只有主節點失效該節點纔會上。
#去除backup，表示爲主節點，和其他主節點共同提供服務。
（4）創建啓動腳本
[root@localhost ~]# cp /usr/src/haproxy-1.5.19/examples/haproxy.init /etc/init.d/haproxy
[root@localhost ~]# ln -s /usr/local/sbin/haproxy /usr/sbin/haproxy
[root@localhost ~]# chmod +x /etc/init.d/haproxy
[root@localhost ~]# chkconfig --add /etc/init.d/haproxy
[root@localhost ~]# /etc/init.d/haproxy start
Starting haproxy (via systemctl): [ 確定 ]
（5）Haproxy服務的日誌
Haproxy的日誌默認輸出到系統的syslog中，查看起來非常不方便，爲了更好的管理Haproxy的日誌信息，我們在聲場環境中一般單獨定義出來。方法如下：
[root@localhost ~]# vim /etc/haproxy/haproxy.cfg
global
log /dev/log local0 info
log /dev/log local0 notice
//添加兩行內容，把原本關於日誌的信息註釋掉
[root@localhost ~]# systemctl restart haproxy
//重啓服務
[root@localhost ~]# vim /etc/rsyslog.d/haproxy.conf
//定義Haproxy服務的日誌文件存放的位置，添加如下內容：
if ($programname == 'haproxy' and $syslogseverity-text == 'info') then -/var/log/haproxy/haproxy-info.log
& ~
if ($programname == 'haproxy' and $syslogseverity-text == 'notice') then -/var/log/haproxy/haproxy-notice.log
& ~
[root@localhost ~]# systemctl restart rsyslog
//重啓日誌服務
當客戶端訪問時，就可以利用以下命令查看Haproxy服務的日誌文件
[root@localhost ~]# tail -f /var/log/haproxy/haproxy-info.log