下圖描述了使用keepalived+Haproxy主從配置來達到能夠針對前段流量進行負載均衡到多台后端web1、web2、web3、img1、img2.
但是由於haproxy會存在單點故障問題，因此使用keepalived來實現對Haproxy單點問題的高可用處理。
三大主流軟件負載均衡器對比(LVS VS Nginx VS Haproxy)
| LVS： 1、抗負載能力強。抗負載能力強、性能高，能達到F5硬件的60%；對內存和cpu資源消耗比較低 2、工作在網絡4層，通過vrrp協議轉發（僅作分發之用），具體的流量由linux內核處理，因此沒有流量的產生。 2、穩定性、可靠性好，自身有完美的熱備方案；（如：LVS+Keepalived） 3、應用范圍比較廣，可以對所有應用做負載均衡； 4、不支持正則處理，不能做動靜分離。 5、支持負載均衡算法：rr（輪循）、wrr（帶權輪循）、lc（最小連接）、wlc（權重最小連接） 6、配置 復雜，對網絡依賴比較大，穩定性很高。 |
|
Ngnix：
1、工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
2、Nginx對網絡的依賴比較小，理論上能ping通就就能進行負載功能；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發；
5、對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。
6、Nginx對請求的異步處理可以幫助節點服務器減輕負載；
7、Nginx僅能支持http、https和Email協議，這樣就在適用范圍較小。
8、不支持Session的直接保持，但能通過ip_hash來解決。、對Big request header的支持不是很好，
9、支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、Ip-hash（Ip哈希）
10、Nginx還能做Web服務器即Cache功能。
|
| HAProxy的特點是： 1、支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機； 2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作 3、支持url檢測后端的服務器出問題的檢測會有很好的幫助。 4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現 5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。 6、HAProxy可以對Mysql進行負載均衡，對后端的DB節點進行檢測和負載均衡。 9、支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie） 10、不能做Web服務器即Cache。 |
三大主流軟件負載均衡器適用業務場景：
1、網站建設初期，可以選用Nigix/HAproxy作為反向代理負載均衡（或者流量不大都可以不選用負載均衡），因為其配置簡單，性能也能滿足一般的業務場景。如果考慮到負載均衡器是有單點問題，可以采用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。 2、網站並發達到一定程度之后，為了提高穩定性和轉發效率，可以使用LVS、畢竟LVS比Nginx/HAproxy要更穩定，轉發效率也更高。不過維護LVS對維護人員的要求也會更高，投入成本也更大。 注：Niginx與Haproxy比較：Niginx支持七層、用戶量最大，穩定性比較可靠。Haproxy支持四層和七層，支持更多的負載均衡算法，支持session保存等。具體選型看使用場景，目前來說Haproxy由於彌補了一些Niginx的缺點用戶量也不斷在提升。 |
衡量負載均衡器好壞的幾個重要因素：
1、會話率 ：單位時間內的處理的請求數
2、會話並發能力：並發處理能力
3、數據率：處理數據能力
經過官方測試統計，haproxy 單位時間處理的最大請求數為20000個，可以同時維護40000-50000個並發連接，最大數據處理能力為10Gbps。綜合上述，haproxy是性能優越的負載均衡、反向代理服務器。
總結HAProxy主要優點：
一、免費開源，穩定性也是非常好，這個可通過我做的一些小項目可以看出來，單Haproxy也跑得不錯，穩定性可以與LVS相媲美；
二、根據官方文檔，HAProxy可以跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，這個作為軟件級負載均衡，也是比較驚人的；
三、HAProxy可以作為MySQL、郵件或其它的非web的負載均衡，我們常用於它作為MySQL(讀)負載均衡；
四、自帶強大的監控服務器狀態的頁面，實際環境中我們結合Nagios進行郵件或短信報警，這個也是我非常喜歡它的原因之一；
五、HAProxy支持虛擬主機。
Haproxy負載均衡器講解：
本次使用環境：
環境centos7.1
Haproxy 1.5.4
Haproxy+keeplived 172.31.2.31
Haproxy+keeplived 172.31.2.32
下述針對Haproxy的配置文件進行詳解：
vim
/etc/haproxy/haproxy.cfg
global # 全局參數的設置 log 127.0.0.1 local2 # log語法：log <address_1>[max_level_1] # 全局的日志配置，使用log關鍵字， 指定使用127.0.0.1 上的syslog服務中的local0日志設備，記錄日志等級為info的日志 chroot /var/lib/haproxy #改變當前工作目錄 pidfile /var/run/haproxy.pid #當前進程id文件 maxconn 4000 #最大連接數 user haproxy #所屬用戶 group haproxy #所屬組 daemon #以守護進程方式運行haproxy stats socket /var/lib/haproxy/stats defaults mode http #默認的模式mode { tcp|http|health }，tcp是4層，http是7層，health只會返回OK log global #應用全局的日志配置 option httplog # 啟用日志記錄HTTP請求，默認haproxy日志記錄是不記錄HTTP請求日志 option dontlognull # 啟用該項，日志中將不會記錄空連接。所謂空連接就是在上游的負載均衡器 或者監控系統為了探測該 服務是否存活可用時，需要定期的連接或者獲取某 一固定的組件或頁面，或者探測掃描端口是否在監聽或開放等動作被稱為空連接； 官方文檔中標注，如果該服務上游沒有其他的負載均衡器的話，建議不要使用 該參數，因為互聯網上的惡意掃描或其他動作就不會被記錄下來 option http-server-close #每次請求完畢后主動關閉http通道 option forwardfor except 127.0.0.0/8 #如果服務器上的應用程序想記錄發起請求的客戶端的IP地址，需要在HAProxy 上 配置此選項， 這樣 HAProxy會把客戶端的IP信息發送給服務器，在HTTP 請求中添加"X-Forwarded-For"字段。 啟用 X-Forwarded-For，在requests 頭部插入客戶端IP發送給后端的server，使后端server獲取到客戶端的真實IP。 option redispatch # 當使用了cookie時，haproxy將會將其請求的后端服務器的serverID插入到 cookie中，以保證會話的SESSION持久性；而此時，如果后端的服務器宕掉 了， 但是客戶端的cookie是不會刷新的，如果設置此參數，將會將客戶的請 求強制定向到另外一個后端server上，以保證服務的正常。 retries 3 # 定義連接后端服務器的失敗重連次數，連接失敗次數超過此值后將會將對應后端 服務器標記為不可用 timeout http-request 10s #http請求超時時間 timeout queue 1m #一個請求在隊列里的超時時間 timeout connect 10s #連接超時 timeout client 1m #客戶端超時 timeout server 1m #服務器端超時 timeout http-keep-alive 10s #設置http-keep-alive的超時時間 timeout check 10s #檢測超時 maxconn 3000 #每個進程可用的最大連接數 frontend main *:80 #監聽地址為80 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 my_webserver #定義一個名為my_app前端部分。此處將對於的請求轉發給后端 backend static #使用了靜態動態分離（如果url_path匹配 .jpg .gif .png .css .js靜態文件則 訪問此后端） balance roundrobin #負載均衡算法（#banlance roundrobin 輪詢，balance source 保存session值， 支持static-rr，leastconn，first，uri等參數） server static 127.0.0.1:80 check #靜態文件部署在本機（也可以部署在其他機器或者squid緩存服務器） backend my_webserver #定義一個名為my_webserver后端部分。PS：此處my_webserver只是一個 自定義名字而已，但是需要與frontend里面配置項default_backend 值相一致 balance roundrobin #負載均衡算法 server web01 172.31.2.33:80 check inter 2000 fall 3 weight 30 #定義的多個后端 server web02 172.31.2.34:80 check inter 2000 fall 3 weight 30 #定義的多個后端 server web03 172.31.2.35:80 check inter 2000 fall 3 weight 30 #定義的多個后端
更多關於Haproxyacl配置參考：http://blog.csdn.net/tantexian/article/details/50015975
配置完成則重啟服務：
systemctl restart haproxy
假若想訪問監控界面：配置stats uri /haproxy項，重啟服務：
systemctl reload haproxy
注意：假若頁面范圍不了，是否selinux關閉了，iptables開啟此端口了（iptables -F）
同理在172.31.2.32上面安裝上述步驟安裝配置好haproxy：
上述對Haproxy的優缺點及配置進行了詳細講解。
接下來對Haproxy+web負載均衡使用進行實戰講解：
首先配置三台web服務器：172.31.2.33、172.31.2.34、172.31.2.35
三台都是同樣操作：
1、實驗環境
centos 7.1 X64 mini版
2、配置web服務器(node33/34/35)：
測試方便，關閉selinux、關閉iptables
一下都采用默認，不做配置即可。
yum install httpd -y
# vim /etc/httpd/conf/httpd.conf
httpd監聽端口：
DocumentRoot：網頁存放的路徑，文檔的根目錄
重啟httpd
# systemctl restart httpd
頁面訪問httpd：
修改顯示內容：
# vim /var/www/html/index.html
I'm node33!!! My IP is 172.31.2.33...
再次訪問：
這樣三個web服務33/34/35搭建成功！！！！
接下來配置負載均衡（本次實驗只用一個Haproxy：172.31.2.31）：
vim /etc/haproxy/haproxy.cfg
瀏覽器請求172.31.2.31：
從上述結果可知，前端對172.31.2.31的請求，被Haproxy的負載均衡器，均衡請求到三個后端web172.31.2.33、172.31.2.34、172.31.2.35上面去了。
這樣當三個當中的一個出現故障，流量則能正常分發到剩余兩個正常的web上，從來提高了系統可靠性。
keepalived+Haproxy參考：http://blog.csdn.net/tantexian/article/details/50056229