1、簡述四層和七層負載均衡的特點及Haproxy與LVS之間的對比
2、簡述Haproxy常見的負載均衡調(diào)度算法及應(yīng)用場景詳解
3、通過Haproxy的ACL規(guī)劃實現(xiàn)智能負載均衡，并簡述tcp、http、health的配置示例
4、LNMT實現(xiàn)動靜分離實戰(zhàn)
1、簡述四層和七層負載均衡的特點及Haproxy與LVS之間的對比
（1）簡述四層和七層負載均衡的特點
四層負責(zé)均衡：主要是指通過判斷報文的IP地址和端口并通過一定的負載均衡算法來決定轉(zhuǎn)發(fā)到哪個指定目標(biāo)，主要工作在OSI模型的第四層。四層負載均衡對數(shù)據(jù)包只是起一個數(shù)據(jù)轉(zhuǎn)發(fā)的作用，并不會干預(yù)客戶端與服務(wù)器之間應(yīng)用層的通信（如：三次握手等）。所以能對數(shù)據(jù)所進行的操作也就很少，但相對于七層負載均衡來講效率會高上很多
七層負載均衡：也被稱為“內(nèi)容交換”，指的是負載均衡設(shè)備通過報文中的應(yīng)用層信息(URL、HTTP頭部等信息)和負載均衡算法，選擇到達目的的內(nèi)部服務(wù)器。七層負載均衡可以“智能化”地篩選報文中 應(yīng)用層信息，然后根據(jù)不同的信息進行特定的負載均衡調(diào)度。這種方式提升了應(yīng)用系統(tǒng)在網(wǎng)絡(luò)層上的靈活性，另外也在一定程度上提升了后端系統(tǒng)的安全性。因為像網(wǎng)絡(luò)常見的DoS攻擊，這些攻擊在七層負載均衡的環(huán)境下通常都在負載均衡設(shè)備上就截止了，不會影響到后臺服務(wù)器的正常運行。
（2）HAproxy、nginx與Lvs的對比
前網(wǎng)絡(luò)中常見的負載均衡主要分為硬件負載均衡和軟件負載均衡。硬件負載均衡比較知名的產(chǎn)品有F5 Big-IP、Cirtix Netscaler等等。而軟件負載均衡就有著眾多的開源項目，常見的有Haproxy、nginx、lvs等。
Haproxy：
1、支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導(dǎo)等工作
3、支持url檢測后端的服務(wù)器出問題的檢測會有很好的幫助。
4、更多的負載均衡策略比如：動態(tài)加權(quán)輪循(Dynamic Round Robin)，加權(quán)源地址哈希(Weighted Source Hash)，加權(quán)URL哈希和加權(quán)參數(shù)哈希(Weighted Parameter Hash)。
5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6、HAProxy可以對Mysql進行負載均衡，對后端的DB節(jié)點進行檢測和負載均衡。
9、支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據(jù)cookie）
10、不能做Web服務(wù)器即Cache。
lvs:
1、抗負載能力強、性能高，能達到F5硬件的60%；對內(nèi)存和cpu資源消耗比較低
2、工作在網(wǎng)絡(luò)4層，通過vrrp協(xié)議轉(zhuǎn)發(fā)（僅作分發(fā)之用），具體的流量由linux內(nèi)核處理，因此沒有流量的產(chǎn)生。
2、穩(wěn)定性、可靠性好，自身有完美的熱備方案；（如：LVS+Keepalived）
3、應(yīng)用范圍比較廣，可以對所有應(yīng)用做負載均衡；
4、不支持正則處理，不能做動靜分離。
5、支持負載均衡算法：rr（輪循）、wrr（帶權(quán)輪循）、lc（最小連接）、wlc（權(quán)重最小連接）
6、配置 復(fù)雜，對網(wǎng)絡(luò)依賴比較大，穩(wěn)定性很高。
nginx:
1、工作在網(wǎng)絡(luò)的7層之上，可以針對http應(yīng)用做一些分流的策略，比如針對域名、目錄結(jié)構(gòu)；
2、Nginx對網(wǎng)絡(luò)的依賴比較小，理論上能ping通就就能進行負載功能；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、可以承擔(dān)高的負載壓力且穩(wěn)定，一般能支撐超過1萬次的并發(fā)；
5、對后端服務(wù)器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。
6、Nginx對請求的異步處理可以幫助節(jié)點服務(wù)器減輕負載；
7、Nginx僅能支持http、https和Email協(xié)議，這樣就在適用范圍較小。
8、不支持Session的直接保持，但能通過ip_hash來解決。、對Big request header的支持不是很好，
9、支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、Ip-hash（Ip哈希）
10、Nginx還能做Web服務(wù)器即Cache功能
2、簡述Haproxy常見的負載均衡調(diào)度算法及應(yīng)用場景詳解
roundrobin：基于權(quán)重進行輪詢，此算法是動態(tài)的，其權(quán)重可以在運行時進行調(diào)整。
static-rr：基于權(quán)重進行輪詢，與roundrobin類似，但是為靜態(tài)方法，在運行時調(diào)整其服務(wù)器權(quán)重不會生效。
leastconn：新的連接請求被派發(fā)至具有最少連接數(shù)目的后端服務(wù)器，動態(tài)算法，適用于較長時間會話的場景。
source：將請求的源地址進行hash運算，并與后端服務(wù)器的總權(quán)重作取模運算后調(diào)度至某臺服務(wù)器；同一IP地址的請求將始終被調(diào)度至某特定的服務(wù)器，靜態(tài)算法，可以使用hash-type修改此特性；
uri：對URI的左半部分(“？”之前的部分)或整個URI進行hash運算，并與后端服務(wù)器的總權(quán)重作取模運算后調(diào)度至某臺服務(wù)器；同一URI的請求將始終被調(diào)度至某特定的服務(wù)器，靜態(tài)算法，可以使用hash-type修改此特性；
hdr(<name>)：根據(jù)用戶請求報文中指定的http首部的值進行調(diào)度，常用于實現(xiàn)將對同一個虛擬主機的請求始終發(fā)往同個backend server。
3、通過Haproxy的ACL規(guī)劃實現(xiàn)智能負載均衡，并簡述tcp、http、health的配置示例
Haproxy可以做代理服務(wù)相對于nginx而言有很多相同之處，統(tǒng)一可以基于mode tcp進行四層代理也可以基于mode http進行七層代理，但不同的是其無法使用location和if等進行匹配判斷。突出優(yōu)勢在于有會話綁定，web管理界面，狀態(tài)統(tǒng)計非常詳細。官方推薦只啟用一個進程，相對于nginx多進程架構(gòu)工作并不理想，更多的線程可能會受到系統(tǒng)內(nèi)存的一些限制。
程序環(huán)境：
主程序：/usr/sbin/haproxy
主配置文件：/etc/haproxy/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service
配置段：
global：全局配置段
進程及安全配置相關(guān)的參數(shù)
性能調(diào)整相關(guān)參數(shù)
Debug參數(shù)
proxies：代理配置段
defaults：為frontend, listen, backend提供默認配置；
frontend：前端，相當(dāng)于nginx, server {}
backend：后端，相當(dāng)于nginx, upstream {}
listen：同時擁前端和后端
查看配置文件
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
重要的幾個參數(shù)，及性能調(diào)優(yōu)，多數(shù)無需修改
log：定義全局的syslog服務(wù)器；最多可以定義兩個；
log <address> [len <length>] <facility> [max level [min level]]
nbproc <number>：要啟動的haproxy的進程數(shù)量；
ulimit-n <number>：每個haproxy進程可打開的最大文件數(shù)；
maxconn <number>：設(shè)定每個haproxy進程所能接受的最大并發(fā)連接數(shù)；
最大的并發(fā)連接數(shù)=nbproc * maxconn
maxconnrate <number>：每個進程每秒種所能創(chuàng)建的最大連接數(shù)量；
maxcomprate ：壓縮創(chuàng)建的速率
maxsessrate <number>：進程每秒能創(chuàng)建的會話數(shù)量
maxsslconn <number>:每個進程所能接受的ssl連接數(shù)
spread-checks <0..50, in percent>：散開監(jiān)控狀態(tài)檢測
發(fā)現(xiàn)日志發(fā)送給本機rsyslog的local2的facility，而本機的rsyslog里并沒有定義，需要我們自己去配置
所以vim /etc/rsyslog.conf添加一段將local2的所有信息記錄在對應(yīng)日志文件中
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
local2.* /var/log/haproxy.log
ACL規(guī)則
由于HAProxy可以工作在七層模型下，因此，要實現(xiàn)HAProxy的強大功能，一定要使用強大靈活的ACL規(guī)則，通過ACL規(guī)則可以實現(xiàn)基于HAProxy的智能負載均衡系統(tǒng)。HAProxy通過ACL規(guī)則完成兩種主要的功能，分別是：
1）通過設(shè)置的ACL規(guī)則檢查客戶端請求是否合法。如果符合ACL規(guī)則要求，那么將放行；如果不符合規(guī)則，則直接中斷請求。
2）符合ACL規(guī)則要求的請求將被提交到后端的backend服務(wù)器集群，進而實現(xiàn)基于ACL規(guī)則的負載均衡。HAProxy中的ACL規(guī)則經(jīng)常使用在frontend段中，使用方法如下：
acl 自定義的acl 名稱 acl 方法 -i [ 匹配的路徑或文件] 其中：
·acl：是一個關(guān)鍵字，表示定義ACL規(guī)則的開始。后面需要跟上自定義的ACL名稱。
·acl方法：這個字段用來定義實現(xiàn)ACL的方法，HAProxy定義了很多ACL方法，經(jīng)常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。
·-i：表示不區(qū)分大小寫，后面需要跟上匹配的路徑或文件或正則表達式。與ACL規(guī)則一起使用的HAProxy參數(shù)還有use_backend，use_backend后面需要跟上一個backend實例名，表示在滿足ACL規(guī)則后去請求哪個backend實例，與use_backend對應(yīng)的還有default_backend參數(shù)，它表示在沒有滿足ACL條件的時候默認使用哪個后端
acl www_policy hdr_reg(host) -i ^(www.z.cn|z.cn)
acl bbs_policy hdr_dom(host) -i bbs.z.cn
acl url_policy url_sub -i buy_sid=
use_backend server_www if www_policy
use_backend server_app if url_policy
use_backend server_bbs if bbs_policy
default_backend server_cache
這些例子定義了www_policy、bbs_policy、url_policy三個ACL規(guī)則，第一條規(guī)則表示如果客戶端以www.z.cn或z.cn開頭的域名發(fā)送請求時，則此規(guī)則返回true，同理第二條規(guī)則表示如果客戶端通過bbs.z.cn域名發(fā)送請求時，則此規(guī)則返回true，而第三條規(guī)則表示如果客戶端在請求的URL中包含“buy_sid=”字符串時，則此規(guī)則返回true。
第四、第五、第六條規(guī)則定義了當(dāng)www_policy、bbs_policy、url_policy三個ACL規(guī)則返回true時要調(diào)度到哪個后端backend，例如，當(dāng)用戶的請求滿足www_policy規(guī)則時，那么HAProxy會將用戶的請求直接發(fā)往名為server_www的后端backend，其他以此類推。而當(dāng)用戶的請求不滿足任何一個ACL規(guī)則時，HAProxy就會把請求發(fā)往由default_backend選項指定的server_cache這個后端backend。
acl host_www hdr_beg(host) -i www
acl host_static hdr_beg(host) -i img. video. download. ftp.
use_backend static if host_static || host_www url_static
use_backend www if host_www
default_backend server_cache
與上面的例子類似，本例中也定義了url_static、host_www和host_static三個ACL規(guī)則，其中，第一條規(guī)則通過path_end參數(shù)定義了如果客戶端在請求的URL中以.gif、.png、.jpg、.css或.js結(jié)尾時返回true，第二條規(guī)則通過hdr_beg（host）參數(shù)定義了如果客戶端以www開頭的域名發(fā)送請求時則返回true，同理，第三條規(guī)則也是通過hdr_beg（host）參數(shù)定義了如果客戶端以img.、video.、download.或ftp.開頭的域名發(fā)送請求時則返回true。
第四、第五條規(guī)則定義了當(dāng)滿足ACL規(guī)則后要調(diào)度到哪個后端backend，例如，當(dāng)用戶的請求同時滿足host_static規(guī)則與url_static規(guī)則，或同時滿足host_www和url_static規(guī)則時，那么會將用戶請求直接發(fā)往名為static的后端backend，如果用戶請求滿足host_www規(guī)則，那么請求將被調(diào)度到名為www的后端backend，如果不滿足所有規(guī)則，那么將用戶請求默認調(diào)度到名為server_cache的這個后端backend。
global部分
log：全局的日志配置，local0是日志設(shè)備，info表示日志級別。其中日志級別有err、warning、info、debug4種可選。這個配置表示使用127.0.0.1上的rsyslog服務(wù)中的local0日志設(shè)備，記錄日志等級為info。
maxconn：設(shè)定每個HAProxy進程可接受的最大并發(fā)連接數(shù)，此選項等同于Linux命令行選項“ulimit -n”。
user/group：設(shè)置運行HAProxy進程的用戶和組，也可使用用戶和組的uid和gid值來替代。
daemon：設(shè)置HAProxy進程進入后臺運行。這是推薦的運行模式。
nbproc：設(shè)置HAProxy啟動時可創(chuàng)建的進程數(shù)，此參數(shù)要求將HAProxy運行模式設(shè)置為daemon，默認只啟動一個進程。該值的設(shè)置應(yīng)該小于服務(wù)器的CPU核數(shù)。創(chuàng)建多個進程，能夠減少每個進程的任務(wù)隊列，但是過多的進程可能會導(dǎo)致進程崩潰。
pidfile：指定HAProxy進程的pid文件。啟動進程的用戶必須有訪問此文件的權(quán)限。
defaults部分
mode：設(shè)置HAProxy實例默認的運行模式，有tcp、http、health三個可選值。
- TCP模式：在此模式下，客戶端和服務(wù)器端之間將建立一個全雙工的連接，不會對七層報文做任何類型的檢查，默認為tcp模式，經(jīng)常用于SSL、SSH、SMTP等應(yīng)用。
- http模式：在此模式下，客戶端請求在轉(zhuǎn)發(fā)至后端服務(wù)器之前將會被深度分析，所有不與RFC格式兼容的請求都會被拒絕。
- health模式：目前此模式基本已經(jīng)廢棄，不再多說。
retries：設(shè)置連接后端服務(wù)器的失敗重試次數(shù)，如果連接失敗的次數(shù)超過這里設(shè)置的值，HAProxy會將對應(yīng)的后端服務(wù)器標(biāo)記為不可用。此參數(shù)也可在后面部分進行設(shè)置。
timeout connect：設(shè)置成功連接到一臺服務(wù)器的最長等待時間，默認單位是毫秒，但也可以使用其他的時間單位后綴。
timeout client：設(shè)置連接客戶端發(fā)送數(shù)據(jù)時最長等待時間，默認單位是毫秒，也可以使用其他的時間單位后綴。
timeout server：設(shè)置服務(wù)器端回應(yīng)客戶端數(shù)據(jù)發(fā)送的最長等待時間，默認單位是毫秒，也可以使用其他的時間單位后綴。
timeout check：設(shè)置對后端服務(wù)器的檢測超時時間，默認單位是毫秒，也可以使用其他的時間單位后綴。
frontend部分
bind：此選項只能在frontend和listen部分進行定義，用于定義一個或幾個監(jiān)聽的套接字。bind的使用格式為： bind [<address>:<port_range>] interface <interface>其可以為主機名或IP地址，如果將其設(shè)置為“*”或“0.0.0.0”，將監(jiān)聽當(dāng)前系統(tǒng)的所有IPv4地址。port_range可以是一個特定的TCP端口，也可是一個端口范圍，小于1024的端口需要有特定權(quán)限的用戶才能使用。interface為可選選項，用來指定網(wǎng)絡(luò)接口的名稱，只能在Linux系統(tǒng)上使用。
option httplog：在默認情況下，HAProxy日志是不記錄HTTP請求的，這樣很不方便HAProxy問題的排查與監(jiān)控。通過此選項可以啟用日志記錄HTTP請求。
option forwardfor：如果后端服務(wù)器需要獲得客戶端的真實IP，就需要配置此參數(shù)。由于HAProxy工作于反向代理模式，因此發(fā)往后端真實服務(wù)器的請求中的客戶端IP均為HAProxy主機的IP，而非真正訪問客戶端的地址，這就導(dǎo)致真實服務(wù)器端無法記錄客戶端真正請求來源的IP，而X-Forwarded-For則可用于解決此問題。通過使用forwardfor選項，HAProxy就可以向每個發(fā)往后端真實服務(wù)器的請求添加X-Forwarded-For記錄，這樣后端真實服務(wù)器日志可以通過“X-Forwarded-For”信息來記錄客戶端來源IP。
option httpclose：此選項表示在客戶端和服務(wù)器端完成一次連接請求后，HAProxy將主動關(guān)閉此TCP連接。這是對性能非常有幫助的一個參數(shù)。
log global：表示使用全局的日志配置，這里的global表示引用在HAProxy配置文件global部分中定義的log選項配置格式。
default_backend：指定默認的后端服務(wù)器池，也就是指定一組后端真實服務(wù)器，而這些真實服務(wù)器組將在backend段進行定義。這里的htmpool就是一個后端服務(wù)器組。
backend部分
option redispatch：此參數(shù)用于cookie保持的環(huán)境中。在默認情況下，HAProxy會將其請求的后端服務(wù)器的serverID插入cookie中，以保證會話的session持久性。而如果后端的服務(wù)器出現(xiàn)故障，客戶端的cookie是不會刷新的，這就會出現(xiàn)問題。此時，如果設(shè)置此參數(shù)，就會將客戶的請求強制定向到另外一臺健康的后端服務(wù)器上，以保證服務(wù)正常。
option abortonclose：如果設(shè)置了此參數(shù)，可以在服務(wù)器負載很高的情況下，自動結(jié)束當(dāng)前隊列中處理時間比較長的連接。
-balance：此關(guān)鍵字用來定義負載均衡算法。目前HAProxy支持多種負載均衡算法，常用的有如下幾種：
- roundrobin：是基于權(quán)重進行輪叫調(diào)度的算法，在服務(wù)器的性能分布比較均勻時，這是一種最公平、最合理的算法。此算法使用頻繁。
- static-rr：也是基于權(quán)重進行輪叫的調(diào)度算法，不過此算法為靜態(tài)方法，在運行時調(diào)整其服務(wù)器權(quán)重不會生效。
- source：是基于請求源IP的算法。此算法先對請求的源IP進行hash運算，然后將結(jié)果與后端服務(wù)器的權(quán)重總數(shù)相除后轉(zhuǎn)發(fā)至某臺匹配的后端服務(wù)器。這種方式可以使同一個客戶端IP的請求始終被轉(zhuǎn)發(fā)到某特定的后端服務(wù)器。
- leastconn：此算法會將新的連接請求轉(zhuǎn)發(fā)到具有最少連接數(shù)目的后端服務(wù)器。在會話時間較長的場景中推薦使用此算法，例如數(shù)據(jù)庫負載均衡等。此算法不適合會話較短的環(huán)境中，例如基于HTTP的應(yīng)用。
- uri：此算法會對部分或整個URI進行hash運算，再經(jīng)過與服務(wù)器的總權(quán)重相除，最后轉(zhuǎn)發(fā)到某臺匹配的后端服務(wù)器上。
- uri_param：此算法會根據(jù)URL路徑中的參數(shù)進行轉(zhuǎn)發(fā)，這樣可保證在后端真實服務(wù)器數(shù)量不變時，同一個用戶的請求始終分發(fā)到同一臺機器上。
- hdr（<name>）：此算法根據(jù)http頭進行轉(zhuǎn)發(fā)，如果指定的http頭名稱不存在，則使用roundrobin算法進行策略轉(zhuǎn)發(fā)。
cookie：表示允許向cookie插入SERVERID，每臺服務(wù)器的SERVERID可在下面的server關(guān)鍵字中使用cookie關(guān)鍵字定義。
option httpchk：此選項表示啟用HTTP的服務(wù)狀態(tài)檢測功能。HAProxy作為一個專業(yè)的負載均衡器，它支持對backend部分指定的后端服務(wù)節(jié)點的健康檢查，以保證在后端backend中某個節(jié)點不能服務(wù)時，把從frotend端進來的客戶端請求分配至backend中其他健康節(jié)點上，從而保證整體服務(wù)的可用性。
option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各個參數(shù)的含義如下：
- method：表示HTTP請求的方式，常用的有OPTIONS、GET、HEAD幾種方式。一般的健康檢查可以采用HEAD方式進行，而不是采用GET方式，這是因為HEAD方式?jīng)]有數(shù)據(jù)返回，僅檢查Response的HEAD是不是狀態(tài)碼200。因此，相對于GET，HEAD方式更快、更簡單。
- uri：表示要檢測的URL地址，通過執(zhí)行此URL，可以獲取后端服務(wù)器的運行狀態(tài)。在正常情況下將返回狀態(tài)碼200，返回其他狀態(tài)碼均為異常狀態(tài)。
- version：指定心跳檢測時的HTTP的版本號。
server：這個關(guān)鍵字用來定義多臺后端真實服務(wù)器，不能用于defaults和frontend部分。使用格式為： server <name> <address>[:port] [param*] 其中，每個參數(shù)含義如下： - <name>：為后端真實服務(wù)器指定一個內(nèi)部名稱，隨便定義一個即可。
- <address>：后端真實服務(wù)器的IP地址或主機名。
- <port>：指定連接請求發(fā)往真實服務(wù)器時的目標(biāo)端口。在未設(shè)定時，將使用客戶端請求時的同一端口。
- [param*]：為后端服務(wù)器設(shè)定的一系列參數(shù)，可用參數(shù)非常多，這里僅介紹常用的一些參數(shù)：
check：表示啟用對此后端服務(wù)器執(zhí)行健康狀態(tài)檢查。
inter：設(shè)置健康狀態(tài)檢查的時間間隔，單位為毫秒。
rise：設(shè)置從故障狀態(tài)轉(zhuǎn)換至正常狀態(tài)需要成功檢查的次數(shù)，例如，“rise 2”表示2次檢查正確就認為此服務(wù)器可用。
fall：設(shè)置后端服務(wù)器從正常狀態(tài)轉(zhuǎn)換為不可用狀態(tài)需要檢查的次數(shù)，例如，“fall 3”表示3次檢查失敗就認為此服務(wù)器不可用。
cookie：為指定的后端服務(wù)器設(shè)定cookie值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的后端服務(wù)器將在后續(xù)的請求中一直被選中，其目的在于實現(xiàn)持久連接的功能。上面的“cookie server1”表示web1的serverid為server1。同理，“cookie server2”表示web2的serverid為server2。
weight：設(shè)置后端真實服務(wù)器的權(quán)重，默認為1，最大值為256。設(shè)置為0表示不參與負載均衡。
backup：設(shè)置后端真實服務(wù)器的備份服務(wù)器，僅僅在后端所有真實服務(wù)器均不可用的情況下才啟用。
通過ACL智能負載均衡動靜分離
rontend web *:80
compression algo gzip
compression type text/html text/plain /application/xml application/javascript
acl static path_end .jpg .jpeg.png .gif .txt .html .css .javascript .
js #定義靜態(tài)acl匹配規(guī)則，后綴匹配
acl static path_beg /imgs /css /javascripts #定義靜態(tài)acl匹配規(guī)則，前綴匹配
use_backend staticsrvs if static #使用靜態(tài)acl匹配規(guī)則
default_backend dynsrvs #未匹配到acl的，使用默認后端主機，動態(tài)內(nèi)容
backend dynsrvs #動態(tài)主機組
cookie SRV insert indirect nocache #啟用cookie綁定
server dynsrv1 192.168.31.204:80 check cookie dynsrv1
backend staticsrvs #靜態(tài)主機組
server staticsrv1 192.168.31.203:80 check
listen stats
bind *:9099
stats enable
stats uri /myproxy?admin #自定義信息頁地址
stats realm "HAProxy Stats Page" #認證提示
stats auth admin:admin #認證時用的用戶名和密碼
stats admin if TRUE #啟用信息頁管理功能，總是為真
4、LNMT實現(xiàn)動靜分離實戰(zhàn)
用nginx反代后端的兩臺tomcat主機，做動靜分離，如果是jsp結(jié)尾的就發(fā)往后端，否則就交給nginx處理。
在兩臺tomcat主機上創(chuàng)建應(yīng)用
mkdir -pv /var/lib/tomcat/webapps/test/{WEB-INF,META-INF,calsses,lib}
然后創(chuàng)建應(yīng)用程序jsp文件
在A主機上
<%@ page language="java" %>
<html>
<head><title>TomcatA</title></head>
<body>
<h1><font color="red">TomcatA.magedu.com</font></h1>
<table align="centre" border="1">
<tr>
<td>Session ID</td>
<% session.setAttribute("magedu.com","magedu.com"); %>
<td><%= session.getId() %></td>
</tr>
<tr>
<td>Created on</td>
<td><%= session.getCreationTime() %></td>
</tr>
</table>
</body>
</html>
在B主機上
<%@ page language="java" %>
<html>
<head><title>TomcatB</title></head>
<body>
<h1><font color="blue">TomcatB.magedu.com</font></h1>
<table align="centre" border="1">
<tr>
<td>Session ID</td>
<% session.setAttribute("magedu.com","magedu.com"); %>
<td><%= session.getId() %></td>
</tr>
<tr>
<td>Created on</td>
<td><%= session.getCreationTime() %></td>
</tr>
</table>
</body>
</html>
nginx配置
upstream tcservs {
hash $request_uri consistent; #使用uri一致性哈希算法保持會話粘性
#hash $cookie_name consistent 對cookie做哈希也可以
server 192.168.31.203:8080;
server 192.168.31.204:8080;
}
vim /etc/nginx/conf.d/lvqin.conf
server {
listen 80;
server_name node1.lvqing.com;
location ~* \.(jsp|do)$ {
proxy_pass http://tcservs;
}
}
則動靜分離就實現(xiàn)了，并且我們還基于uri實現(xiàn)了會話粘性
