Zookeeper 思維導圖

作者：洪永佳

來源：SegmentFault 思否社區(qū)

---

---

常見相關問題

ZooKeeper 是什么？

ZooKeeper 是一個分布式的，開放源碼的分布式應用程序協(xié)調服務，是Google 的 Chubby 一個開源的實現，它是集群的管理者，監(jiān)視著集群中各個節(jié)點的狀態(tài)根據節(jié)點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶?？蛻舳说淖x請求可以被集群中的任意一臺機器處理，如果讀請求在節(jié)點上注冊了監(jiān)聽器，這個監(jiān)聽器也是由所連接的zookeeper機器來處理。對于寫請求，這些請求會同時發(fā)給其他zookeeper機器并且達成一致后，請求才會返回成功。因此，隨著zookeeper的集群機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。有序性是zookeeper中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為zxid（Zookeeper Transaction Id）。而讀請求只會相對于更新有序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid。

節(jié)點類型

• PERSISTENT-持久化目錄節(jié)點 客戶端與zookeeper斷開連接后，該節(jié)點依舊存在
• PERSISTENT_SEQUENTIAL-持久化順序編號目錄節(jié)點 客戶端與zookeeper斷開連接后，該節(jié)點依舊存在，只是Zookeeper給該節(jié)點名稱進行順序編號
• EPHEMERAL-臨時目錄節(jié)點 客戶端與zookeeper斷開連接后，該節(jié)點被刪除
• EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節(jié)點?？蛻舳伺czookeeper斷開連接后，該節(jié)點被刪除，只是Zookeeper給該節(jié)點名稱進行順序編號

集群模式

在 ZooKeeper 集群中將服務器分成 Leader 、Follow 、Observer 三種角色服務器，在集群運行期間這三種服務器所負責的工作各不相同：

• Leader 角色服務器負責管理集群中其他的服務器，是集群中工作的分配和調度者。
• Follow 服務器的主要工作是選舉出 Leader 服務器，在發(fā)生 Leader 服務器選舉的時候，系統(tǒng)會從 Follow 服務器之間根據多數投票原則，選舉出一個 Follow 服務器作為新的 Leader 服務器。
• Observer 服務器則主要負責處理來自客戶端的獲取數據等請求，并不參與 Leader 服務器的選舉操作，也不會作為候選者被選舉為 Leader 服務器。

Zookeeper工作原理

Zookeeper 的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協(xié)議叫做Zab協(xié)議。

Zab協(xié)議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態(tài)同步以后，恢復模式就結束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。

Zookeeper 下 Server工作狀態(tài)

每個Server在工作過程中有三種狀態(tài)：

• LOOKING：當前Server不知道leader是誰，正在搜尋

• LEADING：當前Server即為選舉出來的leader

• FOLLOWING：leader已經選舉出來，當前Server與之同步

Zookeeper分布式鎖（文件系統(tǒng)、通知機制）

有了zookeeper的一致性文件系統(tǒng)，鎖的問題變得容易。

鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。

對于第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點，最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創(chuàng)建的distribute_lock 節(jié)點就釋放出鎖。對于第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創(chuàng)建臨時順序編號目錄節(jié)點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。

zookeeper是如何選取主leader的？

當leader崩潰或者leader失去大多數的follower，這時zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的Server都恢復到一個正確的狀態(tài)。

Zk的選舉算法有兩種：一種是基于basic paxos實現的，另外一種是基于fast paxos算法實現的。系統(tǒng)默認的選舉算法為fast paxos。

1、Zookeeper選主流程(basic paxos)

（1）選舉線程由當前Server發(fā)起選舉的線程擔任，其主要功能是對投票結果進行統(tǒng)計，并選出推薦的Server；

（2）選舉線程首先向所有Server發(fā)起一次詢問(包括自己)；

（3）選舉線程收到回復后，驗證是否是自己發(fā)起的詢問(驗證zxid是否一致)，然后獲取對方的id(myid)，并存儲到當前詢問對象列表中，最后獲取對方提議的leader相關信息(id,zxid)，并將這些信息存儲到當次選舉的投票記錄表中；

（4）收到所有Server回復以后，就計算出zxid最大的那個Server，并將這個Server相關信息設置成下一次要投票的Server；

（5）線程將當前zxid最大的Server設置為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數，設置當前推薦的leader為獲勝的Server，將根據獲勝的Server相關信息設置自己的狀態(tài)，否則，繼續(xù)這個過程，直到leader被選舉出來。

通過流程分析我們可以得出：要使Leader獲得多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少于n+1. 每個Server啟動后都會重復以上流程。

在恢復模式下，如果是剛從崩潰狀態(tài)恢復的或者剛啟動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日志并定期進行快照，方便在恢復時進行狀態(tài)恢復。

2、Zookeeper選主流程(basic paxos) fast paxos流程是在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提議以后，解決epoch和 zxid的沖突，并接受對方的提議，然后向對方發(fā)送接受提議完成的消息，重復這個流程，最后一定能選舉出Leader。

Zookeeper同步流程

選完Leader以后，zk就進入狀態(tài)同步過程。

1、Leader等待server連接；

2、Follower連接leader，將最大的zxid發(fā)送給leader；

3、Leader根據follower的zxid確定同步點；

4、完成同步后通知follower 已經成為uptodate狀態(tài)；

5、Follower收到uptodate消息后，又可以重新接受client的請求進行服務了。

---

點擊左下角閱讀原文，到?SegmentFault 思否社區(qū)?和文章作者展開更多互動和交流，或掃描下方二維碼添加“?SF 思否小姐姐?”，回復“?入群?”即可加入我們的技術交流群，收獲更多的技術文章~

-?END -