前言

昨日博主的第一篇ZooKeeper，對它自身具備的能力做了初步介紹。書接上文，馬不停蹄，我們繼續(xù)挖掘它內在的美，充分把握它的核心與脈絡。

揭秘ZooKeeper

Q：集群一致性協(xié)同是如何進行的

我們講到分布式，一般是在集群環(huán)境下實現(xiàn)的。以ZooKeeper為例，它是如何保障集群環(huán)境下的成功運轉呢？

1. 節(jié)點角色

通過上圖，我們認識一下ZooKeeper的3類節(jié)點：

• Leader節(jié)點
  Leader作為ZooKeeper的領袖，有著舉足輕重的作用。它是ZooKeeper集群環(huán)境如何穩(wěn)定運行的關鍵，主要負責讀寫和調度等核心工作。如果它宕機了，一致性調度從此冷卻，整個集群將面臨群龍無首的局面，直至系統(tǒng)癱瘓。
• Follower節(jié)點
  作為隨從節(jié)點，主要負責客戶端的讀操作，如果遇到寫申請， 需要轉發(fā)Leader節(jié)點完成，自身不做任何處理。如Leader宕機，會立即參與Leader的選舉，具有投票權。
• Observer節(jié)點
  作為候選角色，Observer為提升整個集群的執(zhí)行效率提供一定幫助，但僅限于讀操作。不參與寫，不參與Leader的選舉。

了解3類節(jié)點后，我們大概知道每個Server（Node）是如何執(zhí)行客戶端申請以及Server集群內部是如何完成最終一致性協(xié)同的過程。

比如Client對任一類節(jié)點發(fā)起讀操作，則每個節(jié)點均可立即返回本地數(shù)據(jù)，如此便提高了響應性能；
比如Client對Follower節(jié)點發(fā)起寫操作，則它會寫命令轉交Leader完成，最后由Leader完成寫操作和數(shù)據(jù)同步；
比如Leader發(fā)生宕機，則Follower們立即啟動選舉，任命新的Leader。而Observer完全可以“袖手旁觀，置之不理”，此刻真是“開心開心極了...”

2. 基礎協(xié)議

為了實現(xiàn)上述一致性數(shù)據(jù)同步，ZooKeeper基于ZAB（Zookeeper Atomic Broadcast 原子廣播協(xié)議）完成的。

ZAB準確來講提供了一套完整的數(shù)據(jù)同步消息機制。（無論哪類節(jié)點）從接收客戶端請求到客戶端收到實時數(shù)據(jù)，并實現(xiàn)集群內部數(shù)據(jù)寫操作的一致性，均是通過ZAB機制完成的。

通過上圖，我們了解到，Leader負責處理寫請求，如其他節(jié)點接收到寫請求，需轉發(fā)Leader完成。那么Leader收到請求后，如何繼續(xù)工作呢？

1. 發(fā)布全局唯一事務申請zxid（zxid是64位的Long類型）；
2. 所有的Follower均對此申請進行反饋；
3. Leader如收到反饋過半，則執(zhí)行寫提交，最后完成集群同步；

Q：集群選舉如何進行的

我們都知道Leader至關重要，是維持ZooKeeper的集群健康運轉的大腦。但天有不測風云，即使7*24高可用高可靠，也難免百密一疏。如果Leader真的宕機了？ 如何維持集群秩序呢？

接下來，博主帶著各位盆友，繼續(xù)揭秘ZooKeeper中 Leader的選舉過程。

既然有選舉，就有投票，有投票，就有候選人，有投票人。那么候選人和投票人是怎么產生的，最終誰才能勝任？

在正式講解選項過程前，我們先了解一些基礎知識。

1. 節(jié)點狀態(tài)

在ZooKeeper集群中，涉及4中狀態(tài)：

2. 節(jié)點ID

我們在搭建ZooKeeper集群時，一般需要為每個Server（Node）標識一個唯一的編號（從小到大，比如1.2.3，以此類推）。

這個ID一般記錄在每個ZooKeeper Server中的數(shù)據(jù)文件中，安裝時指定。

3. 奇數(shù)

ZooKeeper集群信仰奇數(shù)，為什么? 因為有“過半才OK”的理念。
所以我們在搭建集群時，務必按要求配置，否則ZooKeeper可能無法正常工作哦。

4. 投票選舉Leader

投票結束后，收到票數(shù)過半者則當選新一任Leader，其他節(jié)點自動更新為Follower，而Observer自必不說，全程不參與。

到此為止，我們具備了以上基礎知識后，繼續(xù)回看上圖，是不是可以理解了？

結語

博主通過揭秘ZooKeeper內在的核心邏輯，剖析它是如何完成我們想象中的職責和工作的。通過以上內容，我們可以發(fā)現(xiàn)，無論是什么協(xié)議或算法，均服務于某個業(yè)務和技術場景。所以感謝前輩們的辛勤耕耘，才有ZooKeeper的用武之地。

歷史回顧

• 微服務實戰(zhàn)系列之ZooKeeper（上）
• 微服務實戰(zhàn)系列之MQ
• 微服務實戰(zhàn)系列之通信
• 微服務實戰(zhàn)系列之J2Cache
• 微服務實戰(zhàn)系列之Cache（技巧篇）
• 微服務實戰(zhàn)系列之MemCache
• 微服務實戰(zhàn)系列之EhCache
• 微服務實戰(zhàn)系列之Redis
• 微服務實戰(zhàn)系列之Cache
• 微服務實戰(zhàn)系列之Nginx（技巧篇）
• 微服務實戰(zhàn)系列之Nginx
• 微服務實戰(zhàn)系列之Feign
• 微服務實戰(zhàn)系列之Sentinel
• 微服務實戰(zhàn)系列之Token
• 微服務實戰(zhàn)系列之Nacos
• 微服務實戰(zhàn)系列之Gateway
• 微服務實戰(zhàn)系列之加密RSA
• 微服務實戰(zhàn)系列之簽名Sign

文章來源地址http://www.zghlxwxcb.cn/news/detail-763234.html

到了這里，關于微服務實戰(zhàn)系列之ZooKeeper（中）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！