大數據教程（3.4）：zookeeper集羣角色分配原理

        1、zookeeper角色概念

        zookeeper集羣中有三種角色（zookeeper服務器節點），它們分別是：羣首（leader），追隨者（follower），觀察者（observer）。因爲觀察者這種節點咱們工做中基本不會接觸到，故此只重點講述前兩種角色。

        羣首（leader）：Leader做爲整個ZooKeeper集羣的主節點，負責響應全部對ZooKeeper狀態變動的請求。它會將每一個狀態更新請求進行排序和編號，以便保證整個集羣內部消息處理的FIFO。

        這裏補充一下ZooKeeper的請求類型。對於exists，getData，getChildren等只讀請求，收到該請求的zk服務器將會在本地處理，由於由其內部的ZAB理論實現，每一個服務器看到的名字空間內容都是一致的，無所謂在哪臺機器上讀取數據，所以若是ZooKeeper集羣的負載是讀多寫少，而且讀請求分佈得均衡的話，效率是很高的。對於create，setData，delete等有寫操做的請求，則須要統一轉發給leader處理，leader須要決定編號、執行操做，這個過程稱爲一個事務（transaction）。

        追隨者（follower）：Follower主要是響應本服務器上的讀請求外，另外follower還要處理leader的提議，並在leader提交該提議時在本地也進行提交。另外須要注意的是，leader和follower構成ZooKeeper集羣的法定人數，也就是說，只有他們才參與新leader的選舉、響應leader的提議。

        2、選舉原理

（1） 第一種狀況：集羣是全新的集羣。
        以一個簡單的例子來講明整個選舉的過程. 
        假設有五臺服務器組成的zookeeper集羣,它們的id從1-5,同時它們都是最新啓動的,也就是沒有歷史數據,在存放數據量這一點上,都是 同樣的.假設這些服務器依序啓動,來看看會發生什麼：

 
        1) 服務器1啓動,此時只有它一臺服務器啓動了,它發出去的報沒有任何響應,因此它的選舉狀態一直是LOOKING狀態 
        2) 服務器2啓動,它與最開始啓動的服務器1進行通訊,互相交換本身的選舉結果,因爲二者都沒有歷史數據,因此id值較大的服務器2勝出,可是因爲沒有達到超過半數以上的服務器都贊成選舉它(這個例子中的半數以上是3),因此服務器1,2仍是繼續保持LOOKING狀態. 
        3) 服務器3啓動,根據前面的理論分析,服務器3成爲服務器1,2,3中的老大,而與上面不一樣的是,此時有三臺服務器選舉了它,因此它成爲了此次選舉的leader. 

        4) 服務器4啓動,根據前面的分析,理論上服務器4應該是服務器1,2,3,4中最大的,可是因爲前面已經有半數以上的服務器選舉了服務器3,因此它只能成爲follower了. 
        5) 服務器5啓動,同4同樣,成爲follower.

（2）第二種狀況：非全新集羣的選舉機制(數據恢復)
        那麼，初始化的時候，是按照上述的說明進行選舉的，可是當zookeeper運行了一段時間以後，有機器down掉，從新選舉時，選舉過程就相對複雜了。 
        須要加入數據id、leader id和邏輯時鐘。 
        數據id：數據新的id就大，數據每次更新都會更新id。 
        Leader id：就是咱們配置的myid中的值，每一個機器一個。 
        邏輯時鐘：這個值從0開始遞增,每次選舉對應一個值,也就是說: 若是在同一次選舉中,那麼這個值應該是一致的 ; 邏輯時鐘值越大,說明這一次選舉leader的進程更新. 

        選舉的規則就變成： 
        一、邏輯時鐘小的選舉結果被忽略，從新投票 
        二、統一邏輯時鐘後，數據id大的勝出 
        三、數據id相同的狀況下，leader id大的勝出 
        根據這個規則選出leader。

     

        3、Zookeeper集羣-應用程序的工做原理

 

        以上是博主今天對zookeeper角色工做原理介紹的所有內容，因爲本教程的重點是大數據部分，故此處zookeeper的介紹不會詳細到專家級。若是你們對zookeeper底層原理或其它知識感興趣，請點贊並關注博主，博主將在後期推出zookeeper的詳細教程。最後的最後，若是你們以爲文章不錯，請爲博主點贊。