ZooKeeper快速入門系列(3) | Zookeeper的內部原理(六大原理)

經過上一篇博文的簡單介紹，相信大家對ZooKeeper有了更深一步的了解，那么，此篇博文，開始講述Zookeeper的內部原理。

目錄

1. 選舉機制(重點)

2. 節點類型

2.1 Znode有兩種類型：

2.2 Znode有四種形式的目錄節點（默認是persistent ）

3. Stat結構體

4. -原理(重點)

5. Paxos算法

5.1 圖形解釋

5.2 Paxos算法流程中的每條消息描述如下

6. 寫數據流程

1. 選舉機制(重點)

1. 半 數 機 制 ： 集 群 中 半 數 以 上 機 器 存 活 ， 集 群 可 用 。 所 以 Z o o k e e p e r 適 合 安 裝 奇 數 臺 服 務 器 。 \color{#FF0000}{1. 半數機制：集群中半數以上機器存活，集群可用。所以Zookeeper適合安裝奇數臺服務器。} 1.半數機制：集群中半數以上機器存活，集群可用。所以Zookeeper適合安裝奇數臺服務器。

2. Zookeeper雖然在配置文件中并沒有指定 M a s t e r 和 S l a v e 。 \color{#FF0000}{Master和Slave。} Master和Slave。但是，Zookeeper工作時，是有一個節點為Leader，其他則為Follower，Leader是通過內部的選舉機制臨時產生的。

3. 以一個簡單的例子來說明整個選舉的過程。

假設有五臺服務器組成的Zookeeper集群，它們的id從1-5，同時它們都是最新啟動的，也就是沒有歷史數據，在存放數據量這一點上，都是一樣的。假設這些服務器依序啟動，來看看會發生什么，如下圖所示。

過程詳解：

（1）服務器1啟動，發起一次選舉。服務器1投自己一票。此時服務器1票數一票，不夠半數以上（3票），選舉無法完成，服務器1狀態保持為LOOKING；

（2）服務器2啟動，再發起一次選舉。服務器1和2分別投自己一票并交換選票信息：此時服務器1發現服務器2的ID比自己目前投票推舉的（服務器1）大，更改選票為推舉服務器2。此時服務器1票數0票，服務器2票數2票，沒有半數以上結果，選舉無法完成，服務器1，2狀態保持LOOKING

（3）服務器3啟動，發起一次選舉。此時服務器1和2都會更改選票為服務器3。此次投票結果：服務器1為0票，服務器2為0票，服務器3為3票。此時服務器3的票數已經超過半數，服務器3當選Leader。服務器1，2更改狀態為FOLLOWING，服務器3更改狀態為LEADING；

（4）服務器4啟動，發起一次選舉。此時服務器1，2，3已經不是LOOKING狀態，不會更改選票信息。交換選票信息結果：服務器3為3票，服務器4為1票。此時服務器4服從多數，更改選票信息為服務器3，并更改狀態為FOLLOWING；

（5）服務器5啟動，同4一樣當小弟。

2. 節點類型

2.1 Znode有兩種類型：

短暫（ephemeral）：客戶端和服務器端斷開連接后，創建的節點自動刪除

持久（persistent）：客戶端和服務器端斷開連接后，創建的節點不刪除

2.2 Znode有四種形式的目錄節點（默認是persistent ）

持久化目錄節點（PERSISTENT）

客戶端與zookeeper斷開連接后，該節點依舊存在

持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）

客戶端與zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

臨時目錄節點（EPHEMERAL）

客戶端與zookeeper斷開連接后，該節點被刪除

臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）

客戶端與zookeeper斷開連接后，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

說明：創建znode時設置順序標識，znode名稱后會附加一個值，順序號是一個單調遞增的計數器，由父節點維護

注 意 ： 在 分 布 式 系 統 中 ， 順 序 號 可 以 被 用 于 為 所 有 的 事 件 進 行 全 局 排 序 ， 這 樣 客 戶 端 可 以 通 過 順 序 號 推 斷 事 件 的 順 序 \color{#FF0000}{注意：在分布式系統中，順序號可以被用于為所有的事件進行全局排序，這樣客戶端可以通過順序號推斷事件的順序} 注意：在分布式系統中，順序號可以被用于為所有的事件進行全局排序，這樣客戶端可以通過順序號推斷事件的順序

3. Stat結構體

czxid-創建節點的事務zxid

每次修改ZooKeeper狀態都會收到一個zxid形式的時間戳，也就是ZooKeeper事務ID。

事務ID是ZooKeeper中所有修改總的次序。每個修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前發生。

ctime - znode被創建的毫秒數(從1970年開始)

mzxid - znode最后更新的事務zxid

mtime - znode最后修改的毫秒數(從1970年開始)

pZxid-znode最后更新的子節點zxid

cversion - znode子節點變化號，znode子節點修改次數

dataversion - znode數據變化號

aclVersion - znode訪問控制列表的變化號

ephemeralOwner- 如果是臨時節點，這個是znode擁有者的session id。如果不是臨時節點則是0。

d a t a L e n g t h ? z n o d e 的 數 據 長 度 \color{#FF0000}{dataLength- znode的數據長度} dataLength?znode的數據長度

n u m C h i l d r e n ? z n o d e 子 節 點 數 量 \color{#FF0000}{numChildren - znode子節點數量} numChildren?znode子節點數量

4. -原理(重點)

1. 監 聽 原 理 詳 解 ： \color{#FF0000}{1. 監聽原理詳解：} 1.監聽原理詳解：

2. 常見的監聽：

1. 監聽節點數據的變化：get path [watch]

2. 監聽子節點增減的變化：ls path [watch]

5. Paxos算法

Paxos算法一種基于消息傳遞且具有高度容錯特性的一致性算法。

分布式系統中的節點通信存在兩種模型：共享內存（Shared memory）和消息傳遞（Messages passing）。基于消息傳遞通信模型的分布式系統，不可避免的會發生以下錯誤：進程可能會慢、被殺死或者重啟，消息可能會延遲、丟失、重復，在基礎 Paxos 場景中，先不考慮可能出現消息篡改即拜占庭錯誤的情況。Paxos 算法解決的問題是在一個可能發生上述異常的分布式系統中如何就某個值達成一致，保證不論發生以上任何異常，都不會破壞決議的一致性。

5.1 圖形解釋

在一個Paxos系統中，首先將所有節點劃分為Proposers，Acceptors，和Learners。(每個節點都可以身兼數職)

一個完整的Paxos算法流程分為三個階段：

1. Preposer階段

1.Proposer向Acceptors發出Prepare請求Promise(承諾)

2.Acceptors針對收到的Prepare請求進行Promise承諾

2. Accept階段

Proposer收到多數Acceptors承諾的Promise后，向Accepter發出Propose請求

2.Acceptors針對收到的Propose請求進行Accept處理

2.Learn階段

Proposer將形成的決議發送給所有Learners

5.2 Paxos算法流程中的每條消息描述如下

Prepare: Proposer生成全局唯一且遞增的Proposal ID (可使用時間戳加Server ID)，向所有Acceptors發送Prepare請求，這里無需攜帶提案內容，只攜帶Proposal ID即可。

Promise: Acceptors收到Prepare請求后，做出“兩個承諾，一個應答”。

兩個承諾：

a. 不再接受Proposal ID小于等于（注意：這里是<= ）當前請求的Prepare請求。

b. 不再接受Proposal ID小于（注意：這里是< ）當前請求的Propose請求。

一個應答：

c. 不違背以前做出的承諾下，回復已經Accept過的提案中Proposal ID最大的那個提案的Value和Proposal ID，沒有則返回空值。

Propose: Proposer 收到多數Acceptors的Promise應答后，從應答中選擇Proposal ID最大的提案的Value，作為本次要發起的提案。如果所有應答的提案Value均為空值，則可以自己隨意決定提案Value。然后攜帶當前Proposal ID，向所有Acceptors發送Propose請求。

Accept: Acceptor收到Propose請求后，在不違背自己之前做出的承諾下，接受并持久化當前Proposal ID和提案Value。

Learn: Proposer收到多數Acceptors的Accept后，決議形成，將形成的決議發送給所有Learners。

下面針對上述描述做三種情況的推演舉例：為了簡化流程，我們這里不設置Learner。

情況1：

情況2：

Paxos算法缺陷：在網絡復雜的情況下，一個應用Paxos算法的分布式系統，可能很久無法收斂，甚至陷入活鎖的情況。

情況3：

造成這種情況的原因是系統中有一個以上的Proposer，多個Proposers相互爭奪Acceptors，造成遲遲無法達成一致的情況。針對這種情況，一種改進的Paxos算法被提出：從系統中選出一個節點作為Leader，只有Leader能夠發起提案。這樣，一次Paxos流程中只有一個Proposer，不會出現活鎖的情況，此時只會出現例子中第一種情況。

6. 寫數據流程

本篇博客就到這里了,下一篇博客博主將為大家帶來Zookeeper分布式安裝部署,敬請期待!!!

看 完 就 贊 ， 養 成 習 慣 ！ ！ ！ \color{#FF0000}{看完就贊，養成習慣！！！} 看完就贊，養成習慣！！！^ _ ^ ?? ?? ??

碼字不易，大家的支持就是我堅持下去的動力。后不要忘了關注我哦！

ZooKeeper 分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。