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

分布式 :

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

優(yōu)點：

    把模塊拆分，使用接口通信，降低模塊之間的耦合度。
    把項目拆分成若干個子項目，不同的團隊負責不同的子項目。
    增加功能時只需要再增加一個子項目，調用其他系統(tǒng)的接口就可以。
    可以靈活的進行分布式部署。

缺點：

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

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

基于soa的架構

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

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

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

分布式，主要還是從部署的角度，將應用按照訪問壓力進行歸類，主要目標是充分利用服務器的資源，避免資源分配不均

 
集群:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）設計的目的？

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

（2）主要的手段？

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

對于服務而言，一旦某個服務器宕機，就將服務切換到其他可用的服務器上；

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

高可用的服務

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

在具體實踐中，有以下幾點高可用的服務策略可以參考：

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

②超時設置：設置服務調用的超時時間，一旦超時后，通信框架拋出異常，應用程序則根據(jù)服務調度策略選擇重試or請求轉移到其他服務器上；

③異步調用：通過消息隊列等異步方式完成，避免一個服務失敗導致整個應用請求失敗的情況。

    不是所有服務都可以異步調用，對于獲取用戶信息這類調用，采用異步方式會延長響應時間，得不償失。對于那些必須確認服務調用成功后才能繼續(xù)進行下一步的操作的應用也不適合異步調用。

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

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

⑤冪等性設計：保證服務重復調用和調用一次產(chǎn)生的結果相同；

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

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

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

關系數(shù)據(jù)庫的熱備機制就是通常所說的主從同步機制，實踐中通常使用讀寫分離的方法來訪問Master和Slave數(shù)據(jù)庫，也就是說寫操作只訪問Master庫，讀操作均訪問Slave庫。























②失效轉移：若數(shù)據(jù)服務器集群中任何一臺服務器宕機，那么應用程序針對這臺服務器的所有讀寫操作都要重新路由到其他服務器，保證數(shù)據(jù)訪問不會失敗。

 

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

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

（1）監(jiān)控數(shù)據(jù)采集

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

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

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

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

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

②失效轉移：監(jiān)控系統(tǒng)在發(fā)現(xiàn)故障時，主動通知應用進行失效轉移；

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

        主從切換

        很好理解，當其中一臺機器的服務宕機后，對于服務調用者來說，能夠迅速的切換到其他可用服務，從服務升級為主服務，這種切換速度應當控制在秒級別（幾秒鐘）。

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

        負載均衡

        當服務的請求量比較高的時候，一臺服務不能滿足需求，這時候需要多臺機器提供同樣的服務，將所有請求分發(fā)到不同機器上。

        高可用架構中應該具有豐富的負載均衡策略和易調節(jié)負載的方式。

        甚至可以自動化智能調節(jié)，例如由于機器性能的原因，響應時間可能不一樣，這時候可以向性能差的機器少一點分發(fā)量，保證各個機器響應時間的均衡。

        易橫向擴展

        當用戶量越來越多，已有服務不能承載更多的用戶的時候，便需要對服務進行擴展，擴展的方式最好是不觸動原有服務，對于服務的調用者是透明的。

 
負載均衡:

1.什么是負載均衡？

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

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

下面詳細介紹負載均衡的實現(xiàn)方式。

（1）HTTP重定向負載均衡。

         這種負載均衡方案的優(yōu)點是比較簡單；

         缺點是瀏覽器需要每次請求兩次服務器才能拿完成一次訪問，性能較差。
（2）DNS域名解析負載均衡

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

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

       優(yōu)點是部署簡單；

       缺點是反向代理服務器是所有請求和響應的中轉站，其性能可能會成為瓶頸。
（4）IP負載均衡。

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

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

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

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

HTTP重定向實現(xiàn)負載均衡

過程描述

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

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

在使用HTTP重定向來實現(xiàn)服務器集群負載均衡的過程中，需要一臺服務器作為請求調度者。用戶的一項操作需要發(fā)起兩次HTTP請求，一次向調度服務器發(fā)送請求，獲取后端服務器的IP，第二次向后端服務器發(fā)送請求，獲取處理結果。
 

調度策略

    調度服務器收到用戶的請求后，究竟選擇哪臺后端服務器處理請求，這由調度服務器所使用的調度策略決定。

    隨機分配策略
    當調度服務器收到用戶請求后，可以隨機決定使用哪臺后端服務器，然后將該服務器的IP封裝在HTTP響應消息的Location屬性中，返回給瀏覽器即可。

    輪詢策略(RR)
    調度服務器需要維護一個值，用于記錄上次分配的后端服務器的IP。那么當新的請求到來時，調度者將請求依次分配給下一臺服務器。

由于輪詢策略需要調度者維護一個值用于記錄上次分配的服務器IP，因此需要額外的開銷；此外，由于這個值屬于互斥資源，那么當多個請求同時到來時，為了避免線程的安全問題，因此需要鎖定互斥資源，從而降低了性能。而隨機分配策略不需要維護額外的值，也就不存在線程安全問題，因此性能比輪詢要高。
 

優(yōu)缺點分析

   采用HTTP重定向來實現(xiàn)服務器集群的負載均衡實現(xiàn)起來較為容易，邏輯比較簡單，但缺點也較為明顯。

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

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

DNS負載均衡

DNS是什么？

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

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

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

那么，DNS服務器有一個天然的優(yōu)勢，如果一個域名指向了多個IP地址，那么每次進行域名解析時，DNS只要選一個IP返回給用戶，就能夠實現(xiàn)服務器集群的負載均衡。
 

具體做法

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

當用戶向我們的域名發(fā)起請求時，DNS服務器會自動地根據(jù)我們事先設定好的調度策略選一個合適的IP返回給用戶，用戶再向該IP發(fā)起請求。
 

調度策略

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

優(yōu)缺點分析

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

此外，DNS負載均衡具有較強了擴展性，你完全可以為一個域名解析較多的IP，而且不用擔心性能問題。

但是，由于把集群調度權交給了DNS服務器，從而我們沒辦法隨心所欲地控制調度者，沒辦法定制調度策略。

DNS服務器也沒辦法了解每臺服務器的負載情況，因此沒辦法實現(xiàn)真正意義上的負載均衡。它和HTTP重定向一樣，只不過把所有請求平均分配給后端服務器罷了。

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

動態(tài)DNS

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

綜上所述

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


 

反向代理負載均衡

什么是反向代理負載均衡？

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

之前我們介紹了用反向代理服務器實現(xiàn)靜態(tài)頁面和常用的動態(tài)頁面的緩存。接下來我們介紹反向代理服務器更常用的功能——實現(xiàn)負載均衡。

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

優(yōu)點

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

缺點

    調度者壓力過大
    由于所有的請求都先由反向代理服務器處理，那么當請求量超過調度服務器的最大負載時，調度服務器的吞吐率降低會直接降低集群的整體性能。
    制約擴展
    當后端服務器也無法滿足巨大的吞吐量時，就需要增加后端服務器的數(shù)量，可沒辦法無限量地增加，因為會受到調度服務器的最大吞吐量的制約。
     

粘滯會話

反向代理服務器會引起一個問題。若某臺后端服務器處理了用戶的請求，并保存了該用戶的session或存儲了緩存，那么當該用戶再次發(fā)送請求時，無法保證該請求仍然由保存了其Session或緩存的服務器處理，若由其他服務器處理，先前的Session或緩存就找不到了。

解決辦法1：
可以修改反向代理服務器的任務分配策略，以用戶IP作為標識較為合適。相同的用戶IP會交由同一臺后端服務器處理，從而就避免了粘滯會話的問題。

解決辦法2：
可以在Cookie中標注請求的服務器ID，當再次提交請求時，調度者將該請求分配給Cookie中標注的服務器處理即可。

 
基于IP的負載均衡方式

 
1.通過NAT實現(xiàn)負載均衡
運作過程

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

特點

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

響應報文一般比較大，每一次都需要NAT轉換的話，大流量的時候，會導致調度器成為一個瓶頸。
配圖

image.png
2.通過直接路由實現(xiàn)負載均衡
描述

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

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

特點

    集群節(jié)點，RealServer和調度器要在同一個物理網(wǎng)絡之中。
    RIP通常是私有網(wǎng)絡，當然也可以是公開網(wǎng)絡，方便監(jiān)控和管理。
    調度器只負責調度請求，響應會由服務器直接對客戶端進行響應。
    RealServer不能指向調度器的網(wǎng)關。
    不支持端口映射。

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

由于VS/DR限制RealServer和調度器在同一個物理網(wǎng)絡，因此無法分散在各地，VS/TUN就能解決這個問題。
運作過程

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

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

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

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

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

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

linux bonding

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

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

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

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

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

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

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

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

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

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

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

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

必要條件：

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

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

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

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

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

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

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

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

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

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

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

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

LVS的特點是：

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

2、配置性比較低，這是一個缺點也是一個優(yōu)點，因為沒有可太多配置的東西， 所以并不需要太多接觸，大大減少了人為出錯的幾率；

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

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

5、應用范圍比較廣，可以對所有應用做負載均衡；

6、LVS需要向IDC多申請一個IP來做Visual IP，因此需要一定的網(wǎng)絡知識，所以對操作人的要求比較高。

Nginx的特點是：

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

2、Nginx對網(wǎng)絡的依賴比較小；

3、Nginx安裝和配置比較簡單，測試起來比較方便；

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

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

6、Nginx對請求的異步處理可以幫助節(jié)點服務器減輕負載；

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

8、不支持Session的保持、對Big request header的支持不是很好， 另外默認的只有Round-robin和IP-hash兩種負載均衡算法。 HAProxy的特點是：

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

2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作

3、支持url檢測后端的服務器出問題的檢測會有很好的幫助。

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

5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。

6、HAProxy可以對Mysql進行負載均衡，對后端的DB節(jié)點進行檢測和負載均衡。

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

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

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

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