1. 程式人生 > >Zookeeper-ZAB協議

Zookeeper-ZAB協議

1.ZAB協議的核心

         在一個zk叢集中,只有一個leader節點可以將客戶端的寫請求轉化為事務或提議proposal,leader節點寫完資料庫,

把proposal訊息傳送到leader和follower直接的通訊佇列中去,follower節點處理完leader節點發送的proposal訊息後,

給leader節點返回ACK訊息確認,當leader節點接收到半數以上的follower返回的ACK訊息後,leader節點就向所有的

follower節點發送commit訊息。

2.ZAB協議的兩種模式

           1.崩潰恢復模式

           2.訊息廣播模式

3.zookeeper 中的ZXID

       1.為了保證zookeeper事務的順序一致性,zxid採用的時遞增的事id(zxid)來標識事務

       2.zxid有64位組成

                     ---高32位是epoch編號(用來標識leader的週期變化,即每次新選舉出leader,epoch編號自動加1)

                    ---低32位用於遞增計數 (每次新選出leader時,清零)

4.崩潰恢復模式

         1.崩潰恢復模式需要解決兩個問題

              A:已經被處理的訊息不能丟失-產生的原因如下圖所示

          當leader節點在向follower節點發送commit訊息的時候,只有follower1 訊息傳送成功後,leader節點直接崩潰,

還沒有向follower2節點發送commit訊息。

         也就是說當zk叢集恢復使用(選出新的leader)後,老leader節點最後提交到follower1節點的訊息不能丟失

             B:被丟棄的訊息不能再次出現-客戶端只能重新發一次請求 -產生的原因如下圖所示

          當leader節點向所有的follower節點發送commit訊息之前,leader節點直接崩潰,也就是說,

所有的follower節點都沒有同步到leader節點最後崩潰前處理的客戶端請求的資料。

          就是說當老leader節點可以使用,加入新的leader領導的叢集中作為follower節點使用的時候,

老leader節點最後處理的客戶端請求需要丟棄

    2 .崩潰恢復的解決方案

          A:針對第一個問題,選出叢集中擁有最高zxid編號事務proposal機器之一,作為新的leader節點

         B:針對第二個問題,當老的leader作為新的follower節點加入叢集時,新的leader把老的leader中所

有舊的epoch號標記的未被提交的事務proposal清除

5.訊息廣播模式

        1.訊息廣播模式流程圖

         2.訊息廣播模式的步驟

  1. 客戶端發起一個寫操作請求 
  2. Leader伺服器將客戶端的request請求轉化為事物proposql提案,同時為每個proposal分配一個全域性唯一的ID,即ZXID。 
  3. leader伺服器與每個follower之間都有一個佇列,leader將訊息傳送到該佇列  
  4.  follower機器從佇列中取出訊息處理完(寫入本地事物日誌中)畢後,向leader伺服器傳送ACK確認。 
  5. leader伺服器收到半數以上的follower的ACK後,即認為可以傳送commit 
  6. leader向所有的follower伺服器傳送commit訊息。

        3. leader節點和每個follower節點之間都有一個佇列進行收發訊息

            使用佇列訊息可以做到非同步解耦。leader和follower之間只要往佇列中傳送了訊息即可。

            如果使用同步方式容易引起阻塞。效能上要下降很多。

6.ZAB協議的原理-每個leader都要經歷3個階段

      1.發現   -即每個ZK叢集必須選舉出一個leader節點;每個leader節點維護一個follower列表,將來客戶端可以和這些節點通訊

     2.同步  - 即leader節點負責把本身的資料同步到所有的follower節點上去,做到多副本儲存;follower將佇列中未處理完的

請求消費完成後,寫入本地事物日誌中。

    3.廣播 - 即leader可以接受客戶端新的proposal請求,將新的proposal請求廣播給所有的follower

7.zookeeper滿足CAP理論的CP理論

        原因:可以從ZAB協議的崩潰恢復模式的第二個問題來回答,即當老的leader節點作為follower節點加入

新的leader領導的叢集中去的時候,新的leader會把老的leader節點中未提交的事務proposal丟棄,

這樣就犧牲了一定的可用性