zookeeper如何實現負載均衡的？（具體鏈接哪個zookeeper服務器的選擇？）阿里面試

若是想了解web 6大負載均衡算法，參考：六大Web負載均衡原理與實現

主要是三點：負載均衡算法，健康檢查和會話保持

 1：首先，咱們要了解，咱們的應用程序，好比java web程序，裏面配置了10個zookeeper服務器的地址？那麼用戶經過網頁訪問咱們的程序，具體是訪問到了哪個zookeeper服務器上呢？

固然zookeeper尚未這麼簡單，zookeeper集羣還要保證用戶鏈接的某一個zookeeper服務器的數據是最新的，因此裏面還有一個選舉算法，而後將最新狀態的服務器暴露給Java web程序訪問。 

負載均衡設備做爲縱跨網絡2-7層協議的設備，每每放置在網絡設備和應用設備的鏈接處，對工程師在網絡和應用基本知識方面的要求遠高於其餘設備，因此咱們要在基本功能的理解上下更多的功夫。負載均衡設備還有另一個稱呼：4/7層交換機，但它首先是個2-3層交換機，這要求咱們首先掌握2-3層的基本知識，而後纔是本文介紹的內容。

服務器負載均衡有三大基本Feature：負載均衡算法，健康檢查和會話保持，這三個Feature是保證負載均衡正常工做的基本要素。其餘一些功能都是在這三個功能之上的一些深化。下面咱們具體介紹一下各個功能的做用和原理。

在沒有部署負載均衡設備以前，用戶直接訪問服務器地址（中間或許有在防火牆上將服務器地址映射成別的地址，但本質上仍是一對一的訪問）。當單臺服務器因爲性能不足沒法處理衆多用戶的訪問時，就要考慮用多臺服務器來提供服務，實現的方式就是負載均衡。負載均衡設備的實現原理是把多臺服務器的地址映射成一個對外的服務IP（咱們一般稱之爲VIP，關於服務器的映射能夠直接將服務器IP映射成VIP地址，也能夠將服務器IP:Port映射成VIP:Port，不一樣的映射方式會採起相應的健康檢查,在端口映射時，服務器端口與VIP端口能夠不相同）,這個過程對用戶端是透明的，用戶實際上不知道服務器是作了負載均衡的，由於他們訪問的仍是一個目的IP,那麼用戶的訪問到達負載均衡設備後，如何把用戶的訪問分發到合適的服務器就是負載均衡設備要作的工做了，具體來講用到的就是上述的三大Feature。

咱們來作一個詳細的訪問流程分析:

 

 

用戶(IP:207.17.117.20)訪問域名www.a10networks.com，首先會經過DNS查詢解析出這個域名的公網地址：199.237.202.124，接下來用戶207.17.117.20會訪問199.237.202.124這個地址，所以數據包會到達負載均衡設備，接下來負載均衡設備會把數據包分發到合適的服務器，看下圖：

 

 

負載均衡設備在將數據包發給服務器時，數據包是作了一些變化的，如上圖所示，數據包到達負載均衡設備以前，源地址是：207.17.117.20，目的地址是：199.237.202.124, 當負載均衡設備將數據包轉發給選中的服務器時，源地址仍是：207.17.117.20,目的地址變爲172.16.20.1，咱們稱這種方式爲目的地址NAT(DNAT)。通常來講，在服務器負載均衡中DNAT是必定要作的（還有另外一種模式叫作服務器直接返回-DSR，是不作DNAT的，咱們將另行討論），而源地址根據部署模式的不一樣，有時候也須要轉換成別的地址，咱們稱之爲：源地址NAT(SNAT)，通常來講，旁路模式須要作SNAT，而串接模式不須要，本示意圖爲串接模式，因此源地址沒作NAT。

咱們再看服務器的返回包，以下圖所示，也通過了IP地址的轉換過程，不過應答包中源/目的地址與請求包正好對調，從服務器回來的包源地址爲172.16.20.1，目的地址爲207.17.117.20,到達負載均衡設備後，負載均衡設備將源地址改成199.237.202.124，而後轉發給用戶，保證了訪問的一致性。

 

 

以上是單個數據包的處理流程。那麼負載均衡設備是怎麼選擇服務器的呢？ 這就是咱們要介紹的第一個Feature:

 

負載均衡算法

 (跟Dubbo的負載均衡算法相似，能夠參考：Dubbo學習(二) Dubbo 集羣容錯模式-負載均衡模式)

通常來講負載均衡設備都會默認支持多種負載均衡分發策略，例如：

Ø  輪詢（RoundRobin）將請求順序循環地發到每一個服務器。當其中某個服務器發生故障，AX就把其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢復正常。

Ø  比率（Ratio）：給每一個服務器分配一個加權值爲比例，根椐這個比例，把用戶的請求分配到每一個服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

Ø  優先權（Priority）：給全部服務器分組，給每一個組定義優先權，將用戶的請求分配給優先級最高的服務器組（在同一組內，採用預先設定的輪詢或比率算法，分配用戶的請求）；當最高優先級中全部服務器或者指定數量的服務器出現故障，AX將把請求送給次優先級的服務器組。這種方式，實際爲用戶提供一種熱備份的方式。

Ø  最少鏈接數（LeastConnection）：AX會記錄當前每臺服務器或者服務端口上的鏈接數，新的鏈接將傳遞給鏈接數最少的服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

Ø  最快響應時間（Fast Reponse time）：新的鏈接傳遞給那些響應最快的服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

以上爲通用的負載均衡算法，還有一些算法根據不一樣的需求也可能會用到，例如：

Ø  哈希算法( hash):  將客戶端的源地址，端口進行哈希運算，根據運算的結果轉發給一臺服務器進行處理，當其中某個服務器發生故障，就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

Ø  基於策略的負載均衡：針對不一樣的數據流設置導向規則，用戶可自行編輯流量分配策略，利用這些策略對經過的數據流實施導向控制。

Ø  基於數據包的內容分發：例如判斷HTTP的URL，若是URL中帶有.jpg的擴展名，就把數據包轉發到指定的服務器。 

繼續看圖分析，第二個用戶207.17.117.21也訪問www.a10networks.com，負載均衡設備根據負載均衡算法將第二個用戶的請求轉發到第二臺服務器來處理。

 

 

 

假設在工做過程當中，忽然有一臺服務器出現問題怎麼辦？ 這就涉及到咱們要介紹的第二個Feature:

健康檢查

健康檢查用於檢查服務器開放的各類服務的可用狀態。負載均衡設備通常會配置各類健康檢查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等。Ping屬於第三層的健康檢查，用於檢查服務器IP的連通性，而TCP/UDP屬於第四層的健康檢查，用於檢查服務端口的UP/DOWN，若是要檢查的更準確，就要用到基於7層的健康檢查，例如建立一個HTTP健康檢查，Get一個頁面回來，而且檢查頁面內容是否包含一個指定的字符串，若是包含，則服務是UP的，若是不包含或者取不回頁面，就認爲該服務器的Web服務是不可用（DOWN）的。以下圖所示，負載均衡設備檢查到172.16.20.3這臺服務器的80端口是DOWN的，負載均衡設備將不把後面的鏈接轉發到這臺服務器，而是根據算法將數據包轉發到別的服務器。建立健康檢查時能夠設定檢查的間隔時間和嘗試次數，例如設定間隔時間爲5秒，嘗試次數爲3，那麼負載均衡設備每隔5秒發起一次健康檢查，若是檢查失敗，則嘗試3次，若是3次都檢查失敗，則把該服務標記爲DOWN，而後服務器仍然會每隔5秒對DOWN的服務器進行檢查，當某個時刻發現該服務器健康檢查又成功了，則把該服務器從新標記爲UP。健康檢查的間隔時間和嘗試次數要根據綜合狀況來設置，原則是既不會對業務產生影響，又不會對負載均衡設備形成較大負擔。

 

 

 

 

 

 

假設是同一個用戶繼續訪問，後續的鏈接會怎麼處理呢？ 看下圖：

 

 

 

 

 

 

用戶207.17.117.25以前發起的第一個鏈接是207.17.117.25：4003-〉199.237.202.127:80，負載均衡設備將該鏈接轉發到了172.16.20.4，接着發起第二個鏈接207.17.117.25：4004-〉199.237.202.127:80，咱們看到該鏈接仍是轉發到了服務器172.16.20.4，爲何呢？由於負載均衡設備配置了會話保持。

會話保持

會話保持用於保持會話的連續性和一致性，因爲服務器之間很難作到實時同步用戶訪問信息，這就要求把用戶的先後訪問會話保持到一臺服務器上來處理。舉個例子，用戶訪問一個電子商務網站，若是用戶登陸時是由第一臺服務器來處理的，但用戶購買商品的動做卻由第二臺服務器來處理，第二臺服務器因爲不知道用戶信息，因此本次購買就不會成功。這種狀況就須要會話保持，把用戶的操做都經過第一臺服務器來處理才能成功。固然並非全部的訪問都須要會話保持，例如服務器提供的是靜態頁面好比網站的新聞頻道，各臺服務器都有相同的內容，這種訪問就不須要會話保持。

負載均衡設備通常會默認配置一些會話保持的選項，例如源地址的會話保持，Cookie會話保持等，基於不一樣的應用要配置不一樣的會話保持，不然會引發負載的不均衡甚至訪問異常。具體可參考本人的另外一篇拙做：《不一樣應用環境下會話保持方式的選擇》。

本文介紹了負載均衡的基本功能和實現原理，看起來並不難，但負載均衡涉及的知識其實很是的普遍，根據各個用戶系統的不一樣，咱們要熟悉不一樣的協議和應用流程，甚至涉及到某些開發語言和軟件平臺，不然在出現故障的時候，咱們可能沒有能力作出有效的判斷，從這個意義上來講，一個負載均衡設備的工程師要掌握網絡，應用和系統等各方面的知識，這些都要看成基礎來積累。

參考：zookeeper如何實現負載均衡的？（具體鏈接哪個zookeeper服務器的選擇？）