Zookeeper 思維導(dǎo)圖

作者：洪永佳

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

---

---

常見相關(guān)問題

ZooKeeper 是什么？

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

節(jié)點類型

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

集群模式

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

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

Zookeeper工作原理

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

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

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

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

• LOOKING：當(dāng)前Server不知道leader是誰，正在搜尋

• LEADING：當(dāng)前Server即為選舉出來的leader

• FOLLOWING：leader已經(jīng)選舉出來，當(dāng)前Server與之同步

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

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

鎖服務(wù)可以分為兩類，一個是保持獨(dú)占，另一個是控制時序。

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

zookeeper是如何選取主leader的？

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

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

1、Zookeeper選主流程(basic paxos)

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

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

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

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

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

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

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

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

Zookeeper同步流程

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

1、Leader等待server連接；

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

3、Leader根據(jù)follower的zxid確定同步點；

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

5、Follower收到uptodate消息后，又可以重新接受client的請求進(jìn)行服務(wù)了。

---

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

-?END -