Zookeeper知識(shí)點(diǎn)有哪些

這篇文章主要介紹“Zookeeper知識(shí)點(diǎn)有哪些”的相關(guān)知識(shí)，小編通過(guò)實(shí)際案例向大家展示操作過(guò)程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“Zookeeper知識(shí)點(diǎn)有哪些”文章能幫助大家解決問(wèn)題。

Zookeeper 隊(duì)列管理（文件系統(tǒng)、通知機(jī)制）

兩種類(lèi)型的隊(duì)列：

1、同步隊(duì)列，當(dāng)一個(gè)隊(duì)列的成員都聚齊時(shí)，這個(gè)隊(duì)列才可用，否則一直等待所有成員到達(dá)。

2、隊(duì)列按照 FIFO 方式進(jìn)行入隊(duì)和出隊(duì)操作。

第一類(lèi)，在約定目錄下創(chuàng)建臨時(shí)目錄節(jié)點(diǎn)，監(jiān)聽(tīng)節(jié)點(diǎn)數(shù)目是否是我們要求的數(shù)目。

第二類(lèi)，和分布式鎖服務(wù)中的控制時(shí)序場(chǎng)景基本原理一致，入列有編號(hào)，出列按編號(hào)。在特定的目錄下創(chuàng)建

PERSISTENT_SEQUENTIAL 節(jié)點(diǎn)，創(chuàng)建成功時(shí) Watcher 通知等待的隊(duì)列，隊(duì)列刪除序列號(hào)最小的節(jié)點(diǎn)用以

消費(fèi)。此場(chǎng)景下 Zookeeper 的 znode 用于消息存儲(chǔ)，znode 存儲(chǔ)的數(shù)據(jù)就是消息隊(duì)列中的消息內(nèi)容，

SEQUENTIAL 序列號(hào)就是消息的編號(hào)，按序取出即可。由于創(chuàng)建的節(jié)點(diǎn)是持久化的，所以不必?fù)?dān)心隊(duì)列消息的

丟失問(wèn)題。

Zookeeper 數(shù)據(jù)復(fù)制Zookeeper 作為一個(gè)集群提供一致的數(shù)據(jù)服務(wù)，自然，

它要在所有機(jī)器間做數(shù)據(jù)復(fù)制。數(shù)據(jù)復(fù)制的好處：

1、容錯(cuò)：一個(gè)節(jié)點(diǎn)出錯(cuò)，不致于讓整個(gè)系統(tǒng)停止工作，別的節(jié)點(diǎn)可以接管它的工作；

2、提高系統(tǒng)的擴(kuò)展能力 ：把負(fù)載分布到多個(gè)節(jié)點(diǎn)上，或者增加節(jié)點(diǎn)來(lái)提高系統(tǒng)的負(fù)載能力；

3、提高性能：讓客戶(hù)端本地訪問(wèn)就近的節(jié)點(diǎn)，提高用戶(hù)訪問(wèn)速度。

從客戶(hù)端讀寫(xiě)訪問(wèn)的透明度來(lái)看，數(shù)據(jù)復(fù)制集群系統(tǒng)分下面兩種：

1、寫(xiě)主(WriteMaster) ：對(duì)數(shù)據(jù)的修改提交給指定的節(jié)點(diǎn)。讀無(wú)此限制，可以讀取任何一個(gè)節(jié)點(diǎn)。這種情況下

客戶(hù)端需要對(duì)讀與寫(xiě)進(jìn)行區(qū)別，俗稱(chēng)讀寫(xiě)分離；

2、寫(xiě)任意(Write Any)：對(duì)數(shù)據(jù)的修改可提交給任意的節(jié)點(diǎn)，跟讀一樣。這種情況下，客戶(hù)端對(duì)集群節(jié)點(diǎn)的角

色與變化透明。

對(duì) zookeeper 來(lái)說(shuō)，它采用的方式是寫(xiě)任意。通過(guò)增加機(jī)器，它的讀吞吐能力和響應(yīng)能力擴(kuò)展性非常好，而

寫(xiě)，隨著機(jī)器的增多吞吐能力肯定下降（這也是它建立 observer 的原因），而響應(yīng)能力則取決于具體實(shí)現(xiàn)方

式，是延遲復(fù)制保持最終一致性，還是立即復(fù)制快速響應(yīng)。

Zookeeper 工作原理

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

議。Zab 協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主）和廣播模式（同步）。當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰

后，Zab 就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來(lái)，且大多數(shù) Server 完成了和 leader 的狀態(tài)同步以后，恢復(fù)

模式就結(jié)束了。狀態(tài)同步保證了 leader 和 Server 具有相同的系統(tǒng)狀態(tài)。

zookeeper 是如何保證事務(wù)的順序一致性

的？

zookeeper 采用了遞增的事務(wù) Id 來(lái)標(biāo)識(shí)，所有的 proposal（提議）都在被提出的時(shí)候加上了 zxid，zxid 實(shí)際

上是一個(gè) 64 位的數(shù)字，高 32 位是 epoch（時(shí)期; 紀(jì)元; 世; 新時(shí)代）用來(lái)標(biāo)識(shí) leader 是否發(fā)生改變，如果有

新的 leader 產(chǎn)生出來(lái)，epoch 會(huì)自增，低 32 位用來(lái)遞增計(jì)數(shù)。當(dāng)新產(chǎn)生 proposal 的時(shí)候，會(huì)依據(jù)數(shù)據(jù)庫(kù)的

兩階段過(guò)程，首先會(huì)向其他的 server 發(fā)出事務(wù)執(zhí)行請(qǐng)求，如果超過(guò)半數(shù)的機(jī)器都能執(zhí)行并且能夠成功，那么就

會(huì)開(kāi)始執(zhí)行。

Zookeeper 下 Server 工作狀態(tài)每個(gè) Server 在工作過(guò)程中有三種狀態(tài)：

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

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

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

zookeeper 是如何選取主 leader 的？

當(dāng) leader 崩潰或者 leader 失去大多數(shù)的 follower，這時(shí) zk 進(jìn)入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個(gè)新的

leader，讓所有的 Server 都恢復(fù)到一個(gè)正確的狀態(tài)。Zk 的選舉算法有兩種：一種是基于 basic paxos 實(shí)現(xiàn)

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

1、Zookeeper 選主流程(basic paxos)

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

Server；

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

（3）選舉線程收到回復(fù)后，驗(yàn)證是否是自己發(fā)起的詢(xún)問(wèn)(驗(yàn)證 zxid 是否一致)，然后獲取對(duì)方的 id(myid)，并存

儲(chǔ)到當(dāng)前詢(xún)問(wèn)對(duì)象列表中，最后獲取對(duì)方提議的 leader 相關(guān)信息(id,zxid)，并將這些信息存儲(chǔ)到當(dāng)次選舉的投

票記錄表中；

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

要投票的 Server；

（5）線程將當(dāng)前 zxid 最大的 Server 設(shè)置為當(dāng)前 Server 要推薦的 Leader，如果此時(shí)獲勝的 Server 獲得 n/2

+ 1 的 Server 票數(shù)，設(shè)置當(dāng)前推薦的 leader 為獲勝的 Server，將根據(jù)獲勝的 Server 相關(guān)信息設(shè)置自己的狀

態(tài)，否則，繼續(xù)這個(gè)過(guò)程，直到 leader 被選舉出來(lái)。 通過(guò)流程分析我們可以得出：要使 Leader 獲得多數(shù)

Server 的支持，則 Server 總數(shù)必須是奇數(shù) 2n+1，且存活的 Server 的數(shù)目不得少于 n+1. 每個(gè) Server 啟動(dòng)后

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

2、Zookeeper 選主流程(basic paxos)

fast paxos 流程是在選舉過(guò)程中，某 Server 首先向所有 Server 提議自己要成為 leader，當(dāng)其它 Server 收到提

議以后，解決 epoch 和 zxid 的沖突，并接受對(duì)方的提議，然后向?qū)Ψ桨l(fā)送接受提議完成的消息，重復(fù)這個(gè)流程，最后一定能選舉出 Leader。

Zookeeper 同步流程

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

1、Leader 等待 server 連接；

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

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

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

5、Follower 收到 uptodate 消息后，又可以重新接受 client 的請(qǐng)求進(jìn)行服務(wù)了。19.分布式通知和協(xié)調(diào)

對(duì)于系統(tǒng)調(diào)度來(lái)說(shuō)：操作人員發(fā)送通知實(shí)際是通過(guò)控制臺(tái)改變某個(gè)節(jié)點(diǎn)的狀態(tài)，然后 zk 將這些變化發(fā)送給注冊(cè)

了這個(gè)節(jié)點(diǎn)的 watcher 的所有客戶(hù)端。

對(duì)于執(zhí)行情況匯報(bào)：每個(gè)工作進(jìn)程都在某個(gè)目錄下創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)。并攜帶工作的進(jìn)度數(shù)據(jù)，這樣匯總的進(jìn)

程可以監(jiān)控目錄子節(jié)點(diǎn)的變化獲得工作進(jìn)度的實(shí)時(shí)的全局情況。

機(jī)器中為什么會(huì)有 leader？

在分布式環(huán)境中，有些業(yè)務(wù)邏輯只需要集群中的某一臺(tái)機(jī)器進(jìn)行執(zhí)行，其他的機(jī)器可以共享這個(gè)結(jié)果，這樣可

以大大減少重復(fù)計(jì)算，提高性能，于是就需要進(jìn)行 leader 選舉。

zk 節(jié)點(diǎn)宕機(jī)如何處理？

Zookeeper 本身也是集群，推薦配置不少于 3 個(gè)服務(wù)器。Zookeeper 自身也要保證當(dāng)一個(gè)節(jié)點(diǎn)宕機(jī)時(shí)，其他

節(jié)點(diǎn)會(huì)繼續(xù)提供服務(wù)。

如果是一個(gè) Follower 宕機(jī)，還有 2 臺(tái)服務(wù)器提供訪問(wèn)，因?yàn)?Zookeeper 上的數(shù)據(jù)是有多個(gè)副本的，數(shù)據(jù)并不

會(huì)丟失；

如果是一個(gè) Leader 宕機(jī)，Zookeeper 會(huì)選舉出新的 Leader。

ZK 集群的機(jī)制是只要超過(guò)半數(shù)的節(jié)點(diǎn)正常，集群就能正常提供服務(wù)。只有在 ZK 節(jié)點(diǎn)掛得太多，只剩一半或不

到一半節(jié)點(diǎn)能工作，集群才失效。

所以

3 個(gè)節(jié)點(diǎn)的 cluster 可以掛掉 1 個(gè)節(jié)點(diǎn)(leader 可以得到 2 票>1.5)

2 個(gè)節(jié)點(diǎn)的 cluster 就不能掛掉任何 1 個(gè)節(jié)點(diǎn)了(leader 可以得到 1 票<=1)

zookeeper 負(fù)載均衡和 nginx 負(fù)載均衡區(qū)別

zk 的負(fù)載均衡是可以調(diào)控，nginx 只是能調(diào)權(quán)重，其他需要可控的都需要自己寫(xiě)插件；但是 nginx 的吞吐量比

zk 大很多，應(yīng)該說(shuō)按業(yè)務(wù)選擇用哪種方式。23.zookeeper watch 機(jī)制

Watch 機(jī)制官方聲明：一個(gè) Watch 事件是一個(gè)一次性的觸發(fā)器，當(dāng)被設(shè)置了 Watch 的數(shù)據(jù)發(fā)生了改變的時(shí)

候，則服務(wù)器將這個(gè)改變發(fā)送給設(shè)置了 Watch 的客戶(hù)端，以便通知它們。

Zookeeper 機(jī)制的特點(diǎn)：

1、一次性觸發(fā)數(shù)據(jù)發(fā)生改變時(shí)，一個(gè) watcher event 會(huì)被發(fā)送到 client，但是 client 只會(huì)收到一次這樣的信

息。

2、watcher event 異步發(fā)送 watcher 的通知事件從 server 發(fā)送到 client 是異步的，這就存在一個(gè)問(wèn)題，不同

的客戶(hù)端和服務(wù)器之間通過(guò) socket 進(jìn)行通信，由于網(wǎng)絡(luò)延遲或其他因素導(dǎo)致客戶(hù)端在不通的時(shí)刻監(jiān)聽(tīng)到事件，

由于 Zookeeper 本身提供了 ordering guarantee，即客戶(hù)端監(jiān)聽(tīng)事件后，才會(huì)感知它所監(jiān)視 znode 發(fā)生了

變化。所以我們使用 Zookeeper 不能期望能夠監(jiān)控到節(jié)點(diǎn)每次的變化。Zookeeper 只能保證最終的一致性，

而無(wú)法保證強(qiáng)一致性。

3、數(shù)據(jù)監(jiān)視 Zookeeper 有數(shù)據(jù)監(jiān)視和子數(shù)據(jù)監(jiān)視 getdata() and exists()設(shè)置數(shù)據(jù)監(jiān)視，getchildren()設(shè)置了

子節(jié)點(diǎn)監(jiān)視。

4、注冊(cè) watcher getData、exists、getChildren

5、觸發(fā) watcher create、delete、setData

6、**setData()**會(huì)觸發(fā) znode 上設(shè)置的 data watch（如果 set 成功的話）。一個(gè)成功的 create() 操作會(huì)觸發(fā)被

創(chuàng)建的 znode 上的數(shù)據(jù) watch，以及其父節(jié)點(diǎn)上的 child watch。而一個(gè)成功的 **delete()**操作將會(huì)同時(shí)觸發(fā)一

個(gè) znode 的 data watch 和 child watch（因?yàn)檫@樣就沒(méi)有子節(jié)點(diǎn)了），同時(shí)也會(huì)觸發(fā)其父節(jié)點(diǎn)的 child

watch。

7、當(dāng)一個(gè)客戶(hù)端連接到一個(gè)新的服務(wù)器上時(shí)，watch 將會(huì)被以任意會(huì)話事件觸發(fā)。當(dāng)與一個(gè)服務(wù)器失去連接的

時(shí)候，是無(wú)法接收到 watch 的。而當(dāng) client 重新連接時(shí)，如果需要的話，所有先前注冊(cè)過(guò)的 watch，都會(huì)被重

新注冊(cè)。通常這是完全透明的。只有在一個(gè)特殊情況下，watch 可能會(huì)丟失：對(duì)于一個(gè)未創(chuàng)建的 znode 的

exist watch，如果在客戶(hù)端斷開(kāi)連接期間被創(chuàng)建了，并且隨后在客戶(hù)端連接上之前又刪除了，這種情況下，這

個(gè) watch 事件可能會(huì)被丟失。

8、Watch 是輕量級(jí)的，其實(shí)就是本地 JVM 的 Callback，服務(wù)器端只是存了是否有設(shè)置了 Watcher 的布爾類(lèi)

型

關(guān)于“Zookeeper知識(shí)點(diǎn)有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。