ZooKeeper的基本原理講解

這篇文章主要講解了“ZooKeeper的基本原理講解”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“ZooKeeper的基本原理講解”吧！

ZooKeeper 簡介

ZooKeeper是一個開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，它包含一個簡單的原語集，分布式應(yīng)用程序可以基于它實現(xiàn)同步服務(wù)，配置維護(hù)和命名服務(wù)等。

ZooKeeper 設(shè)計目的

1. 最終一致性：client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。

2. 可靠性：具有簡單、健壯、良好的性能，如果消息m被到一臺服務(wù)器接受，那么它將被所有的服務(wù)器接受。

3. 實時性：Zookeeper保證客戶端將在一個時間間隔范圍內(nèi)獲得服務(wù)器的更新信息，或者服務(wù)器失效的信息。

但由于網(wǎng)絡(luò)延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數(shù)據(jù)，如果需要最新數(shù)據(jù)，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口。

4. 等待無關(guān)（wait-free）：慢的或者失效的client不得干預(yù)快速的client的請求，使得每個client都能有效的等待。

5. 原子性：更新只能成功或者失敗，沒有中間狀態(tài)。

6. 順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺服務(wù)器上消息a在消息b前發(fā)布，則在所有Server上消息a都將在消息b前被發(fā)布；偏序是指如果一個消息b在消息a后被同一個發(fā)送者發(fā)布，a必將排在b前面。

ZooKeeper數(shù)據(jù)模型

Zookeeper會維護(hù)一個具有層次關(guān)系的數(shù)據(jù)結(jié)構(gòu)，它非常類似于一個標(biāo)準(zhǔn)的文件系統(tǒng)，如圖所示：

Zookeeper這種數(shù)據(jù)結(jié)構(gòu)有如下這些特點：

1）每個子目錄項如NameService都被稱作為znode，這個znode是被它所在的路徑唯一標(biāo)識，如Server1這個znode的標(biāo)識為/NameService/Server1。

2）znode可以有子節(jié)點目錄，并且每個znode可以存儲數(shù)據(jù)，注意EPHEMERAL（臨時的）類型的目錄節(jié)點不能有子節(jié)點目錄。

3）znode是有版本的（version），每個znode中存儲的數(shù)據(jù)可以有多個版本，也就是一個訪問路徑中可以存儲多份數(shù)據(jù)，version號自動增加。

4）znode的類型：

•  Persistent 節(jié)點，一旦被創(chuàng)建，便不會意外丟失，即使服務(wù)器全部重啟也依然存在。每個 Persist 節(jié)點即可包含數(shù)據(jù)，也可包含子節(jié)點。

•  Ephemeral 節(jié)點，在創(chuàng)建它的客戶端與服務(wù)器間的 Session 結(jié)束時自動被刪除。服務(wù)器重啟會導(dǎo)致 Session 結(jié)束，因此 Ephemeral 類型的 znode 此時也會自動刪除。

•  Non-sequence 節(jié)點，多個客戶端同時創(chuàng)建同一 Non-sequence 節(jié)點時，只有一個可創(chuàng)建成功，其它勻失敗。并且創(chuàng)建出的節(jié)點名稱與創(chuàng)建時指定的節(jié)點名完全一樣。

•  Sequence 節(jié)點，創(chuàng)建出的節(jié)點名在指定的名稱之后帶有10位10進(jìn)制數(shù)的序號。多個客戶端創(chuàng)建同一名稱的節(jié)點時，都能創(chuàng)建成功，只是序號不同。

5）znode可以被監(jiān)控，包括這個目錄節(jié)點中存儲的數(shù)據(jù)的修改，子節(jié)點目錄的變化等，一旦變化可以通知設(shè)置監(jiān)控的客戶端，這個是Zookeeper的核心特性，Zookeeper的很多功能都是基于這個特性實現(xiàn)的。

6）ZXID：每次對Zookeeper的狀態(tài)的改變都會產(chǎn)生一個zxid（ZooKeeper Transaction Id），zxid是全局有序的，如果zxid1小于zxid2，則zxid1在zxid2之前發(fā)生。

ZooKeeper Session

Client和Zookeeper集群建立連接，整個session狀態(tài)變化如圖所示：

如果Client因為Timeout和Zookeeper Server失去連接，client處在CONNECTING狀態(tài)，會自動嘗試再去連接Server，如果在session有效期內(nèi)再次成功連接到某個Server，則回到CONNECTED狀態(tài)。

注意：如果因為網(wǎng)絡(luò)狀態(tài)不好，client和Server失去聯(lián)系，client會停留在當(dāng)前狀態(tài)，會嘗試主動再次連接Zookeeper Server。client不能宣稱自己的session expired，session expired是由Zookeeper Server來決定的，client可以選擇自己主動關(guān)閉session。

ZooKeeper Watch

Zookeeper watch是一種監(jiān)聽通知機(jī)制。Zookeeper所有的讀操作getData(), getChildren()和 exists()都可以設(shè)置監(jiān)視(watch)，監(jiān)視事件可以理解為一次性的觸發(fā)器

官方定義如下：

a watch event is one-time trigger, sent to the client that set the watch, whichoccurs when the data for which the watch was set changes。

Watch的三個關(guān)鍵點：

• （一次性觸發(fā)）One-time trigger

當(dāng)設(shè)置監(jiān)視的數(shù)據(jù)發(fā)生改變時，該監(jiān)視事件會被發(fā)送到客戶端。

例如，如果客戶端調(diào)用了getData(/znode1, true) 并且稍后 /znode1 節(jié)點上的數(shù)據(jù)發(fā)生了改變或者被刪除了，客戶端將會獲取到 /znode1 發(fā)生變化的監(jiān)視事件；

而如果 /znode1 再一次發(fā)生了變化，除非客戶端再次對/znode1 設(shè)置監(jiān)視，否則客戶端不會收到事件通知。

•  （發(fā)送至客戶端）Sent to the client

Zookeeper客戶端和服務(wù)端是通過 socket 進(jìn)行通信的，由于網(wǎng)絡(luò)存在故障，所以監(jiān)視事件很有可能不會成功地到達(dá)客戶端，監(jiān)視事件是異步發(fā)送至監(jiān)視者的。

Zookeeper 本身提供了順序保證(ordering guarantee)：即客戶端只有首先看到了監(jiān)視事件后，才會感知到它所設(shè)置監(jiān)視的znode發(fā)生了變化(a client will never see a change for which it has set a watch until it first sees the watch event)。

網(wǎng)絡(luò)延遲或者其他因素可能導(dǎo)致不同的客戶端在不同的時刻感知某一監(jiān)視事件，但是不同的客戶端所看到的一切具有一致的順序。

•  （被設(shè)置 watch 的數(shù)據(jù)）The data for which the watch was set

這意味著znode節(jié)點本身具有不同的改變方式。你也可以想象 Zookeeper 維護(hù)了兩條監(jiān)視鏈表：數(shù)據(jù)監(jiān)視和子節(jié)點監(jiān)視(data watches and child watches) getData() 和exists()設(shè)置數(shù)據(jù)監(jiān)視，getChildren()設(shè)置子節(jié)點監(jiān)視。

或者你也可以想象 Zookeeper 設(shè)置的不同監(jiān)視返回不同的數(shù)據(jù)，getData() 和 exists() 返回znode節(jié)點的相關(guān)信息，而getChildren() 返回子節(jié)點列表。

因此，setData() 會觸發(fā)設(shè)置在某一節(jié)點上所設(shè)置的數(shù)據(jù)監(jiān)視（假定數(shù)據(jù)設(shè)置成功），而一次成功的create() 操作則會出發(fā)當(dāng)前節(jié)點上所設(shè)置的數(shù)據(jù)監(jiān)視以及父節(jié)點的子節(jié)點監(jiān)視。

一次成功的 delete操作將會觸發(fā)當(dāng)前節(jié)點的數(shù)據(jù)監(jiān)視和子節(jié)點監(jiān)視事件，同時也會觸發(fā)該節(jié)點父節(jié)點的child watch。

Zookeeper 中的監(jiān)視是輕量級的，因此容易設(shè)置、維護(hù)和分發(fā)。當(dāng)客戶端與 Zookeeper 服務(wù)器失去聯(lián)系時，客戶端并不會收到監(jiān)視事件的通知，只有當(dāng)客戶端重新連接后，若在必要的情況下，以前注冊的監(jiān)視會重新被注冊并觸發(fā)，對于開發(fā)人員來說這通常是透明的。

只有一種情況會導(dǎo)致監(jiān)視事件的丟失，即：通過exists()設(shè)置了某個znode節(jié)點的監(jiān)視，但是如果某個客戶端在此znode節(jié)點被創(chuàng)建和刪除的時間間隔內(nèi)與zookeeper服務(wù)器失去了聯(lián)系，該客戶端即使稍后重新連接 zookeeper服務(wù)器后也得不到事件通知。

Consistency Guarantees

Zookeeper是一個高效的、可擴(kuò)展的服務(wù)，read和write操作都被設(shè)計為快速的，read比write操作更快。

順序一致性（Sequential Consistency）：從一個客戶端來的更新請求會被順序執(zhí)行。

原子性（Atomicity）：更新要么成功要么失敗，沒有部分成功的情況。

唯一的系統(tǒng)鏡像（Single System Image）：無論客戶端連接到哪個Server，看到系統(tǒng)鏡像是一致的。

可靠性（Reliability）：更新一旦有效，持續(xù)有效，直到被覆蓋。

時間線（Timeliness）：保證在一定的時間內(nèi)各個客戶端看到的系統(tǒng)信息是一致的。

ZooKeeper的工作原理

在zookeeper的集群中，各個節(jié)點共有下面3種角色和4種狀態(tài)：

•  角色：leader,follower,observer

•  狀態(tài)：leading,following,observing,looking

Zookeeper的核心是原子廣播，這個機(jī)制保證了各個Server之間的同步。實現(xiàn)這個機(jī)制的協(xié)議叫做Zab協(xié)議（ZooKeeper Atomic Broadcast protocol）。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（Recovery選主）和廣播模式（Broadcast同步）。

當(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)。

為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號（zxid）來標(biāo)識事務(wù)。所有的提議（proposal）都在被提出的時候加上了zxid。

實現(xiàn)中zxid是一個64位的數(shù)字，它高32位是epoch用來標(biāo)識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一個新的epoch，標(biāo)識當(dāng)前屬于那個leader的統(tǒng)治時期。低32位用于遞增計數(shù)。

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

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

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

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

OBSERVING：observer的行為在大多數(shù)情況下與follower完全一致，但是他們不參加選舉和投票，而僅僅接受(observing)選舉和投票的結(jié)果。

Leader Election

當(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。先介紹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ù)。

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

Leader工作流程

Leader主要有三個功能：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  恢復(fù)數(shù)據(jù)；

3.  維持與follower的心跳，接收follower請求并判斷follower的請求消息類型；

4.  follower的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據(jù)不同的消息類型，進(jìn)行不同的處理。

說明：

PING消息是指follower的心跳信息；REQUEST消息是follower發(fā)送的提議信息，包括寫請求及同步請求；

ACK消息是follower的對提議的回復(fù)，超過半數(shù)的follower通過，則commit該提議；

REVALIDATE消息是用來延長SESSION有效時間。

Follower工作流程

Follower主要有四個功能：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  向Leader發(fā)送請求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

3.  接收Leader消息并進(jìn)行處理；

4.  接收Client的請求，如果為寫請求，發(fā)送給Leader進(jìn)行投票；

5.  返回Client結(jié)果。

Follower的消息循環(huán)處理如下幾種來自Leader的消息：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  PING消息：心跳消息

3.  PROPOSAL消息：Leader發(fā)起的提案，要求Follower投票

4.  OMMIT消息：服務(wù)器端最新一次提案的信息

5.  UPTODATE消息：表明同步完成

6.  REVALIDATE消息：根據(jù)Leader的REVALIDATE結(jié)果，關(guān)閉待revalidate的session還是允許其接受消息

7.  SYNC消息：返回SYNC結(jié)果到客戶端，這個消息最初由客戶端發(fā)起，用來強制得到最新的更新。

Zab: Broadcasting State Updates

Zookeeper Server接收到一次request，如果是follower，會轉(zhuǎn)發(fā)給leader，Leader執(zhí)行請求并通過Transaction的形式廣播這次執(zhí)行。

Zookeeper集群如何決定一個Transaction是否被commit執(zhí)行？通過“兩段提交協(xié)議”（a two-phase commit）：

•  Leader給所有的follower發(fā)送一個PROPOSAL消息。

•  一個follower接收到這次PROPOSAL消息，寫到磁盤，發(fā)送給leader一個ACK消息，告知已經(jīng)收到。

•  當(dāng)Leader收到法定人數(shù)（quorum）的follower的ACK時候，發(fā)送commit消息執(zhí)行。

Zab協(xié)議保證：

•  如果leader以T1和T2的順序廣播，那么所有的Server必須先執(zhí)行T1，再執(zhí)行T2。

•  如果任意一個Server以T1、T2的順序commit執(zhí)行，其他所有的Server也必須以T1、T2的順序執(zhí)行。

“兩段提交協(xié)議”最大的問題是如果Leader發(fā)送了PROPOSAL消息后crash或暫時失去連接，會導(dǎo)致整個集群處在一種不確定的狀態(tài)（follower不知道該放棄這次提交還是執(zhí)行提交）。

Zookeeper這時會選出新的leader，請求處理也會移到新的leader上，不同的leader由不同的epoch標(biāo)識。切換Leader時，需要解決下面兩個問題：

1. Never forget delivered messages

Leader在COMMIT投遞到任何一臺follower之前crash，只有它自己commit了。新Leader必須保證這個事務(wù)也必須commit。

2. Let go of messages that are skipped

Leader產(chǎn)生某個proposal，但是在crash之前，沒有follower看到這個proposal。該server恢復(fù)時，必須丟棄這個proposal。

Zookeeper會盡量保證不會同時有2個活動的Leader，因為2個不同的Leader會導(dǎo)致集群處在一種不一致的狀態(tài)，所以Zab協(xié)議同時保證：

•  在新的leader廣播Transaction之前，先前Leader commit的Transaction都會先執(zhí)行。

•  在任意時刻，都不會有2個Server同時有法定人數(shù)（quorum）的支持者。

        這里的quorum是一半以上的Server數(shù)目，確切的說是有投票權(quán)力的Server（不包括Observer）。

感謝各位的閱讀，以上就是“ZooKeeper的基本原理講解”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對ZooKeeper的基本原理講解這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！