面試：第九章：分布式 、高并發(fā)、集群、負(fù)載均衡、高可用

分布式 :

分布式架構(gòu)：把系統(tǒng)按照模塊拆分成多個(gè)子系統(tǒng)，多個(gè)子系統(tǒng)分布在不同的網(wǎng)絡(luò)計(jì)算機(jī)上相互協(xié)作完成業(yè)務(wù)流程，系統(tǒng)之間需要進(jìn)行通信。

優(yōu)點(diǎn)：

    把模塊拆分，使用接口通信，降低模塊之間的耦合度。
    把項(xiàng)目拆分成若干個(gè)子項(xiàng)目，不同的團(tuán)隊(duì)負(fù)責(zé)不同的子項(xiàng)目。
    增加功能時(shí)只需要再增加一個(gè)子項(xiàng)目，調(diào)用其他系統(tǒng)的接口就可以。
    可以靈活的進(jìn)行分布式部署。

缺點(diǎn)：

1、系統(tǒng)之間交互需要使用遠(yuǎn)程通信，接口開(kāi)發(fā)增加工作量。

2、各個(gè)模塊有一些通用的業(yè)務(wù)邏輯無(wú)法共用。

基于soa的架構(gòu)

SOA：面向服務(wù)的架構(gòu)。也就是把工程拆分成服務(wù)層、表現(xiàn)層兩個(gè)工程。服務(wù)層中包含業(yè)務(wù)邏輯，只需要對(duì)外提供服務(wù)即可。表現(xiàn)層只需要處理和頁(yè)面的交互，業(yè)務(wù)邏輯都是調(diào)用服務(wù)層的服務(wù)來(lái)實(shí)現(xiàn)。

分布式架構(gòu)和soa架構(gòu)有什么區(qū)別？

SOA，主要還是從服務(wù)的角度，將工程拆分成服務(wù)層、表現(xiàn)層兩個(gè)工程。

分布式，主要還是從部署的角度，將應(yīng)用按照訪問(wèn)壓力進(jìn)行歸類，主要目標(biāo)是充分利用服務(wù)器的資源，避免資源分配不均

 
集群:

一個(gè)集群系統(tǒng)是一群松散結(jié)合的服務(wù)器組，形成一個(gè)虛擬的服務(wù)器，為客戶端用戶提供統(tǒng)一的服務(wù)。對(duì)于這個(gè)客戶端來(lái)說(shuō)，通常在訪問(wèn)集群系統(tǒng)時(shí)不會(huì)意識(shí)到它的服務(wù)是由具體的哪一臺(tái)服務(wù)器提供。集群的目的，是為實(shí)現(xiàn)負(fù)載均衡、容錯(cuò)和災(zāi)難恢復(fù)。以達(dá)到系統(tǒng)可用性和可伸縮性的要求。集群系統(tǒng)一般應(yīng)具高可用性、可伸縮性、負(fù)載均衡、故障恢復(fù)和可維護(hù)性等特殊性能。一般同一個(gè)工程會(huì)部署到多臺(tái)服務(wù)器上。

常見(jiàn)的tomcat集群，Redis集群，Zookeeper集群，數(shù)據(jù)庫(kù)集群

分布式與集群的區(qū)別：

分布式是指將不同的業(yè)務(wù)分布在不同的地方。 而集群指的是將幾臺(tái)服務(wù)器集中在一起，實(shí)現(xiàn)同一業(yè)務(wù)。一句話：分布式是并聯(lián)工作的，集群是串聯(lián)工作的。

分布式中的每一個(gè)節(jié)點(diǎn)，都可以做集群。 而集群并不一定就是分布式的。

舉例：就比如新浪網(wǎng)，訪問(wèn)的人多了，他可以做一個(gè)群集，前面放一個(gè)響應(yīng)服務(wù)器，后面幾臺(tái)服務(wù)器完成同一業(yè)務(wù)，如果有業(yè)務(wù)訪問(wèn)的時(shí)候，響應(yīng)服務(wù)器看哪臺(tái)服務(wù)器的負(fù)載不是很重，就將給哪一臺(tái)去完成。
而分布式，從窄意上理解，也跟集群差不多， 但是它的組織比較松散，不像集群，有一個(gè)組織性，一臺(tái)服務(wù)器垮了，其它的服務(wù)器可以頂上來(lái)。
分布式的每一個(gè)節(jié)點(diǎn)，都完成不同的業(yè)務(wù)，一個(gè)節(jié)點(diǎn)垮了，哪這個(gè)業(yè)務(wù)就不可訪問(wèn)了。

分布式是以縮短單個(gè)任務(wù)的執(zhí)行時(shí)間來(lái)提升效率的，而集群則是通過(guò)提高單位時(shí)間內(nèi)執(zhí)行的任務(wù)數(shù)來(lái)提升效率。

舉例：如果一個(gè)任務(wù)由10個(gè)子任務(wù)組成，每個(gè)子任務(wù)單獨(dú)執(zhí)行需1小時(shí)，則在一臺(tái)服務(wù)器上執(zhí)行該任務(wù)需10小時(shí)。
采用分布式方案，提供10臺(tái)服務(wù)器，每臺(tái)服務(wù)器只負(fù)責(zé)處理一個(gè)子任務(wù)，不考慮子任務(wù)間的依賴關(guān)系，執(zhí)行完這個(gè)任務(wù)只需一個(gè)小時(shí)。(這種工作模式的一個(gè)典型代表就是Hadoop的Map/Reduce分布式計(jì)算模型）
而采用集群方案，同樣提供10臺(tái)服務(wù)器，每臺(tái)服務(wù)器都能獨(dú)立處理這個(gè)任務(wù)。假設(shè)有10個(gè)任務(wù)同時(shí)到達(dá)，10個(gè)服務(wù)器將同時(shí)工作，1小時(shí)后，10個(gè)任務(wù)同時(shí)完成，這樣，整身來(lái)看，還是1小時(shí)內(nèi)完成一個(gè)任務(wù)！
高并發(fā):

處理高并發(fā)常見(jiàn)的方法有哪些？

1、HTML靜態(tài)化  freemaker
其實(shí)大家都知道，效率最高、消耗最小的就是純靜態(tài)化的html頁(yè)面，所以我們盡可能使我們的網(wǎng)站上的頁(yè)面采 用靜態(tài)頁(yè)面來(lái)實(shí)現(xiàn)，這個(gè)最簡(jiǎn)單的方法其實(shí)也是最有效的方法。但是對(duì)于大量?jī)?nèi)容并且頻繁更新的網(wǎng)站，我們無(wú)法全部手動(dòng)去挨個(gè)實(shí)現(xiàn)，于是出現(xiàn)了我們常見(jiàn)的信息 發(fā)布系統(tǒng)CMS，像我們常訪問(wèn)的各個(gè)門(mén)戶站點(diǎn)的新聞?lì)l道，甚至他們的其他頻道，都是通過(guò)信息發(fā)布系統(tǒng)來(lái)管理和實(shí)現(xiàn)的，信息發(fā)布系統(tǒng)可以實(shí)現(xiàn)最簡(jiǎn)單的信息錄 入自動(dòng)生成靜態(tài)頁(yè)面，還能具備頻道管理、權(quán)限管理、自動(dòng)抓取等功能，對(duì)于一個(gè)大型網(wǎng)站來(lái)說(shuō)，擁有一套高效、可管理的CMS是必不可少的。

除了門(mén)戶和信息發(fā)布類型的網(wǎng)站，對(duì)于交互性要求很高的社區(qū)類型網(wǎng)站來(lái)說(shuō)，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進(jìn)行實(shí)時(shí)的靜態(tài)化，有更新的時(shí)候再重新靜態(tài)化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。

同 時(shí)，html靜態(tài)化也是某些緩存策略使用的手段，對(duì)于系統(tǒng)中頻繁使用數(shù)據(jù)庫(kù)查詢但是內(nèi)容更新很小的應(yīng)用，可以考慮使用html靜態(tài)化來(lái)實(shí)現(xiàn)，比如論壇中論 壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)行后臺(tái)管理并且存儲(chǔ)再數(shù)據(jù)庫(kù)中，這些信息其實(shí)大量被前臺(tái)程序調(diào)用，但是更新頻率很小，可以考慮將這部分 內(nèi)容進(jìn)行后臺(tái)更新的時(shí)候進(jìn)行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫(kù)訪問(wèn)請(qǐng)求。

2、圖片服務(wù)器分離
大家知道，對(duì)于Web服務(wù)器來(lái)說(shuō)，不管 是 Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁(yè)面進(jìn)行分離，這是基本上大型網(wǎng)站都會(huì)采用的策略，他們都有獨(dú)立的圖片服 務(wù)器，甚至很多臺(tái)圖片服務(wù)器。這樣的架構(gòu)可以降低提供頁(yè)面訪問(wèn)請(qǐng)求的服務(wù)器系統(tǒng)壓力，并且可以保證系統(tǒng)不會(huì)因?yàn)閳D片問(wèn)題而崩潰，在應(yīng)用服務(wù)器和圖片服務(wù)器 上，可以進(jìn)行不同的配置優(yōu)化，比如apache在配置ContentType的時(shí)候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗 和執(zhí)行效率。

3、數(shù)據(jù)庫(kù)集群和庫(kù)表散列
大型網(wǎng)站都有復(fù)雜的應(yīng)用，這些應(yīng)用必須使用數(shù)據(jù)庫(kù)，那么在面對(duì)大量訪問(wèn)的時(shí)候，數(shù)據(jù)庫(kù)的瓶頸很快就能顯現(xiàn)出來(lái)，這時(shí)一臺(tái)數(shù)據(jù)庫(kù)將很快無(wú)法滿足應(yīng)用，于是我們需要使用數(shù)據(jù)庫(kù)集群或者庫(kù)表散列。

在數(shù)據(jù)庫(kù)集群方面，很多數(shù)據(jù)庫(kù)都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什么樣的DB，就參考相應(yīng)的解決方案來(lái)實(shí)施即可。

上 面提到的數(shù)據(jù)庫(kù)集群由于在架構(gòu)、成本、擴(kuò)張性方面都會(huì)受到所采用DB類型的限制，于是我們需要從應(yīng)用程序的角度來(lái)考慮改善系統(tǒng)架構(gòu)，庫(kù)表散列是常用并且最 有效的解決方案。我們?cè)趹?yīng)用程序中安裝業(yè)務(wù)和應(yīng)用或者功能模塊將數(shù)據(jù)庫(kù)進(jìn)行分離，不同的模塊對(duì)應(yīng)不同的數(shù)據(jù)庫(kù)或者表，再按照一定的策略對(duì)某個(gè)頁(yè)面或者功能 進(jìn)行更小的數(shù)據(jù)庫(kù)散列，比如用戶表，按照用戶ID進(jìn)行表散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴(kuò)展性。sohu的論壇就是采用了這樣的架 構(gòu)，將論壇的用戶、設(shè)置、帖子等信息進(jìn)行數(shù)據(jù)庫(kù)分離，然后對(duì)帖子、用戶按照板塊和ID進(jìn)行散列數(shù)據(jù)庫(kù)和表，最終可以在配置文件中進(jìn)行簡(jiǎn)單的配置便能讓系統(tǒng) 隨時(shí)增加一臺(tái)低成本的數(shù)據(jù)庫(kù)進(jìn)來(lái)補(bǔ)充系統(tǒng)性能。

4、緩存
緩存一詞搞技術(shù)的都接觸過(guò)，很多地方用到緩存。網(wǎng)站架構(gòu)和網(wǎng)站開(kāi)發(fā)中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級(jí)和分布式的緩存在后面講述。
架構(gòu)方面的緩存，對(duì)Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進(jìn)行緩存，這兩種方式均可以有效的提高Apache的訪問(wèn)響應(yīng)能力。
網(wǎng) 站程序開(kāi)發(fā)方面的緩存，Linux上提供的Memory Cache是常用的緩存接口，可以在web開(kāi)發(fā)中使用，比如用Java開(kāi)發(fā)的時(shí)候就可以調(diào)用MemoryCache對(duì)一些數(shù)據(jù)進(jìn)行緩存和通訊共享，一些大 型社區(qū)使用了這樣的架構(gòu)。另外，在使用web語(yǔ)言開(kāi)發(fā)的時(shí)候，各種語(yǔ)言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多 了，.net不是很熟悉，相信也肯定有。

5、鏡像
鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術(shù)可以解決不同網(wǎng) 絡(luò)接入商和地域帶來(lái)的用戶訪問(wèn)速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內(nèi)搭建鏡像站點(diǎn)，數(shù)據(jù)進(jìn)行定時(shí)更新或者實(shí) 時(shí)更新。在鏡像的細(xì)節(jié)技術(shù)方面，這里不闡述太深，有很多專業(yè)的現(xiàn)成的解決架構(gòu)和產(chǎn)品可選。也有廉價(jià)的通過(guò)軟件實(shí)現(xiàn)的思路，比如Linux上的rsync等 工具。

6、負(fù)載均衡
負(fù)載均衡將是大型網(wǎng)站解決高負(fù)荷訪問(wèn)和大量并發(fā)請(qǐng)求采用的終極解決辦法。
負(fù)載均衡技術(shù)發(fā)展了多年，有很多專業(yè)的服務(wù)提供商和產(chǎn)品可以選擇，我個(gè)人接觸過(guò)一些解決方法，其中有兩個(gè)架構(gòu)可以給大家做參考。
 
高可用:

通常企業(yè)級(jí)應(yīng)用系統(tǒng)（特別是政府部門(mén)和大企業(yè)的應(yīng)用系統(tǒng)）一般會(huì)采用安規(guī)的軟硬件設(shè)備，如IOE（IBM的小型機(jī)、Oracle數(shù)據(jù)、EMC存儲(chǔ)設(shè)備）系列。而一般互聯(lián)網(wǎng)公司更多地采用PC級(jí)服務(wù)器（x86），開(kāi)源的數(shù)據(jù)庫(kù)（MySQL）和操作系統(tǒng)（Linux）組建廉價(jià)且高容錯(cuò)（硬件故障是常態(tài)）的應(yīng)用集群。

（1）設(shè)計(jì)的目的？

保證服務(wù)器硬件故障服務(wù)依然可用，數(shù)據(jù)依然保存并能夠被訪問(wèn)。

（2）主要的手段？

數(shù)據(jù)和服務(wù)的①冗余備份以及②失效轉(zhuǎn)移：

對(duì)于服務(wù)而言，一旦某個(gè)服務(wù)器宕機(jī)，就將服務(wù)切換到其他可用的服務(wù)器上；

對(duì)于數(shù)據(jù)而言，如果某個(gè)磁盤(pán)損壞，就從備份的磁盤(pán)（事先就做好了數(shù)據(jù)的同步復(fù)制）讀取數(shù)據(jù)。

高可用的服務(wù)

高可用的服務(wù)模塊為業(yè)務(wù)產(chǎn)品提供基礎(chǔ)公共服務(wù)，在大型站點(diǎn)中這些服務(wù)通常都獨(dú)立分布式部署，被具體應(yīng)用遠(yuǎn)程調(diào)用。

在具體實(shí)踐中，有以下幾點(diǎn)高可用的服務(wù)策略可以參考：

①分級(jí)管理：核心應(yīng)用和服務(wù)具有更高的優(yōu)先級(jí)，比如用戶及時(shí)付款比能否評(píng)價(jià)商品更重要；

②超時(shí)設(shè)置：設(shè)置服務(wù)調(diào)用的超時(shí)時(shí)間，一旦超時(shí)后，通信框架拋出異常，應(yīng)用程序則根據(jù)服務(wù)調(diào)度策略選擇重試or請(qǐng)求轉(zhuǎn)移到其他服務(wù)器上；

③異步調(diào)用：通過(guò)消息隊(duì)列等異步方式完成，避免一個(gè)服務(wù)失敗導(dǎo)致整個(gè)應(yīng)用請(qǐng)求失敗的情況。

    不是所有服務(wù)都可以異步調(diào)用，對(duì)于獲取用戶信息這類調(diào)用，采用異步方式會(huì)延長(zhǎng)響應(yīng)時(shí)間，得不償失。對(duì)于那些必須確認(rèn)服務(wù)調(diào)用成功后才能繼續(xù)進(jìn)行下一步的操作的應(yīng)用也不適合異步調(diào)用。

④服務(wù)降級(jí)：網(wǎng)站訪問(wèn)高峰期間，為了保證核心應(yīng)用的正常運(yùn)行，需要對(duì)服務(wù)降級(jí)。

降級(jí)有兩種手段：一是拒絕服務(wù)，拒絕較低優(yōu)先級(jí)的應(yīng)用的調(diào)用，減少服務(wù)調(diào)用并發(fā)數(shù)，確保核心應(yīng)用的正常運(yùn)行；二是關(guān)閉功能，關(guān)閉部分不重要的服務(wù)，或者服務(wù)內(nèi)部關(guān)閉部分不重要的功能，以節(jié)約系統(tǒng)開(kāi)銷，為核心應(yīng)用服務(wù)讓出資源；

⑤冪等性設(shè)計(jì)：保證服務(wù)重復(fù)調(diào)用和調(diào)用一次產(chǎn)生的結(jié)果相同；

高可用的數(shù)據(jù)

保證數(shù)據(jù)高可用的主要手段有兩種：一是數(shù)據(jù)備份，二是失效轉(zhuǎn)移機(jī)制；

①數(shù)據(jù)備份：又分為冷備份和熱備份，冷備份是定期復(fù)制，不能保證數(shù)據(jù)可用性。熱備份又分為異步熱備和同步熱備，異步熱備是指多份數(shù)據(jù)副本的寫(xiě)入操作異步完成，而同步方式則是指多份數(shù)據(jù)副本的寫(xiě)入操作同時(shí)完成。

關(guān)系數(shù)據(jù)庫(kù)的熱備機(jī)制就是通常所說(shuō)的主從同步機(jī)制，實(shí)踐中通常使用讀寫(xiě)分離的方法來(lái)訪問(wèn)Master和Slave數(shù)據(jù)庫(kù)，也就是說(shuō)寫(xiě)操作只訪問(wèn)Master庫(kù)，讀操作均訪問(wèn)Slave庫(kù)。























②失效轉(zhuǎn)移：若數(shù)據(jù)服務(wù)器集群中任何一臺(tái)服務(wù)器宕機(jī)，那么應(yīng)用程序針對(duì)這臺(tái)服務(wù)器的所有讀寫(xiě)操作都要重新路由到其他服務(wù)器，保證數(shù)據(jù)訪問(wèn)不會(huì)失敗。

 

網(wǎng)站運(yùn)行監(jiān)控

”不允許沒(méi)有監(jiān)控的系統(tǒng)上線“

（1）監(jiān)控?cái)?shù)據(jù)采集

①用戶行為日志收集：服務(wù)器端的日志收集和客戶端的日志收集；目前許多網(wǎng)站逐步開(kāi)發(fā)基于實(shí)時(shí)計(jì)算框架Storm的日志統(tǒng)計(jì)與分析工具；

②服務(wù)器性能監(jiān)控：收集服務(wù)器性能指標(biāo)，如系統(tǒng)Load、內(nèi)存占用、磁盤(pán)IO等，及時(shí)判斷，防患于未然；

③運(yùn)行數(shù)據(jù)報(bào)告：采集并報(bào)告，匯總后統(tǒng)一顯示，應(yīng)用程序需要在代碼中處理運(yùn)行數(shù)據(jù)采集的邏輯；

（2）監(jiān)控管理

①系統(tǒng)報(bào)警：配置報(bào)警閥值和值守人員聯(lián)系方式，系統(tǒng)發(fā)生報(bào)警時(shí)，即使工程師在千里之外，也可以被及時(shí)通知；

②失效轉(zhuǎn)移：監(jiān)控系統(tǒng)在發(fā)現(xiàn)故障時(shí)，主動(dòng)通知應(yīng)用進(jìn)行失效轉(zhuǎn)移；

③自動(dòng)優(yōu)雅降級(jí)：為了應(yīng)付網(wǎng)站訪問(wèn)高峰，主動(dòng)關(guān)閉部分功能，釋放部分系統(tǒng)資源，保證核心應(yīng)用服務(wù)的正常運(yùn)行；—>網(wǎng)站柔性架構(gòu)的理想狀態(tài)

        主從切換

        很好理解，當(dāng)其中一臺(tái)機(jī)器的服務(wù)宕機(jī)后，對(duì)于服務(wù)調(diào)用者來(lái)說(shuō)，能夠迅速的切換到其他可用服務(wù)，從服務(wù)升級(jí)為主服務(wù)，這種切換速度應(yīng)當(dāng)控制在秒級(jí)別（幾秒鐘）。

        當(dāng)宕機(jī)的服務(wù)恢復(fù)之后，自動(dòng)變?yōu)閺姆?wù)，主從服務(wù)角色切換。主從切換一定是要付出代價(jià)的，所以當(dāng)主服務(wù)恢復(fù)之后，也就不再替換現(xiàn)有的主服務(wù)。

        負(fù)載均衡

        當(dāng)服務(wù)的請(qǐng)求量比較高的時(shí)候，一臺(tái)服務(wù)不能滿足需求，這時(shí)候需要多臺(tái)機(jī)器提供同樣的服務(wù)，將所有請(qǐng)求分發(fā)到不同機(jī)器上。

        高可用架構(gòu)中應(yīng)該具有豐富的負(fù)載均衡策略和易調(diào)節(jié)負(fù)載的方式。

        甚至可以自動(dòng)化智能調(diào)節(jié)，例如由于機(jī)器性能的原因，響應(yīng)時(shí)間可能不一樣，這時(shí)候可以向性能差的機(jī)器少一點(diǎn)分發(fā)量，保證各個(gè)機(jī)器響應(yīng)時(shí)間的均衡。

        易橫向擴(kuò)展

        當(dāng)用戶量越來(lái)越多，已有服務(wù)不能承載更多的用戶的時(shí)候，便需要對(duì)服務(wù)進(jìn)行擴(kuò)展，擴(kuò)展的方式最好是不觸動(dòng)原有服務(wù)，對(duì)于服務(wù)的調(diào)用者是透明的。

 
負(fù)載均衡:

1.什么是負(fù)載均衡？

        當(dāng)一臺(tái)服務(wù)器的性能達(dá)到極限時(shí)，我們可以使用服務(wù)器集群來(lái)提高網(wǎng)站的整體性能。那么，在服務(wù)器集群中，需要有一臺(tái)服務(wù)器充當(dāng)調(diào)度者的角色，用戶的所有請(qǐng)求都會(huì)首先由它接收，調(diào)度者再根據(jù)每臺(tái)服務(wù)器的負(fù)載情況將請(qǐng)求分配給某一臺(tái)后端服務(wù)器去處理。

那么在這個(gè)過(guò)程中，調(diào)度者如何合理分配任務(wù)，保證所有后端服務(wù)器都將性能充分發(fā)揮，從而保持服務(wù)器集群的整體性能最優(yōu)，這就是負(fù)載均衡問(wèn)題。

下面詳細(xì)介紹負(fù)載均衡的實(shí)現(xiàn)方式。

（1）HTTP重定向負(fù)載均衡。

         這種負(fù)載均衡方案的優(yōu)點(diǎn)是比較簡(jiǎn)單；

         缺點(diǎn)是瀏覽器需要每次請(qǐng)求兩次服務(wù)器才能拿完成一次訪問(wèn)，性能較差。
（2）DNS域名解析負(fù)載均衡

         優(yōu)點(diǎn)是將負(fù)載均衡工作交給DNS，省略掉了網(wǎng)絡(luò)管理的麻煩；

         缺點(diǎn)就是DNS可能緩存A記錄，不受網(wǎng)站控制。
（3）反向代理負(fù)載均衡。

       優(yōu)點(diǎn)是部署簡(jiǎn)單；

       缺點(diǎn)是反向代理服務(wù)器是所有請(qǐng)求和響應(yīng)的中轉(zhuǎn)站，其性能可能會(huì)成為瓶頸。
（4）IP負(fù)載均衡。

      優(yōu)點(diǎn)：IP負(fù)載均衡在內(nèi)核進(jìn)程完成數(shù)據(jù)分發(fā)，較反向代理均衡有更好的處理性能。

      缺點(diǎn)：負(fù)載均衡的網(wǎng)卡帶寬成為系統(tǒng)的瓶頸。

（5）數(shù)據(jù)鏈路層負(fù)載均衡。

       避免負(fù)載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸，是目前大型網(wǎng)站所使用的最廣的一種負(fù)載均衡手段。

HTTP重定向?qū)崿F(xiàn)負(fù)載均衡

過(guò)程描述

        當(dāng)用戶向服務(wù)器發(fā)起請(qǐng)求時(shí)，請(qǐng)求首先被集群調(diào)度者截獲；調(diào)度者根據(jù)某種分配策略，選擇一臺(tái)服務(wù)器，并將選中的服務(wù)器的IP地址封裝在HTTP響應(yīng)消息頭部的Location字段中，并將響應(yīng)消息的狀態(tài)碼設(shè)為302，最后將這個(gè)響應(yīng)消息返回給瀏覽器。

當(dāng)瀏覽器收到響應(yīng)消息后，解析Location字段，并向該URL發(fā)起請(qǐng)求，然后指定的服務(wù)器處理該用戶的請(qǐng)求，最后將結(jié)果返回給用戶。

在使用HTTP重定向來(lái)實(shí)現(xiàn)服務(wù)器集群負(fù)載均衡的過(guò)程中，需要一臺(tái)服務(wù)器作為請(qǐng)求調(diào)度者。用戶的一項(xiàng)操作需要發(fā)起兩次HTTP請(qǐng)求，一次向調(diào)度服務(wù)器發(fā)送請(qǐng)求，獲取后端服務(wù)器的IP，第二次向后端服務(wù)器發(fā)送請(qǐng)求，獲取處理結(jié)果。
 

調(diào)度策略

    調(diào)度服務(wù)器收到用戶的請(qǐng)求后，究竟選擇哪臺(tái)后端服務(wù)器處理請(qǐng)求，這由調(diào)度服務(wù)器所使用的調(diào)度策略決定。

    隨機(jī)分配策略
    當(dāng)調(diào)度服務(wù)器收到用戶請(qǐng)求后，可以隨機(jī)決定使用哪臺(tái)后端服務(wù)器，然后將該服務(wù)器的IP封裝在HTTP響應(yīng)消息的Location屬性中，返回給瀏覽器即可。

    輪詢策略(RR)
    調(diào)度服務(wù)器需要維護(hù)一個(gè)值，用于記錄上次分配的后端服務(wù)器的IP。那么當(dāng)新的請(qǐng)求到來(lái)時(shí)，調(diào)度者將請(qǐng)求依次分配給下一臺(tái)服務(wù)器。

由于輪詢策略需要調(diào)度者維護(hù)一個(gè)值用于記錄上次分配的服務(wù)器IP，因此需要額外的開(kāi)銷；此外，由于這個(gè)值屬于互斥資源，那么當(dāng)多個(gè)請(qǐng)求同時(shí)到來(lái)時(shí)，為了避免線程的安全問(wèn)題，因此需要鎖定互斥資源，從而降低了性能。而隨機(jī)分配策略不需要維護(hù)額外的值，也就不存在線程安全問(wèn)題，因此性能比輪詢要高。
 

優(yōu)缺點(diǎn)分析

   采用HTTP重定向來(lái)實(shí)現(xiàn)服務(wù)器集群的負(fù)載均衡實(shí)現(xiàn)起來(lái)較為容易，邏輯比較簡(jiǎn)單，但缺點(diǎn)也較為明顯。

在HTTP重定向方法中，調(diào)度服務(wù)器只在客戶端第一次向網(wǎng)站發(fā)起請(qǐng)求的時(shí)候起作用。當(dāng)調(diào)度服務(wù)器向?yàn)g覽器返回響應(yīng)信息后，客戶端此后的操作都基于新的URL進(jìn)行的(也就是后端服務(wù)器)，此后瀏覽器就不會(huì)與調(diào)度服務(wù)器產(chǎn)生關(guān)系，進(jìn)而會(huì)產(chǎn)生如下幾個(gè)問(wèn)題：

    由于不同用戶的訪問(wèn)時(shí)間、訪問(wèn)頁(yè)面深度有所不同，從而每個(gè)用戶對(duì)各自的后端服務(wù)器所造成的壓力也不同。而調(diào)度服務(wù)器在調(diào)度時(shí)，無(wú)法知道當(dāng)前用戶將會(huì)對(duì)服務(wù)器造成多大的壓力，因此這種方式無(wú)法實(shí)現(xiàn)真正意義上的負(fù)載均衡，只不過(guò)是把請(qǐng)求次數(shù)平均分配給每臺(tái)服務(wù)器罷了。
    若分配給該用戶的后端服務(wù)器出現(xiàn)故障，并且如果頁(yè)面被瀏覽器緩存，那么當(dāng)用戶再次訪問(wèn)網(wǎng)站時(shí)，請(qǐng)求都會(huì)發(fā)給出現(xiàn)故障的服務(wù)器，從而導(dǎo)致訪問(wèn)失敗。

DNS負(fù)載均衡

DNS是什么？

在了解DNS負(fù)載均衡之前，我們首先需要了解DNS域名解析的過(guò)程。

我們知道，數(shù)據(jù)包采用IP地址在網(wǎng)絡(luò)中傳播，而為了方便用戶記憶，我們使用域名來(lái)訪問(wèn)網(wǎng)站。那么，我們通過(guò)域名訪問(wèn)網(wǎng)站之前，首先需要將域名解析成IP地址，這個(gè)工作是由DNS完成的。也就是域名服務(wù)器。

我們提交的請(qǐng)求不會(huì)直接發(fā)送給想要訪問(wèn)的網(wǎng)站，而是首先發(fā)給域名服務(wù)器，它會(huì)幫我們把域名解析成IP地址并返回給我們。我們收到IP之后才會(huì)向該IP發(fā)起請(qǐng)求。

那么，DNS服務(wù)器有一個(gè)天然的優(yōu)勢(shì)，如果一個(gè)域名指向了多個(gè)IP地址，那么每次進(jìn)行域名解析時(shí)，DNS只要選一個(gè)IP返回給用戶，就能夠?qū)崿F(xiàn)服務(wù)器集群的負(fù)載均衡。
 

具體做法

首先需要將我們的域名指向多個(gè)后端服務(wù)器(將一個(gè)域名解析到多個(gè)IP上)，再設(shè)置一下調(diào)度策略，那么我們的準(zhǔn)備工作就完成了，接下來(lái)的負(fù)載均衡就完全由DNS服務(wù)器來(lái)實(shí)現(xiàn)。

當(dāng)用戶向我們的域名發(fā)起請(qǐng)求時(shí)，DNS服務(wù)器會(huì)自動(dòng)地根據(jù)我們事先設(shè)定好的調(diào)度策略選一個(gè)合適的IP返回給用戶，用戶再向該IP發(fā)起請(qǐng)求。
 

調(diào)度策略

一般DNS提供商會(huì)提供一些調(diào)度策略供我們選擇，如隨機(jī)分配、輪詢、根據(jù)請(qǐng)求者的地域分配離他最近的服務(wù)器。
 

優(yōu)缺點(diǎn)分析

       DNS負(fù)載均衡最大的優(yōu)點(diǎn)就是配置簡(jiǎn)單。服務(wù)器集群的調(diào)度工作完全由DNS服務(wù)器承擔(dān)，那么我們就可以把精力放在后端服務(wù)器上，保證他們的穩(wěn)定性與吞吐量。而且完全不用擔(dān)心DNS服務(wù)器的性能，即便是使用了輪詢策略，它的吞吐率依然卓越。

此外，DNS負(fù)載均衡具有較強(qiáng)了擴(kuò)展性，你完全可以為一個(gè)域名解析較多的IP，而且不用擔(dān)心性能問(wèn)題。

但是，由于把集群調(diào)度權(quán)交給了DNS服務(wù)器，從而我們沒(méi)辦法隨心所欲地控制調(diào)度者，沒(méi)辦法定制調(diào)度策略。

DNS服務(wù)器也沒(méi)辦法了解每臺(tái)服務(wù)器的負(fù)載情況，因此沒(méi)辦法實(shí)現(xiàn)真正意義上的負(fù)載均衡。它和HTTP重定向一樣，只不過(guò)把所有請(qǐng)求平均分配給后端服務(wù)器罷了。

此外，當(dāng)我們發(fā)現(xiàn)某一臺(tái)后端服務(wù)器發(fā)生故障時(shí)，即使我們立即將該服務(wù)器從域名解析中去除，但由于DNS服務(wù)器會(huì)有緩存，該IP仍然會(huì)在DNS中保留一段時(shí)間，那么就會(huì)導(dǎo)致一部分用戶無(wú)法正常訪問(wèn)網(wǎng)站。這是一個(gè)致命的問(wèn)題！好在這個(gè)問(wèn)題可以用動(dòng)態(tài)DNS來(lái)解決。
 

動(dòng)態(tài)DNS

動(dòng)態(tài)DNS能夠讓我們通過(guò)程序動(dòng)態(tài)修改DNS服務(wù)器中的域名解析。從而當(dāng)我們的監(jiān)控程序發(fā)現(xiàn)某臺(tái)服務(wù)器掛了之后，能立即通知DNS將其刪掉。

綜上所述

DNS負(fù)載均衡是一種粗獷的負(fù)載均衡方法，這里只做介紹，不推薦使用。


 

反向代理負(fù)載均衡

什么是反向代理負(fù)載均衡？

       反向代理服務(wù)器是一個(gè)位于實(shí)際服務(wù)器之前的服務(wù)器，所有向我們網(wǎng)站發(fā)來(lái)的請(qǐng)求都首先要經(jīng)過(guò)反向代理服務(wù)器，服務(wù)器根據(jù)用戶的請(qǐng)求要么直接將結(jié)果返回給用戶，要么將請(qǐng)求交給后端服務(wù)器處理，再返回給用戶。

之前我們介紹了用反向代理服務(wù)器實(shí)現(xiàn)靜態(tài)頁(yè)面和常用的動(dòng)態(tài)頁(yè)面的緩存。接下來(lái)我們介紹反向代理服務(wù)器更常用的功能——實(shí)現(xiàn)負(fù)載均衡。

我們知道，所有發(fā)送給我們網(wǎng)站的請(qǐng)求都首先經(jīng)過(guò)反向代理服務(wù)器。那么，反向代理服務(wù)器就可以充當(dāng)服務(wù)器集群的調(diào)度者，它可以根據(jù)當(dāng)前后端服務(wù)器的負(fù)載情況，將請(qǐng)求轉(zhuǎn)發(fā)給一臺(tái)合適的服務(wù)器，并將處理結(jié)果返回給用戶。

優(yōu)點(diǎn)

    隱藏后端服務(wù)器。
    與HTTP重定向相比，反向代理能夠隱藏后端服務(wù)器，所有瀏覽器都不會(huì)與后端服務(wù)器直接交互，從而能夠確保調(diào)度者的控制權(quán)，提升集群的整體性能。
    故障轉(zhuǎn)移
    與DNS負(fù)載均衡相比，反向代理能夠更快速地移除故障結(jié)點(diǎn)。當(dāng)監(jiān)控程序發(fā)現(xiàn)某一后端服務(wù)器出現(xiàn)故障時(shí)，能夠及時(shí)通知反向代理服務(wù)器，并立即將其刪除。
    合理分配任務(wù)
    HTTP重定向和DNS負(fù)載均衡都無(wú)法實(shí)現(xiàn)真正意義上的負(fù)載均衡，也就是調(diào)度服務(wù)器無(wú)法根據(jù)后端服務(wù)器的實(shí)際負(fù)載情況分配任務(wù)。但反向代理服務(wù)器支持手動(dòng)設(shè)定每臺(tái)后端服務(wù)器的權(quán)重。我們可以根據(jù)服務(wù)器的配置設(shè)置不同的權(quán)重，權(quán)重的不同會(huì)導(dǎo)致被調(diào)度者選中的概率的不同。

缺點(diǎn)

    調(diào)度者壓力過(guò)大
    由于所有的請(qǐng)求都先由反向代理服務(wù)器處理，那么當(dāng)請(qǐng)求量超過(guò)調(diào)度服務(wù)器的最大負(fù)載時(shí)，調(diào)度服務(wù)器的吞吐率降低會(huì)直接降低集群的整體性能。
    制約擴(kuò)展
    當(dāng)后端服務(wù)器也無(wú)法滿足巨大的吞吐量時(shí)，就需要增加后端服務(wù)器的數(shù)量，可沒(méi)辦法無(wú)限量地增加，因?yàn)闀?huì)受到調(diào)度服務(wù)器的最大吞吐量的制約。
     

粘滯會(huì)話

反向代理服務(wù)器會(huì)引起一個(gè)問(wèn)題。若某臺(tái)后端服務(wù)器處理了用戶的請(qǐng)求，并保存了該用戶的session或存儲(chǔ)了緩存，那么當(dāng)該用戶再次發(fā)送請(qǐng)求時(shí)，無(wú)法保證該請(qǐng)求仍然由保存了其Session或緩存的服務(wù)器處理，若由其他服務(wù)器處理，先前的Session或緩存就找不到了。

解決辦法1：
可以修改反向代理服務(wù)器的任務(wù)分配策略，以用戶IP作為標(biāo)識(shí)較為合適。相同的用戶IP會(huì)交由同一臺(tái)后端服務(wù)器處理，從而就避免了粘滯會(huì)話的問(wèn)題。

解決辦法2：
可以在Cookie中標(biāo)注請(qǐng)求的服務(wù)器ID，當(dāng)再次提交請(qǐng)求時(shí)，調(diào)度者將該請(qǐng)求分配給Cookie中標(biāo)注的服務(wù)器處理即可。

 
基于IP的負(fù)載均衡方式

 
1.通過(guò)NAT實(shí)現(xiàn)負(fù)載均衡
運(yùn)作過(guò)程

    客戶端會(huì)向一個(gè)ip地址發(fā)出請(qǐng)求，這個(gè)ip地址是一個(gè)VIP(虛擬IP)，這也是調(diào)度器向外公布的一個(gè)地址。
    請(qǐng)求達(dá)到調(diào)度器，調(diào)度器會(huì)根據(jù)負(fù)載均衡算法(詳情請(qǐng)見(jiàn)8種負(fù)載均衡算法)從RealServer列表中選取一個(gè)負(fù)載不高的服務(wù)器，然后把請(qǐng)求報(bào)文的目標(biāo)地址，也就是VIP和端口通過(guò)iptables進(jìn)行NAT轉(zhuǎn)換成選中的服務(wù)器的真實(shí)ip地址。最后，調(diào)度器會(huì)把其連接保存在一個(gè)hash表中，只要這個(gè)連接下次再發(fā)請(qǐng)求報(bào)文過(guò)來(lái)就會(huì)把其分發(fā)到上次選定的服務(wù)器中。
    RealServer收到報(bào)文之后，會(huì)把響應(yīng)返回給調(diào)度器。
    調(diào)度器收到報(bào)文之后，會(huì)把源地址和源端口改為虛擬ip和端口，最后再返回給客戶端。

特點(diǎn)

1.RealServer和調(diào)度器必須位于一個(gè)ip網(wǎng)絡(luò)之中。
2.調(diào)度器位于RealServer和客戶端之間，處理進(jìn)出的通信。
3.RIP通常是內(nèi)部地址，僅用于集群之間通信。
4.RealServer的網(wǎng)關(guān)必須指向調(diào)度器。
5.支持端口映射，RealServer沒(méi)必要跟調(diào)度器一個(gè)端口。
限制

響應(yīng)報(bào)文一般比較大，每一次都需要NAT轉(zhuǎn)換的話，大流量的時(shí)候，會(huì)導(dǎo)致調(diào)度器成為一個(gè)瓶頸。
配圖

image.png
2.通過(guò)直接路由實(shí)現(xiàn)負(fù)載均衡
描述

由于網(wǎng)絡(luò)請(qǐng)求有一個(gè)特點(diǎn)，就是響應(yīng)報(bào)文往往都是比請(qǐng)求報(bào)文大很多的，這就會(huì)造成上面的nat每次轉(zhuǎn)發(fā)收到機(jī)器負(fù)載的影響，會(huì)成為這個(gè)請(qǐng)求的一個(gè)瓶頸。因此VS/DR這個(gè)方案可以通過(guò)直接路由的方式，只轉(zhuǎn)發(fā)請(qǐng)求，而相應(yīng)則由RealServer去直接響應(yīng)給客戶端，這樣可以極高提高吞吐量。
運(yùn)作過(guò)程

    客戶端請(qǐng)求一個(gè)VIP，這個(gè)ip地址就是調(diào)度器對(duì)外公布的地址。
    請(qǐng)求到達(dá)調(diào)度器之后，調(diào)度器根據(jù)負(fù)載算法去調(diào)度請(qǐng)求，分發(fā)給特定的RealServer，調(diào)度器不會(huì)修改ip和端口，只會(huì)mac地址改為把選出的RealServer的mac地址，RealServer將會(huì)收到對(duì)應(yīng)的報(bào)文。
    RealServer收到報(bào)文之后，發(fā)現(xiàn)報(bào)文的目標(biāo)地址VIP，處理結(jié)束之后，會(huì)通過(guò)路由表將響應(yīng)返回給客戶端。

特點(diǎn)

    集群節(jié)點(diǎn)，RealServer和調(diào)度器要在同一個(gè)物理網(wǎng)絡(luò)之中。
    RIP通常是私有網(wǎng)絡(luò)，當(dāng)然也可以是公開(kāi)網(wǎng)絡(luò)，方便監(jiān)控和管理。
    調(diào)度器只負(fù)責(zé)調(diào)度請(qǐng)求，響應(yīng)會(huì)由服務(wù)器直接對(duì)客戶端進(jìn)行響應(yīng)。
    RealServer不能指向調(diào)度器的網(wǎng)關(guān)。
    不支持端口映射。

3. VS/TUN 實(shí)現(xiàn)虛擬服務(wù)器
描述

由于VS/DR限制RealServer和調(diào)度器在同一個(gè)物理網(wǎng)絡(luò)，因此無(wú)法分散在各地，VS/TUN就能解決這個(gè)問(wèn)題。
運(yùn)作過(guò)程

1.客戶端通過(guò)VIP發(fā)送請(qǐng)求，通過(guò)一個(gè)ip隧道，將一個(gè)ip報(bào)文封裝到另一個(gè)ip報(bào)文，這樣可以讓目標(biāo)為一個(gè)ip的地址數(shù)據(jù)轉(zhuǎn)發(fā)到另一個(gè)ip地址。
2.調(diào)度器根據(jù)負(fù)載均衡算法去選擇一臺(tái)RealServer，再把封裝后的ip報(bào)文發(fā)送過(guò)去。
3.RealServer獲取到報(bào)文之后解封報(bào)文，獲取到原來(lái)目標(biāo)為VIP的報(bào)文，服務(wù)器發(fā)現(xiàn)這個(gè)VIP是位于本地的IP隧道中就會(huì)處理這個(gè)這個(gè)請(qǐng)求，并通過(guò)路由表去把響應(yīng)報(bào)文直接回復(fù)給客戶端。
特點(diǎn)

    RealServer和調(diào)度器必須可以公網(wǎng)訪問(wèn)。
    RIP必須是公網(wǎng)地址。
    調(diào)度器只分配和轉(zhuǎn)發(fā)請(qǐng)求給RealServer，響應(yīng)報(bào)文則由RealSever直接響應(yīng)給客戶端。
    RealServer的網(wǎng)關(guān)不能指向調(diào)度器。
    不支持端口映射。
     

數(shù)據(jù)鏈路層的負(fù)載均衡

數(shù)據(jù)鏈路層負(fù)載均衡其實(shí)也就是網(wǎng)卡的負(fù)載均衡,在下面的應(yīng)用情況下，就要考慮對(duì)網(wǎng)卡進(jìn)行負(fù)載均衡：

    某個(gè)服務(wù)器跑的應(yīng)用非高峰期間都能達(dá)到500M以上，晚高峰一般能夠超過(guò)1G，主流服務(wù)器的網(wǎng)卡都是千兆的，超過(guò)1G的流量明顯會(huì)導(dǎo)致丟包的問(wèn)題，此時(shí)又不能停止業(yè)務(wù)對(duì)網(wǎng)卡進(jìn)行更換，所以必須在增加一個(gè)網(wǎng)卡來(lái)聯(lián)合提供服務(wù)，所以就必須把多張網(wǎng)卡捆綁做成一個(gè)邏輯網(wǎng)卡。
    對(duì)網(wǎng)卡的高可用性要求，某些業(yè)務(wù)必須要求網(wǎng)卡層面的高可用性，所以必須捆綁多個(gè)網(wǎng)卡。

對(duì)于linux系統(tǒng)來(lái)說(shuō)，數(shù)據(jù)鏈路層的解決方案就是實(shí)現(xiàn)多個(gè)網(wǎng)卡綁定，即linux bonding，在思科交換機(jī)上這稱為以太網(wǎng)通道（Ether Channel）

linux bonding

在配置之前，我們先說(shuō)說(shuō)linux bonding的七種模式：
七種bond模式說(shuō)明：

第一種模式：mod=0 ，即：(balance-rr) Round-robin policy（平衡掄循環(huán)策略）

特點(diǎn)：傳輸數(shù)據(jù)包順序是依次傳輸（即：第1個(gè)包走eth0，下一個(gè)包就走eth1….一直循環(huán)下去，直到最后一個(gè)傳輸完畢），此模式提供負(fù)載平衡和容錯(cuò)能力；但是我們知道如果一個(gè)連接或者會(huì)話的數(shù)據(jù)包從不同的接口發(fā)出的話，中途再經(jīng)過(guò)不同的鏈路，在客戶端很有可能會(huì)出現(xiàn)數(shù)據(jù)包無(wú)序到達(dá)的問(wèn)題，而無(wú)序到達(dá)的數(shù)據(jù)包需要重新要求被發(fā)送，這樣網(wǎng)絡(luò)的吞吐量就會(huì)下降

第二種模式：mod=1，即： (active-backup) Active-backup policy（主-備份策略）

特點(diǎn)：只有一個(gè)設(shè)備處于活動(dòng)狀態(tài)，當(dāng)一個(gè)宕掉另一個(gè)馬上由備份轉(zhuǎn)換為主設(shè)備。mac地址是外部可見(jiàn)得，從外面看來(lái)，bond的MAC地址是唯一的，以避免switch(交換機(jī))發(fā)生混亂。此模式只提供了容錯(cuò)能力；由此可見(jiàn)此算法的優(yōu)點(diǎn)是可以提供高網(wǎng)絡(luò)連接的可用性，但是它的資源利用率較低，只有一個(gè)接口處于工作狀態(tài)，在有 N 個(gè)網(wǎng)絡(luò)接口的情況下，資源利用率為1/N

第三種模式：mod=2，即：(balance-xor) XOR policy（平衡策略）

特點(diǎn)：基于指定的傳輸HASH策略傳輸數(shù)據(jù)包。缺省的策略是：(源MAC地址 XOR 目標(biāo)MAC地址) % slave數(shù)量。其他的傳輸策略可以通過(guò)xmit_hash_policy選項(xiàng)指定，此模式提供負(fù)載平衡和容錯(cuò)能力

第四種模式：mod=3，即：broadcast（廣播策略）

特點(diǎn)：在每個(gè)slave接口上傳輸每個(gè)數(shù)據(jù)包，此模式提供了容錯(cuò)能力

第五種模式：mod=4，即：(802.3ad) IEEE 802.3adDynamic link aggregation（IEEE 802.3ad 動(dòng)態(tài)鏈接聚合）

特點(diǎn)：創(chuàng)建一個(gè)聚合組，它們共享同樣的速率和雙工設(shè)定。根據(jù)802.3ad規(guī)范將多個(gè)slave工作在同一個(gè)激活的聚合體下。

外出流量的slave選舉是基于傳輸hash策略，該策略可以通過(guò)xmit_hash_policy選項(xiàng)從缺省的XOR策略改變到其他策略。需要注意的是，并不是所有的傳輸策略都是802.3ad適應(yīng)的，尤其考慮到在802.3ad標(biāo)準(zhǔn)43.2.4章節(jié)提及的包亂序問(wèn)題。不同的實(shí)現(xiàn)可能會(huì)有不同的適應(yīng)性。

必要條件：

條件1：ethtool支持獲取每個(gè)slave的速率和雙工設(shè)定

條件2：switch(交換機(jī))支持IEEE 802.3ad Dynamic link aggregation

條件3：大多數(shù)switch(交換機(jī))需要經(jīng)過(guò)特定配置才能支持802.3ad模式

第六種模式：mod=5，即：(balance-tlb) Adaptive transmit load balancing（適配器傳輸負(fù)載均衡）

特點(diǎn)：不需要任何特別的switch(交換機(jī))支持的通道bonding。在每個(gè)slave上根據(jù)當(dāng)前的負(fù)載（根據(jù)速度計(jì)算）分配外出流量。如果正在接受數(shù)據(jù)的slave出故障了，另一個(gè)slave接管失敗的slave的MAC地址。

該模式的必要條件：ethtool支持獲取每個(gè)slave的速率

第七種模式：mod=6，即：(balance-alb) Adaptive load balancing（適配器適應(yīng)性負(fù)載均衡）

特點(diǎn)：該模式包含了balance-tlb模式，同時(shí)加上針對(duì)IPV4流量的接收負(fù)載均衡(receive load balance, rlb)，而且不需要任何switch(交換機(jī))的支持。接收負(fù)載均衡是通過(guò)ARP協(xié)商實(shí)現(xiàn)的。bonding驅(qū)動(dòng)截獲本機(jī)發(fā)送的ARP應(yīng)答，并把源硬件地址改寫(xiě)為bond中某個(gè)slave的唯一硬件地址，從而使得不同的對(duì)端使用不同的硬件地址進(jìn)行通信。

現(xiàn)在網(wǎng)絡(luò)中常見(jiàn)的的負(fù)載均衡主要分為兩種：

一種是通過(guò)硬件來(lái)進(jìn)行進(jìn)行， 常見(jiàn)的硬件有比較昂貴的NetScaler、F5、Radware和Array等商用的負(fù)載均衡器， 也有類似于LVS、Nginx、HAproxy的基于Linux的開(kāi)源的負(fù)載均衡策略, 商用負(fù)載均衡里面NetScaler從效果上比F5的效率上更高。對(duì)于負(fù)載均衡器來(lái)說(shuō)， 不過(guò)商用負(fù)載均衡由于可以建立在四~七層協(xié)議之上，因此適用面更廣所以有其不可替代性， 他的優(yōu)點(diǎn)就是有專業(yè)的維護(hù)團(tuán)隊(duì)來(lái)對(duì)這些服務(wù)進(jìn)行維護(hù)、缺點(diǎn)就是花銷太大， 所以對(duì)于規(guī)模較小的網(wǎng)絡(luò)服務(wù)來(lái)說(shuō)暫時(shí)還沒(méi)有需要使用。

另一種負(fù)載均衡的方式是通過(guò)軟件：比較常見(jiàn)的有LVS、Nginx、HAproxy等， 其中LVS是建立在四層協(xié)議上面的，而另外Nginx和HAproxy是建立在七層協(xié)議之上的

LVS：使用集群技術(shù)和Linux操作系統(tǒng)實(shí)現(xiàn)一個(gè)高性能、高可用的服務(wù)器， 它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。

LVS的特點(diǎn)是：

1、抗負(fù)載能力強(qiáng)、是工作在網(wǎng)絡(luò)4層之上僅作分發(fā)之用，沒(méi)有流量的產(chǎn)生；

2、配置性比較低，這是一個(gè)缺點(diǎn)也是一個(gè)優(yōu)點(diǎn)，因?yàn)闆](méi)有可太多配置的東西， 所以并不需要太多接觸，大大減少了人為出錯(cuò)的幾率；

3、工作穩(wěn)定，自身有完整的雙機(jī)熱備方案；

4、無(wú)流量，保證了均衡器IO的性能不會(huì)收到大流量的影響；

5、應(yīng)用范圍比較廣，可以對(duì)所有應(yīng)用做負(fù)載均衡；

6、LVS需要向IDC多申請(qǐng)一個(gè)IP來(lái)做Visual IP，因此需要一定的網(wǎng)絡(luò)知識(shí)，所以對(duì)操作人的要求比較高。

Nginx的特點(diǎn)是：

1、工作在網(wǎng)絡(luò)的7層之上，可以針對(duì)http應(yīng)用做一些分流的策略，比如針對(duì)域名、目錄結(jié)構(gòu)；

2、Nginx對(duì)網(wǎng)絡(luò)的依賴比較??；

3、Nginx安裝和配置比較簡(jiǎn)單，測(cè)試起來(lái)比較方便；

4、也可以承擔(dān)高的負(fù)載壓力且穩(wěn)定，一般能支撐超過(guò)1萬(wàn)次的并發(fā)；

5、Nginx可以通過(guò)端口檢測(cè)到服務(wù)器內(nèi)部的故障， 比如根據(jù)服務(wù)器處理網(wǎng)頁(yè)返回的狀態(tài)碼、超時(shí)等等， 并且會(huì)把返回錯(cuò)誤的請(qǐng)求重新提交到另一個(gè)節(jié)點(diǎn)，不過(guò)其中缺點(diǎn)就是不支持url來(lái)檢測(cè)；

6、Nginx對(duì)請(qǐng)求的異步處理可以幫助節(jié)點(diǎn)服務(wù)器減輕負(fù)載；

7、Nginx能支持http和Email，這樣就在適用范圍上面小很多；

8、不支持Session的保持、對(duì)Big request header的支持不是很好， 另外默認(rèn)的只有Round-robin和IP-hash兩種負(fù)載均衡算法。 HAProxy的特點(diǎn)是：

1、HAProxy是工作在網(wǎng)絡(luò)7層之上。

2、能夠補(bǔ)充Nginx的一些缺點(diǎn)比如Session的保持，Cookie的引導(dǎo)等工作

3、支持url檢測(cè)后端的服務(wù)器出問(wèn)題的檢測(cè)會(huì)有很好的幫助。

4、更多的負(fù)載均衡策略比如：動(dòng)態(tài)加權(quán)輪循(Dynamic Round Robin)， 加權(quán)源地址哈希(Weighted Source Hash)， 加權(quán)URL哈希和加權(quán)參數(shù)哈希(Weighted Parameter Hash)已經(jīng)實(shí)現(xiàn)

5、單純從效率上來(lái)講HAProxy更會(huì)比Nginx有更出色的負(fù)載均衡速度。

6、HAProxy可以對(duì)Mysql進(jìn)行負(fù)載均衡，對(duì)后端的DB節(jié)點(diǎn)進(jìn)行檢測(cè)和負(fù)載均衡。

現(xiàn)在網(wǎng)站發(fā)展的趨勢(shì)對(duì)網(wǎng)絡(luò)負(fù)載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來(lái)使用不同的技術(shù)：

第一階段：利用Nginx或者HAProxy進(jìn)行單點(diǎn)的負(fù)載均衡， 這一階段服務(wù)器規(guī)模剛脫離開(kāi)單服務(wù)器、單數(shù)據(jù)庫(kù)的模式，需要一定的負(fù)載均衡， 但是 仍然規(guī)模較小沒(méi)有專業(yè)的維護(hù)團(tuán)隊(duì)來(lái)進(jìn)行維護(hù)，也沒(méi)有需要進(jìn)行大規(guī)模的網(wǎng)站部署。 這樣利用Nginx或者HAproxy就是第一選擇，此時(shí)這些東西上手快， 配置容易， 在七層之上利用HTTP協(xié)議就可以。這時(shí)是第一選擇

第二階段：隨著網(wǎng)絡(luò)服務(wù)進(jìn)一步擴(kuò)大，這時(shí)單點(diǎn)的Nginx已經(jīng)不能滿足， 這時(shí)使用LVS或者商用F5就是首要選擇，Nginx此時(shí)就作為L(zhǎng)VS或者 F5的節(jié)點(diǎn)來(lái)使用， 具體LVS或者F5的是選擇是根據(jù)公司規(guī)模，人才以及資金能力來(lái)選擇的，這里也不做詳談， 但是一般來(lái)說(shuō)這階段相關(guān)人才跟不上業(yè)務(wù)的提 升，所以購(gòu)買(mǎi)商業(yè)負(fù)載均衡已經(jīng)成為了必經(jīng)之路。

第三階段：這時(shí)網(wǎng)絡(luò)服務(wù)已經(jīng)成為主流產(chǎn)品，此時(shí)隨著公司知名度也進(jìn)一步擴(kuò)展， 相關(guān)人才的能力以及數(shù)量也隨之提升，這時(shí)無(wú)論從開(kāi)發(fā)適合自身產(chǎn)品的定制， 以及降低成本來(lái)講開(kāi)源的LVS，已經(jīng)成為首選，這時(shí)LVS會(huì)成為主流。 最終形成比較理想的狀態(tài)為：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer