zookeeper 詳解

是 分布式 協調 服務。

ZK的工作：
注冊：所有節點向ZK爭搶注冊，注冊成功會建立一套節點目錄樹，先注冊的節點為Active節點，后注冊節點成為standby;
監聽事件：節點在ZK集群里注冊監聽動作：比如節點的新增、刪除、更新等事件
回調函數：發生了監聽事件后，ZK集群通知客戶端(zkfc)執行回調函數，回調函數是客戶端定義的

協調機制：
當中一個客戶端向集群任意follower節點請求增刪改動作，follower會通知leader,leader會廣播給所有follower，當收到過半follower回復后，然后執行增刪改動作

如何選舉leader？
sid：標識zk server標識； zxid：標識事務標識
先比較事務ID，事務大的得票；事務相同，再比較server標識，大的得票。

 

專題參考：

一、Zookeeper簡單介紹 
二、ZooKeeper安裝配置 
三、Zookeeper命令操作 
四、構建ZooKeeper應用 
五、ZooKeeper管理分布式環境中的數據 
六、ZooKeeper機制架構 
七、ZooKeeper一致性原理 
八、ZooKeeper伸縮性 

 

ZAB協議

1. ZAB協議是專門為zookeeper實現分布式協調功能而設計。zookeeper主要是根據ZAB協議是實現分布式系統數據一致性。
2. zookeeper根據ZAB協議建立了主備模型完成zookeeper集群中數據的同步。這里所說的主備系統架構模型是指，在zookeeper集群中，只有一台leader負責處理外部客戶端的事物請求(或寫操作)，然后leader服務器將客戶端的寫操作數據同步到所有的follower節點中。 
   
3. ZAB的協議核心是在整個zookeeper集群中只有一個節點即Leader將客戶端的寫操作轉化為事物(或提議proposal)。Leader節點再數據寫完之后，將向所有的follower節點發送數據廣播請求(或數據復制)，等待所有的follower節點反饋。在ZAB協議中，只要超過半數follower節點反饋OK，Leader節點就會向所有的follower服務器發送commit消息。即將leader節點上的數據同步到follower節點之上。 
   
4. ZAB協議中主要有兩種模式，第一是消息廣播模式；第二是崩潰恢復模式

消息廣播模式

1. 在zookeeper集群中數據副本的傳遞策略就是采用消息廣播模式。zookeeper中數據副本的同步方式與二階段提交相似但是卻又不同。二階段提交的要求協調者必須等到所有的參與者全部反饋ACK確認消息后，再發送commit消息。要求所有的參與者要么全部成功要么全部失敗。二階段提交會產生嚴重阻塞問題。
2. ZAB協議中Leader等待follower的ACK反饋是指”只要半數以上的follower成功反饋即可，不需要收到全部follower反饋”
3. 圖中展示了消息廣播的具體流程圖 
   
4. zookeeper中消息廣播的具體步驟如下： 
   4.1. 客戶端發起一個寫操作請求 
   4.2. Leader服務器將客戶端的request請求轉化為事物proposql提案，同時為每個proposal分配一個全局唯一的ID，即ZXID。 
   4.3. leader服務器與每個follower之間都有一個隊列，leader將消息發送到該隊列 
   4.4. follower機器從隊列中取出消息處理完(寫入本地事物日志中)畢后，向leader服務器發送ACK確認。 
   4.5. leader服務器收到半數以上的follower的ACK后，即認為可以發送commit 
   4.6. leader向所有的follower服務器發送commit消息。
5. zookeeper采用ZAB協議的核心就是只要有一台服務器提交了proposal，就要確保所有的服務器最終都能正確提交proposal。這也是CAP/BASE最終實現一致性的一個體現。
6. leader服務器與每個follower之間都有一個單獨的隊列進行收發消息，使用隊列消息可以做到異步解耦。leader和follower之間只要往隊列中發送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。

崩潰恢復

1. zookeeper集群中為保證任何所有進程能夠有序的順序執行，只能是leader服務器接受寫請求，即使是follower服務器接受到客戶端的請求，也會轉發到leader服務器進行處理。
2. 如果leader服務器發生崩潰，則zab協議要求zookeeper集群進行崩潰恢復和leader服務器選舉。
3. ZAB協議崩潰恢復要求滿足如下2個要求： 
   3.1. 確保已經被leader提交的proposal必須最終被所有的follower服務器提交。 
   3.2. 確保丟棄已經被leader出的但是沒有被提交的proposal。
4. 根據上述要求，新選舉出來的leader不能包含未提交的proposal，即新選舉的leader必須都是已經提交了的proposal的follower服務器節點。同時，新選舉的leader節點中含有最高的ZXID。這樣做的好處就是可以避免了leader服務器檢查proposal的提交和丟棄工作。
5. leader服務器發生崩潰時分為如下場景： 
   5.1. leader在提出proposal時未提交之前崩潰，則經過崩潰恢復之后，新選舉的leader一定不能是剛才的leader。因為這個leader存在未提交的proposal。 
   5.2 leader在發送commit消息之后，崩潰。即消息已經發送到隊列中。經過崩潰恢復之后，參與選舉的follower服務器(剛才崩潰的leader有可能已經恢復運行，也屬於follower節點范疇)中有的節點已經是消費了隊列中所有的commit消息。即該follower節點將會被選舉為最新的leader。剩下動作就是數據同步過程。

數據同步

1. 在zookeeper集群中新的leader選舉成功之后，leader會將自身的提交的最大proposal的事物ZXID發送給其他的follower節點。follower節點會根據leader的消息進行回退或者是數據同步操作。最終目的要保證集群中所有節點的數據副本保持一致。
2. 數據同步完之后，zookeeper集群如何保證新選舉的leader分配的ZXID是全局唯一呢？這個就要從ZXID的設計談起。 
   2.1 ZXID是一個長度64位的數字，其中低32位是按照數字遞增，即每次客戶端發起一個proposal,低32位的數字簡單加1。高32位是leader周期的epoch編號，至於這個編號如何產生(我也沒有搞明白)，每當選舉出一個新的leader時，新的leader就從本地事物日志中取出ZXID,然后解析出高32位的epoch編號，進行加1，再將低32位的全部設置為0。這樣就保證了每次新選舉的leader后，保證了ZXID的唯一性而且是保證遞增的。 
   

ZAB協議原理

1. ZAB協議要求每個leader都要經歷三個階段，即發現，同步，廣播。
2. 發現：即要求zookeeper集群必須選擇出一個leader進程，同時leader會維護一個follower可用列表。將來客戶端可以這follower中的節點進行通信。
3. 同步：leader要負責將本身的數據與follower完成同步，做到多副本存儲。這樣也是體現了CAP中高可用和分區容錯。follower將隊列中未處理完的請求消費完成后，寫入本地事物日志中。
4. 廣播：leader可以接受客戶端新的proposal請求，將新的proposal請求廣播給所有的follower。

Zookeeper設計目標

1. zookeeper作為當今最流行的分布式系統應用協調框架，采用zab協議的最大目標就是建立一個高可用可擴展的分布式數據主備系統。即在任何時刻只要leader發生宕機，都能保證分布式系統數據的可靠性和最終一致性。
2. 深刻理解ZAB協議，才能更好的理解zookeeper對於分布式系統建設的重要性。以及為什么采用zookeeper就能保證分布式系統中數據最終一致性，服務的高可用性。

轉自：https://blog.csdn.net/junchenbb0430/article/details/77583955

Zookeeper全解析——Paxos作為靈魂