業(yè)務(wù)專線：13711534025
上一篇：《大型網(wǎng)站架構(gòu)系列：負(fù)載均衡詳解（上）》
一、軟件負(fù)載均衡概述
硬件負(fù)載均衡性能優(yōu)越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟件負(fù)載均衡在互聯(lián)網(wǎng)領(lǐng)域大量使用。常用的軟件負(fù)載均衡軟件有Nginx，Lvs，HaProxy等。
二、Ngnix負(fù)載均衡
Ngnix是一款輕量級的Web服務(wù)器/反向代理服務(wù)器，工作在七層Http協(xié)議的負(fù)載均衡系統(tǒng)。具有高性能、高并發(fā)、低內(nèi)存使用等特點(diǎn)。是一個輕量級的Http和反向代理服務(wù)器。Nginx使用epoll and kqueue作為開發(fā)模型。能夠支持高達(dá) 50,000 個并發(fā)連接數(shù)的響應(yīng)。
操作系統(tǒng)：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）
開發(fā)語言：C
并發(fā)性能：官方支持每秒5萬并發(fā)，實際國內(nèi)一般到每秒2萬并發(fā)，有優(yōu)化到每秒10萬并發(fā)的。具體性能看應(yīng)用場景。
2.1.特點(diǎn)
1.模塊化設(shè)計：良好的擴(kuò)展性，可以通過模塊方式進(jìn)行功能擴(kuò)展。
2.高可靠性：主控進(jìn)程和worker是同步實現(xiàn)的，一個worker出現(xiàn)問題，會立刻啟動另一個worker。
3.內(nèi)存消耗低：一萬個長連接（keep-alive）,僅消耗2.5MB內(nèi)存。
4.支持熱部署：不用停止服務(wù)器，實現(xiàn)更新配置文件，更換日志文件、更新服務(wù)器程序版本。
5.并發(fā)能力強(qiáng)：官方數(shù)據(jù)每秒支持5萬并發(fā)；
6.功能豐富：優(yōu)秀的反向代理功能和靈活的負(fù)載均衡策略
2.2.功能
2.2.1基本功能
支持靜態(tài)資源的web服務(wù)器。
http,smtp,pop3協(xié)議的反向代理服務(wù)器、緩存、負(fù)載均衡；
支持FASTCGI（fpm）
支持模塊化，過濾器（讓文本可以實現(xiàn)壓縮，節(jié)約帶寬）,ssl及圖像大小調(diào)整。
內(nèi)置的健康檢查功能
基于名稱和ip的虛擬主機(jī)
定制訪問日志
支持平滑升級
支持KEEPALIVE
支持url rewrite
支持路徑別名
支持基于IP和用戶名的訪問控制。
支持傳輸速率限制，支持并發(fā)數(shù)限制。
2.2.2擴(kuò)展功能
2.2.3性能
Nginx的高并發(fā)，官方測試支持5萬并發(fā)連接。實際生產(chǎn)環(huán)境能到2-3萬并發(fā)連接數(shù)。10000個非活躍的HTTP keep-alive 連接僅占用約2.5MB內(nèi)存。三萬并發(fā)連接下，10個Nginx進(jìn)程，消耗內(nèi)存150M。淘寶tengine團(tuán)隊測試結(jié)果是“24G內(nèi)存機(jī)器上，處理并發(fā)請求可達(dá)200萬”。
2.3架構(gòu)
2.3.1Nginx的基本工作模式
一個master進(jìn)程，生成一個或者多個worker進(jìn)程。但是這里master是使用root身份啟動的，因為nginx要工作在80端口。而只有管理員才有權(quán)限啟動小于低于1023的端口。master主要是負(fù)責(zé)的作用只是啟動worker，加載配置文件，負(fù)責(zé)系統(tǒng)的平滑升級。其它的工作是交給worker。那么當(dāng)worker被啟動之后，也只是負(fù)責(zé)一些web最簡單的工作，而其他的工作都是有worker中調(diào)用的模塊來實現(xiàn)的。
模塊之間是以流水線的方式實現(xiàn)功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現(xiàn)完成的。比如：第一個模塊只負(fù)責(zé)分析請求首部，第二個模塊只負(fù)責(zé)查找數(shù)據(jù)，第三個模塊只負(fù)責(zé)壓縮數(shù)據(jù)，依次完成各自工作。來實現(xiàn)整個工作的完成。
他們是如何實現(xiàn)熱部署的呢？其實是這樣的，我們前面說master不負(fù)責(zé)具體的工作，而是調(diào)用worker工作，他只是負(fù)責(zé)讀取配置文件，因此當(dāng)一個模塊修改或者配置文件發(fā)生變化，是由master進(jìn)行讀取，因此此時不會影響到worker工作。在master進(jìn)行讀取配置文件之后，不會立即的把修改的配置文件告知worker。而是讓被修改的worker繼續(xù)使用老的配置文件工作，當(dāng)worker工作完畢之后，直接當(dāng)?shù)暨@個子進(jìn)程，更換新的子進(jìn)程，使用新的規(guī)則。
2.3.2Nginx支持的sendfile機(jī)制
Sendfile機(jī)制，用戶將請求發(fā)給內(nèi)核，內(nèi)核根據(jù)用戶的請求調(diào)用相應(yīng)用戶進(jìn)程，進(jìn)程在處理時需要資源。此時再把請求發(fā)給內(nèi)核（進(jìn)程沒有直接IO的能力），由內(nèi)核加載數(shù)據(jù)。內(nèi)核查找到數(shù)據(jù)之后，會把數(shù)據(jù)復(fù)制給用戶進(jìn)程，由用戶進(jìn)程對數(shù)據(jù)進(jìn)行封裝，之后交給內(nèi)核，內(nèi)核在進(jìn)行tcp/ip首部的封裝，最后再發(fā)給客戶端。這個功能用戶進(jìn)程只是發(fā)生了一個封裝報文的過程，卻要繞一大圈。因此nginx引入了sendfile機(jī)制，使得內(nèi)核在接受到數(shù)據(jù)之后，不再依靠用戶進(jìn)程給予封裝，而是自己查找自己封裝，減少了一個很長一段時間的浪費(fèi)，這是一個提升性能的核心點(diǎn)。
以上內(nèi)容摘自網(wǎng)友發(fā)布的文章，簡單一句話是資源的處理，直接通過內(nèi)核層進(jìn)行數(shù)據(jù)傳遞，避免了數(shù)據(jù)傳遞到應(yīng)用層，應(yīng)用層再傳遞到內(nèi)核層的開銷。
目前高并發(fā)的處理，一般都采用sendfile模式。通過直接操作內(nèi)核層數(shù)據(jù)，減少應(yīng)用與內(nèi)核層數(shù)據(jù)傳遞。
2.3.3Nginx通信模型（I/O復(fù)用機(jī)制）
開發(fā)模型：epoll和kqueue。
支持的事件機(jī)制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。
支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用數(shù)據(jù)的數(shù)量，錯誤代碼.
支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.
以上概念較多，大家自行百度或谷歌，知識領(lǐng)域是網(wǎng)絡(luò)通信（BIO,NIO,AIO）和多線程方面的知識。
2.4均衡策略
nginx的負(fù)載均衡策略可以劃分為兩大類：內(nèi)置策略和擴(kuò)展策略。內(nèi)置策略包含加權(quán)輪詢和ip hash，在默認(rèn)情況下這兩種策略會編譯進(jìn)nginx內(nèi)核，只需在nginx配置中指明參數(shù)即可。擴(kuò)展策略有很多，如fair、通用hash、consistent hash等，默認(rèn)不編譯進(jìn)nginx內(nèi)核。由于在nginx版本升級中負(fù)載均衡的代碼沒有本質(zhì)性的變化，因此下面將以nginx1.0.15穩(wěn)定版為例，從源碼角度分析各個策略。
2.4.1. 加權(quán)輪詢（weighted round robin）
輪詢的原理很簡單，首先我們介紹一下輪詢的基本流程。如下是處理一次請求的流程圖：
圖中有兩點(diǎn)需要注意：
第一，如果可以把加權(quán)輪詢算法分為先深搜索和先廣搜索，那么nginx采用的是先深搜索算法，即將首先將請求都分給高權(quán)重的機(jī)器，直到該機(jī)器的權(quán)值降到了比其他機(jī)器低，才開始將請求分給下一個高權(quán)重的機(jī)器；
第二，當(dāng)所有后端機(jī)器都down掉時，nginx會立即將所有機(jī)器的標(biāo)志位清成初始狀態(tài)，以避免造成所有的機(jī)器都處在timeout的狀態(tài)，從而導(dǎo)致整個前端被夯住。
2.4.2. ip hash
ip hash是nginx內(nèi)置的另一個負(fù)載均衡的策略，流程和輪詢很類似，只是其中的算法和具體的策略有些變化，如下圖所示：
2.4.3. fair
fair策略是擴(kuò)展策略，默認(rèn)不被編譯進(jìn)nginx內(nèi)核。其原理是根據(jù)后端服務(wù)器的響應(yīng)時間判斷負(fù)載情況，從中選出負(fù)載最輕的機(jī)器進(jìn)行分流。這種策略具有很強(qiáng)的自適應(yīng)性，但是實際的網(wǎng)絡(luò)環(huán)境往往不是那么簡單，因此要慎用。
2.4.4 通用hash、一致性hash
這兩種也是擴(kuò)展策略，在具體的實現(xiàn)上有些差別，通用hash比較簡單，可以以nginx內(nèi)置的變量為key進(jìn)行hash，一致性hash采用了nginx內(nèi)置的一致性hash環(huán)，可以支持memcache。
2.5場景
Ngnix一般作為入口負(fù)載均衡或內(nèi)部負(fù)載均衡，結(jié)合反向代理服務(wù)器使用。以下架構(gòu)示例，僅供參考，具體使用根據(jù)場景而定。
2.5.1入口負(fù)載均衡架構(gòu)
Ngnix服務(wù)器在用戶訪問的最前端。根據(jù)用戶請求再轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器或二級負(fù)載均衡服務(wù)器（LVS）
2.5.2內(nèi)部負(fù)載均衡架構(gòu)
LVS作為入口負(fù)載均衡，將請求轉(zhuǎn)發(fā)到二級Ngnix服務(wù)器，Ngnix再根據(jù)請求轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器。
2.5.3Ngnix高可用
分布式系統(tǒng)中，應(yīng)用只部署一臺服務(wù)器會存在單點(diǎn)故障，負(fù)載均衡同樣有類似的問題。一般可采用主備或負(fù)載均衡設(shè)備集群的方式節(jié)約單點(diǎn)故障或高并發(fā)請求分流。
Ngnix高可用，至少包含兩個Ngnix服務(wù)器，一臺主服務(wù)器，一臺備服務(wù)器，之間使用Keepalived做健康監(jiān)控和故障檢測。開放VIP端口，通過防火墻進(jìn)行外部映射。
DNS解析公網(wǎng)的IP實際為VIP。
三、LVS負(fù)載均衡
LVS是一個開源的軟件，由畢業(yè)于國防科技大學(xué)的章文嵩博士于1998年5月創(chuàng)立，用來實現(xiàn)Linux平臺下的簡單負(fù)載均衡。LVS是Linux Virtual Server的縮寫，意思是Linux虛擬服務(wù)器。
基于IP層的負(fù)載均衡調(diào)度技術(shù)，它在操作系統(tǒng)核心層上，將來自IP層的TCP/UDP請求均衡地轉(zhuǎn)移到不同的 服務(wù)器，從而將一組服務(wù)器構(gòu)成一個高性能、高可用的虛擬服務(wù)器。
操作系統(tǒng)：Liunx
開發(fā)語言：C
并發(fā)性能：默認(rèn)4096，可以修改但需要重新編譯。
3.1.功能
LVS的主要功能是實現(xiàn)IP層（網(wǎng)絡(luò)層）負(fù)載均衡，有NAT,TUN,DR三種請求轉(zhuǎn)發(fā)模式。
3.1.1LVS/NAT方式的負(fù)載均衡集群
NAT是指Network Address Translation，它的轉(zhuǎn)發(fā)流程是：Director機(jī)器收到外界請求，改寫數(shù)據(jù)包的目標(biāo)地址，按相應(yīng)的調(diào)度算法將其發(fā)送到相應(yīng)Real Server上，Real Server處理完該請求后，將結(jié)果數(shù)據(jù)包返回到其默認(rèn)網(wǎng)關(guān)，即Director機(jī)器上，Director機(jī)器再改寫數(shù)據(jù)包的源地址，最后將其返回給外界。這樣就完成一次負(fù)載調(diào)度。
構(gòu)架一個最簡單的LVS/NAT方式的負(fù)載均衡集群Real Server可以是任何的操作系統(tǒng)，而且無需做任何特殊的設(shè)定，惟一要做的就是將其默認(rèn)網(wǎng)關(guān)指向Director機(jī)器。Real Server可以使用局域網(wǎng)的內(nèi)部IP(192.168.0.0/24)。Director要有兩塊網(wǎng)卡，一塊網(wǎng)卡綁定一個外部IP地址 (10.0.0.1)，另一塊網(wǎng)卡綁定局域網(wǎng)的內(nèi)部IP(192.168.0.254)，作為Real Server的默認(rèn)網(wǎng)關(guān)。
LVS/NAT方式實現(xiàn)起來最為簡單，而且Real Server使用的是內(nèi)部IP，可以節(jié)省Real IP的開銷。但因為執(zhí)行NAT需要重寫流經(jīng)Director的數(shù)據(jù)包，在速度上有一定延遲；
當(dāng)用戶的請求非常短，而服務(wù)器的回應(yīng)非常大的情況下，會對Director形成很大壓力，成為新的瓶頸，從而使整個系統(tǒng)的性能受到限制。
3.1.2LVS/TUN方式的負(fù)載均衡集群
TUN是指IP Tunneling，它的轉(zhuǎn)發(fā)流程是：
Director機(jī)器收到外界請求，按相應(yīng)的調(diào)度算法,通過IP隧道發(fā)送到相應(yīng)Real Server，Real Server處理完該請求后，將結(jié)果數(shù)據(jù)包直接返回給客戶。至此完成一次負(fù)載調(diào)度。
最簡單的LVS/TUN方式的負(fù)載均衡集群架構(gòu)使用IP Tunneling技術(shù)，在Director機(jī)器和Real Server機(jī)器之間架設(shè)一個IP Tunnel，通過IP Tunnel將負(fù)載分配到Real Server機(jī)器上。Director和Real Server之間的關(guān)系比較松散，可以是在同一個網(wǎng)絡(luò)中，也可以是在不同的網(wǎng)絡(luò)中，只要兩者能夠通過IP Tunnel相連就行。收到負(fù)載分配的Real Server機(jī)器處理完后會直接將反饋數(shù)據(jù)送回給客戶，而不必通過Director機(jī)器。實際應(yīng)用中，服務(wù)器必須擁有正式的IP地址用于與客戶機(jī)直接通信，并且所有服務(wù)器必須支持IP隧道協(xié)議。
該方式中Director將客戶請求分配到不同的Real Server，Real Server處理請求后直接回應(yīng)給用戶，這樣Director就只處理客戶機(jī)與服務(wù)器的一半連接，極大地提高了Director的調(diào)度處理能力，使集群系統(tǒng)能容納更多的節(jié)點(diǎn)數(shù)。另外TUN方式中的Real Server可以在任何LAN或WAN上運(yùn)行，這樣可以構(gòu)筑跨地域的集群，其應(yīng)對災(zāi)難的能力也更強(qiáng)，但是服務(wù)器需要為IP封裝付出一定的資源開銷，而且后端的Real Server必須是支持IP Tunneling的操作系統(tǒng)。
3.3.3LVS/TUN方式的負(fù)載均衡集群
DR是指Direct Routing，它的轉(zhuǎn)發(fā)流程是：
Director機(jī)器收到外界請求，按相應(yīng)的調(diào)度算法將其直接發(fā)送到相應(yīng)Real Server，Real Server處理完該請求后，將結(jié)果數(shù)據(jù)包直接返回給客戶，完成一次負(fù)載調(diào)度。
構(gòu)架一個最簡單的LVS/DR方式的負(fù)載均衡集群Real Server和Director都在同一個物理網(wǎng)段中，Director的網(wǎng)卡IP是192.168.0.253，再綁定另一個IP： 192.168.0.254作為對外界的virtual IP，外界客戶通過該IP來訪問整個集群系統(tǒng)。Real Server在lo上綁定IP：192.168.0.254，同時加入相應(yīng)的路由。
LVS/DR方式與前面的LVS/TUN方式有些類似，前臺的Director機(jī)器也是只需要接收和調(diào)度外界的請求，而不需要負(fù)責(zé)返回這些請求的反饋結(jié)果，所以能夠負(fù)載更多的Real Server，提高Director的調(diào)度處理能力，使集群系統(tǒng)容納更多的Real Server。但LVS/DR需要改寫請求報文的MAC地址，所以所有服務(wù)器必須在同一物理網(wǎng)段內(nèi)。
3.3架構(gòu)
LVS架設(shè)的服務(wù)器集群系統(tǒng)有三個部分組成：最前端的負(fù)載均衡層（Loader Balancer），中間的服務(wù)器群組層，用Server Array表示，最底層的數(shù)據(jù)共享存儲層，用Shared Storage表示。在用戶看來所有的應(yīng)用都是透明的，用戶只是在使用一個虛擬服務(wù)器提供的高性能服務(wù)。
LVS的體系架構(gòu)如圖：
LVS的各個層次的詳細(xì)介紹：
Load Balancer層：位于整個集群系統(tǒng)的最前端，有一臺或者多臺負(fù)載調(diào)度器（Director Server）組成，LVS模塊就安裝在Director Server上，而Director的主要作用類似于一個路由器，它含有完成LVS功能所設(shè)定的路由表，通過這些路由表把用戶的請求分發(fā)給Server Array層的應(yīng)用服務(wù)器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務(wù)的監(jiān)控模塊Ldirectord，此模塊用于監(jiān)測各個Real Server服務(wù)的健康狀況。在Real Server不可用時把它從LVS路由表中剔除，恢復(fù)時重新加入。
Server Array層：由一組實際運(yùn)行應(yīng)用服務(wù)的機(jī)器組成，Real Server可以是WEB服務(wù)器、MAIL服務(wù)器、FTP服務(wù)器、DNS服務(wù)器、視頻服務(wù)器中的一個或者多個，每個Real Server之間通過高速的LAN或分布在各地的WAN相連接。在實際的應(yīng)用中，Director Server也可以同時兼任Real Server的角色。
Shared Storage層：是為所有Real Server提供共享存儲空間和內(nèi)容一致性的存儲區(qū)域，在物理上，一般有磁盤陣列設(shè)備組成，為了提供內(nèi)容的一致性，一般可以通過NFS網(wǎng)絡(luò)文件系統(tǒng)共享數(shù) 據(jù)，但是NFS在繁忙的業(yè)務(wù)系統(tǒng)中，性能并不是很好，此時可以采用集群文件系統(tǒng)，例如Red hat的GFS文件系統(tǒng)，oracle提供的OCFS2文件系統(tǒng)等。
從整個LVS結(jié)構(gòu)可以看出，Director Server是整個LVS的核心，目前，用于Director Server的操作系統(tǒng)只能是Linux和FreeBSD，linux2.6內(nèi)核不用任何設(shè)置就可以支持LVS功能，而FreeBSD作為 Director Server的應(yīng)用還不是很多，性能也不是很好。對于Real Server，幾乎可以是所有的系統(tǒng)平臺，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。
3.4均衡策略
LVS默認(rèn)支持八種負(fù)載均衡策略，簡述如下：
3.4.1.輪詢調(diào)度（Round Robin）
調(diào)度器通過“輪詢”調(diào)度算法將外部請求按順序輪流分配到集群中的真實服務(wù)器上，它均等地對待每一臺服務(wù)器，而不管服務(wù)器上實際的連接數(shù)和系統(tǒng)負(fù)載。
3.4.2.加權(quán)輪詢（Weighted Round Robin）
調(diào)度器通過“加權(quán)輪詢”調(diào)度算法根據(jù)真實服務(wù)器的不同處理能力來調(diào)度訪問請求。這樣可以保證處理能力強(qiáng)的服務(wù)器能處理更多的訪問流量。調(diào)度器可以自動問詢真實服務(wù)器的負(fù)載情況，并動態(tài)地調(diào)整其權(quán)值。
3.4.3.最少鏈接（Least Connections）
調(diào)度器通過“最少連接”調(diào)度算法動態(tài)地將網(wǎng)絡(luò)請求調(diào)度到已建立的鏈接數(shù)最少的服務(wù)器上。如果集群系統(tǒng)的真實服務(wù)器具有相近的系統(tǒng)性能，采用“最小連接”調(diào)度算法可以較好地均衡負(fù)載。
3.4.4.加權(quán)最少鏈接（Weighted Least Connections）
在集群系統(tǒng)中的服務(wù)器性能差異較大的情況下，調(diào)度器采用“加權(quán)最少鏈接”調(diào)度算法優(yōu)化負(fù)載均衡性能，具有較高權(quán)值的服務(wù)器將承受較大比例的活動連接負(fù)載。調(diào)度器可以自動問詢真實服務(wù)器的負(fù)載情況，并動態(tài)地調(diào)整其權(quán)值。
3.4.5.基于局部性的最少鏈接（Locality-Based Least Connections）
“基于局部性的最少鏈接”調(diào)度算法是針對目標(biāo)IP地址的負(fù)載均衡，目前主要用于Cache集群系統(tǒng)。該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址最近使用的服務(wù)器，若該服務(wù)器是可用的且沒有超載，將請求發(fā)送到該服務(wù)器；若服務(wù)器不存在，或者該服務(wù)器超載且有服務(wù)器處于一半的工作負(fù)載，則用“最少鏈接” 的原則選出一個可用的服務(wù)器，將請求發(fā)送到該服務(wù)器。
3.4.6.帶復(fù)制的基于局部性最少鏈接（Locality-Based Least Connections with Replication）
“帶復(fù)制的基于局部性最少鏈接”調(diào)度算法也是針對目標(biāo)IP地址的負(fù)載均衡，目前主要用于Cache集群系統(tǒng)。它與LBLC算法的不同之處是它要維護(hù)從一個目標(biāo)IP地址到一組服務(wù)器的映射，而LBLC算法維護(hù)從一個目標(biāo)IP地址到一臺服務(wù)器的映射。該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址對應(yīng)的服務(wù)器組，按“最小連接”原則從服務(wù)器組中選出一臺服務(wù)器，若服務(wù)器沒有超載，將請求發(fā)送到該服務(wù)器；若服務(wù)器超載，則按“最小連接”原則從這個集群中選出一臺服務(wù)器，將該服務(wù)器加入到服務(wù)器組中，將請求發(fā)送到該服務(wù)器。同時，當(dāng)該服務(wù)器組有一段時間沒有被修改，將最忙的服務(wù)器從服務(wù)器組中刪除，以降低復(fù)制的程度。
3.4.7.目標(biāo)地址散列（Destination Hashing）
“目標(biāo)地址散列”調(diào)度算法根據(jù)請求的目標(biāo)IP地址，作為散列鍵（Hash Key）從靜態(tài)分配的散列表找出對應(yīng)的服務(wù)器，若該服務(wù)器是可用的且未超載，將請求發(fā)送到該服務(wù)器，否則返回空。
3.4.8.源地址散列（Source Hashing）
“源地址散列”調(diào)度算法根據(jù)請求的源IP地址，作為散列鍵（Hash Key）從靜態(tài)分配的散列表找出對應(yīng)的服務(wù)器，若該服務(wù)器是可用的且未超載，將請求發(fā)送到該服務(wù)器，否則返回空。
除具備以上負(fù)載均衡算法外，還可以自定義均衡策略。
3.5場景
一般作為入口負(fù)載均衡或內(nèi)部負(fù)載均衡，結(jié)合反向代理服務(wù)器使用。相關(guān)架構(gòu)可參考Ngnix場景架構(gòu)。
4、HaProxy負(fù)載均衡
HAProxy也是使用較多的一款負(fù)載均衡軟件。HAProxy提供高可用性、負(fù)載均衡以及基于TCP和HTTP應(yīng)用的代理，支持虛擬主機(jī)，是免費(fèi)、快速并且可靠的一種解決方案。特別適用于那些負(fù)載特大的web站點(diǎn)。運(yùn)行模式使得它可以很簡單安全的整合到當(dāng)前的架構(gòu)中，同時可以保護(hù)你的web服務(wù)器不被暴露到網(wǎng)絡(luò)上。
4.1.特點(diǎn)
支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機(jī)；
配置簡單，支持url檢測后端服務(wù)器狀態(tài)；
做負(fù)載均衡軟件使用，在高并發(fā)情況下，處理速度高于nginx；
TCP層多用于Mysql從（讀）服務(wù)器負(fù)載均衡。 （對Mysql進(jìn)行負(fù)載均衡，對后端的DB節(jié)點(diǎn)進(jìn)行檢測和負(fù)載均衡）
能夠補(bǔ)充Nginx的一些缺點(diǎn)比如Session的保持，Cookie引導(dǎo)等工作
4.2.均衡策略
支持四種常用算法：
1.roundrobin：輪詢，輪流分配到后端服務(wù)器；
2.static-rr：根據(jù)后端服務(wù)器性能分配；
3.leastconn：最小連接者優(yōu)先處理；
4.source：根據(jù)請求源IP，與Nginx的IP_Hash類似。
五、本次分享總結(jié)
以上是本周的分享，從主要講解了軟件負(fù)載均衡的應(yīng)用背景，Ngnix負(fù)載均衡，LVS負(fù)載均衡，Haproxy負(fù)載均衡。
因為時間關(guān)系，有些講解的不細(xì)致，大家可以問下度娘/Google，希望本次分享對大家有幫助。
