下圖描述了使用keepalived+Haproxy主從配置來達到能夠針對前段流量進行負載均衡到多臺后端web1、web2、web3、img1、img2.但是由于haproxy會存在單點故障問題，因此使用keepalived來實現對Haproxy單點問題的高可用處理。
常用開源軟件負載均衡器有：Nginx、LVS、Haproxy。
三大主流軟件負載均衡器對比(LVS VS Nginx VS Haproxy)
LVS：
1、抗負載能力強?？关撦d能力強、性能高，能達到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
#定義的多個后端
配置完成則重啟服務：
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
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上，從來提高了系統可靠性。
本文來源：blog.csdn.net/tantexian。
