目錄

01ZooKeeper的ZAB協(xié)議

ZAB協(xié)議概念

ZAB協(xié)議基本模式

消息廣播

崩潰恢復(fù)

選舉出新的Leader服務(wù)器

數(shù)據(jù)同步

02Zookeeper的核心

ZooKeeper 的核心特點

ZooKeeper 的核心組件

選舉算法概述

服務(wù)器啟動時的Leader選舉

服務(wù)器運行期間的Leader選舉

03ZooKeeper的簡單使用

04ZooKeeper的應(yīng)用場景

01ZooKeeper的ZAB協(xié)議

在解決一致性方面，Zookeeper并沒有直接采用Paxos算法，而是采用了一種被稱為ZAB(ZooKeeper Atomic Broadcast)的一致性協(xié)議。

ZAB協(xié)議概念

ZAB協(xié)議是為分布式協(xié)調(diào)服務(wù)Zookeeper專門設(shè)計的一種支持崩潰恢復(fù)的原子廣播協(xié)議?；谠搮f(xié)議，Zookeeper實現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來維持集群中各副本之間數(shù)據(jù)的一致性。

ZAB協(xié)議的核心是定義了事務(wù)請求的處理方式：

所有事務(wù)請求必須由一個全局唯一的服務(wù)器來協(xié)調(diào)處理，這樣的服務(wù)器被稱為Leader服務(wù)器，而余下的其他服務(wù)器則成為Follower服務(wù)器。Leader服務(wù)器負責將一個客戶端事務(wù)請求轉(zhuǎn)換為一個事務(wù)Proposal（提議），并將該Proposal分發(fā)給集群中的所有Follower服務(wù)器。之后Leader服務(wù)器需要等待所有Follower服務(wù)器的反饋，一旦超過半數(shù)的Follower服務(wù)器進行了正確的反饋后，那么Leader就會再次向所有的Follower服務(wù)器發(fā)布Commit信息，要求將前一個Proposal進行提交。

ZAB協(xié)議基本模式

ZAB 協(xié)議包括兩種基本模式：消息廣播和崩潰恢復(fù)。

1. 消息廣播：這是 ZAB 協(xié)議的基本模式之一，用于確保 ZooKeeper 集群中的所有節(jié)點都接收到相同的消息。在這種模式下，ZooKeeper 集群中的 leader 節(jié)點負責將客戶端請求轉(zhuǎn)化為一系列的消息，然后將這些消息廣播給所有的 follower 節(jié)點。每個 follower 節(jié)點接收到消息后，會將消息寫入本地的事務(wù)日志。一旦超過半數(shù)的節(jié)點確認接收了消息，leader 就可以提交這些消息，并將其應(yīng)用到自己的狀態(tài)機上，從而達到狀態(tài)一致性。這確保了 ZooKeeper 的一致性和可靠性。

2. 崩潰恢復(fù)：是 ZAB 協(xié)議的另一種基本模式，用于選擇 ZooKeeper 集群中的 leader 節(jié)點。在一個 ZooKeeper 集群中，只有一個節(jié)點充當 leader，負責處理客戶端請求并維護共享狀態(tài)。如果當前的 leader 節(jié)點出現(xiàn)故障，集群需要選舉一個新的 leader。ZAB 協(xié)議中的選舉是基于消息廣播的，節(jié)點會爭相發(fā)送選舉消息，然后根據(jù)規(guī)則選擇新的 leader。選舉過程確保了只有一個節(jié)點成為 leader，從而維持了一致性。

消息廣播

ZAB的消息廣播類似于二階段提交。不同之處是ZAB協(xié)議移除了中斷邏輯——Follower服務(wù)器要么Ack給Leader，要么拋棄Leader。當過半的Follower服務(wù)器反饋Ack之后就開始提交事務(wù)Proposal,而不需要等待集群中所有的Follower服務(wù)器都反饋響應(yīng)。

• 消息廣播是基于具有FIFO特性的TCP協(xié)議通信的，所以能很容易地保證消息廣播過程中消息接收與發(fā)送的順序性。

• 整個消息廣播過程中，leader服務(wù)器會為每一個事務(wù)請求生成一個Proposal來進行廣播，并且在廣播事務(wù)Proposal之前，Leader服務(wù)器會為這個事務(wù)分配一個全局單調(diào)遞增的唯一ID,稱之為事務(wù)ID(即ZXID)。而且每一個事務(wù)Proposal嚴格按照其ZXID的先后順序進行排序和處理。

• 消息廣播過程中，Leader服務(wù)器會為每一個Follower服務(wù)器各自分配一個單獨的隊列，將需要廣播的事務(wù)Proposal一次放入隊列中，根據(jù)FIFO的策略發(fā)送。每一個Follower服務(wù)器在接收到這個事務(wù)Proposal之后，都會首先將其以事務(wù)日志的形式寫入本地磁盤，在成功寫入后反饋給Leader服務(wù)器一個Ack響應(yīng)。服務(wù)器收到過半的Follower的Ack響應(yīng)后，就會廣播一個Commit消息給所有的服務(wù)器以通知其進行事務(wù)提交，同時Leader完成自身的事務(wù)提交，每一個Follower服務(wù)器收到Commit消息后，完成自身事務(wù)的提交。

需要注意的是：Leader服務(wù)器可以處理事務(wù)請求(包括創(chuàng)建、更新和刪除節(jié)點等需要保證強一致性的操作)和非事務(wù)請求，F(xiàn)ollower服務(wù)器只能處理非事務(wù)請求，如果Follower收到事務(wù)請求會轉(zhuǎn)交給Leader服務(wù)器。

崩潰恢復(fù)

簡化的二階段提交模型是無法處理Leader崩潰帶來的數(shù)據(jù)不一致問題。一旦Leader服務(wù)器出現(xiàn)崩潰，或者由于網(wǎng)絡(luò)導(dǎo)致Leader服務(wù)器失去了過半Follower的聯(lián)系，就會進入崩潰恢復(fù)模式。

崩潰恢復(fù)狀態(tài)下，ZAB協(xié)議有兩件事要做：

• 選舉出新的Leader服務(wù)器

• 數(shù)據(jù)同步

選舉出新的Leader服務(wù)器

整個崩潰過程結(jié)束后，需要選舉出新的Leader服務(wù)器，而且還得讓其他服務(wù)器感知到選舉產(chǎn)生的新Leader服務(wù)器。

在ZAB協(xié)議中，崩潰恢復(fù)模式可能出現(xiàn)的兩個數(shù)據(jù)不一致的隱患場景：

1. 服務(wù)器Leader在確認半數(shù)通過后完成了進行自身事務(wù)的提交，但是發(fā)送Commit告知Follower進行事務(wù)提交的瞬間異常，這是第一個需要保證的特性：確保在Leader服務(wù)器提交過的事務(wù)最終被所有服務(wù)器都提交。

2. ZAB協(xié)議規(guī)定：如果一個Proposal事務(wù)在一臺機器上被處理成功，那么應(yīng)該在所有的機器上都被處理成功，哪怕機器出現(xiàn)故障崩潰。(所以在過半確認過程中數(shù)據(jù)會被強制一致的)基于這個特性，如果Leader節(jié)點在提出了某個Proposal事務(wù)之后就崩了，沒有告知到Follower進行本地提交，等崩潰恢復(fù)了，原本的Leader保留了提出這個Proposal的狀態(tài)，此時應(yīng)該直接丟棄而不是強制同步。這是第二個需要保證的特性：確保丟棄那些只在Leader服務(wù)器上被提出的事務(wù)。

結(jié)合這兩種情況，ZAB協(xié)議設(shè)計的選舉算法就必須要滿足：能夠確保提交已經(jīng)被Leader提交的事務(wù)Proposal，同時丟棄已經(jīng)被跳過的事務(wù)Proposal。

ZAB協(xié)議的Leader選舉方案就是：擁有最大ZXID的Follower服務(wù)器作為新的Leader服務(wù)器。為什么呢？

1. 在消息廣播的過程中，Leader服務(wù)器進行自身事務(wù)的提交前提是收到了半數(shù)的Follower服務(wù)器的Ack響應(yīng)，那么此時必然有Follower服務(wù)器的事務(wù)日志中保存了所有的proposal狀態(tài)，包含Leader異常時提交的那份。

2. Follower自身ZXID是64位，高32位是epoch編號，低32位是消息計數(shù)器，每接收到1條消息+1，新Leader選舉后epoch會+1，消息計數(shù)器置為0。設(shè)計的好處在于，舊的Leader作為Follower接入時，它的ZXID是肯定小于新Leader的，而且新Leader會讓它將所有的擁有舊的epoch號的未被Commit的proposal清除。

至此，就保證了崩潰恢復(fù)后數(shù)據(jù)的一致性。

數(shù)據(jù)同步

在選出新的Leader服務(wù)器后，需要開始數(shù)據(jù)同步。Leader服務(wù)器會為每一個Follower服務(wù)器準備一個隊列，將那些沒有被同步的事務(wù)以Proposal消息的形式逐個發(fā)給Follower服務(wù)器，在Follower服務(wù)器將所有未同步的proposal事務(wù)從Leader服務(wù)器上同步并成功應(yīng)用到本地數(shù)據(jù)庫中后，Leader服務(wù)器會將該Follower服務(wù)器加入真正可用的Follower列表中，然后開始之后的正常流程。

02Zookeeper的核心

ZooKeeper是一個開源的分布式協(xié)調(diào)服務(wù)，用于構(gòu)建分布式應(yīng)用和分布式系統(tǒng)。它提供了一個高度可靠的分布式協(xié)調(diào)基礎(chǔ)設(shè)施，幫助應(yīng)用程序在分布式環(huán)境中協(xié)同工作。ZooKeeper 通常用于解決分布式系統(tǒng)中的一致性、配置管理、鎖服務(wù)、命名服務(wù)等問題。

ZooKeeper 的核心特點

1. 分布式文件系統(tǒng)：ZooKeeper 維護一個分層的命名空間，類似于文件系統(tǒng)目錄結(jié)構(gòu)，它可以用于存儲配置信息和分布式數(shù)據(jù)。

2. 一致性：ZooKeeper 提供了強一致性的數(shù)據(jù)模型，即一旦數(shù)據(jù)被寫入，所有客戶端都能讀取到最新的數(shù)據(jù)，從而確保數(shù)據(jù)的一致性。

3. 高可用性：ZooKeeper 以多數(shù)節(jié)點的方式運行，即在集群中的節(jié)點數(shù)必須超過半數(shù)，以確保高可用性。如果一些節(jié)點失效，ZooKeeper 仍然能夠提供服務(wù)。

4. 快速通知：ZooKeeper 允許客戶端監(jiān)聽節(jié)點數(shù)據(jù)的變化，一旦節(jié)點數(shù)據(jù)發(fā)生變化，相關(guān)的客戶端將得到通知。

5. 順序一致性：ZooKeeper 允許客戶端按照順序創(chuàng)建節(jié)點，并提供了有序性保證，這在分布式鎖服務(wù)中非常有用。

ZooKeeper 的核心組件

1. 集群：ZooKeeper 集群由多個節(jié)點組成，這些節(jié)點分布在不同的機器上，它們協(xié)同工作以提供服務(wù)。典型的 ZooKeeper 集群包括奇數(shù)個節(jié)點，通常是 3、5 或 7 個節(jié)點，以確保多數(shù)節(jié)點可用。

2. ZNode：ZNode 是 ZooKeeper 命名空間的基本單元，類似于文件系統(tǒng)中的目錄或文件。每個 ZNode 可以包含數(shù)據(jù)，并具有一個路徑名稱。

3. 會話：ZooKeeper 客戶端與 ZooKeeper 服務(wù)器之間建立會話，會話是客戶端與服務(wù)器之間的狀態(tài)會話，用于保持連接和跟蹤會話的生命周期。

4. Watch：客戶端可以在 ZNode 上設(shè)置 Watch，以便在 ZNode 數(shù)據(jù)發(fā)生變化時獲得通知。

5. 選舉算法：ZooKeeper 使用選舉算法來選舉 leader 節(jié)點，leader 負責協(xié)調(diào)事務(wù)和保持一致性。

選舉算法概述

分兩種情況拆解下選舉算法：服務(wù)器啟動時的Leader選舉和服務(wù)器運行期間的Leader選舉。

服務(wù)器啟動時的Leader選舉

假設(shè)在集群中，有3臺服務(wù)器已經(jīng)可以互相通信，它們需要選出一個Leader服務(wù)器。有一個前提條件，它們擁有一個myid的屬性，server1的myid是1，server2的myid是2，server3的myid是3。

1.每個server會發(fā)出一個投票

例如server1以(myid，zxid)格式發(fā)送給其他服務(wù)器投票的數(shù)據(jù)(1,0)，server2發(fā)送的(2,0)。

2.接收來自每個服務(wù)器的投票

每個服務(wù)器都會收到其他服務(wù)器的投票，首先驗證有效性，其次是否本輪投票、是否來自Looking狀態(tài)的服務(wù)器。

3.處理投票

每個服務(wù)器根據(jù)規(guī)則處理收到的投票，規(guī)則如下：

• 優(yōu)先zxid。zxid大的優(yōu)先作為Leader。

• zxid相同，myid大的作為Leader。

那么，3臺服務(wù)器的zxid都為0，就會比較myid。server1和server2根據(jù)規(guī)則會修改自身投票為(3,0)。然后重新向其他服務(wù)器發(fā)送投票。server3不用修改，只是再發(fā)送一次。

4.統(tǒng)計投票

每次投票，服務(wù)器都會統(tǒng)計所有投票判斷是否產(chǎn)生了Leader，這里還是使用的過半概念：當有一半的服務(wù)器收到相同的投票時候，就認為已經(jīng)選出了Leader。

5.改變服務(wù)器狀態(tài)

一旦確定了Leader，服務(wù)器就會變更自己的狀態(tài)：Follower會變更為FOLLOWING，Leader會變更為LEADING。

服務(wù)器運行期間的Leader選舉

當Leader服務(wù)器掛掉的時候，就會進行新一輪的Leader選舉。

1.變更狀態(tài)

非Observer服務(wù)器會將自己的服務(wù)器狀態(tài)變更為LOOKING，開始選舉流程。(Observer服務(wù)器不參與選舉也不投票)

2.每個server發(fā)出一個投票

與啟動期間不同的是，運行期間的服務(wù)器可能有不同的zxid。例如server的投票(1,1112)，server3的投票(3,1113)。

3.接收各個服務(wù)器的投票

4.處理投票，顯然server3的zxid大，server3會成為Leader。

5.統(tǒng)計投票

6.改變服務(wù)器狀態(tài)

03ZooKeeper的簡單使用

可以參考這篇博客：

04ZooKeeper的應(yīng)用場景

Apache ZooKeeper 在分布式系統(tǒng)中有多種典型應(yīng)用場景，它提供了高度可靠的分布式協(xié)調(diào)服務(wù)，用于解決各種分布式系統(tǒng)的共識、配置管理和協(xié)同協(xié)作問題。以下是 ZooKeeper 的一些典型應(yīng)用場景：

1. 分布式配置管理：ZooKeeper 可用于存儲和管理應(yīng)用程序的配置信息。各個分布式節(jié)點可以監(jiān)聽配置節(jié)點，當配置發(fā)生變化時，節(jié)點能夠及時獲取最新的配置，實現(xiàn)動態(tài)配置管理。

2. 分布式鎖服務(wù)：ZooKeeper 提供了分布式鎖服務(wù)，允許多個節(jié)點協(xié)同競爭獲取鎖。這對于協(xié)調(diào)分布式系統(tǒng)中的操作非常有用，確保只有一個節(jié)點能夠執(zhí)行關(guān)鍵操作。

3. 分布式一致性：ZooKeeper 可以用于協(xié)調(diào)多個節(jié)點以達成一致的決策。它確保在分布式系統(tǒng)中節(jié)點的狀態(tài)和數(shù)據(jù)是一致的，從而提供強一致性的數(shù)據(jù)存儲。

4. 服務(wù)發(fā)現(xiàn)：ZooKeeper 可用于注冊和發(fā)現(xiàn)分布式系統(tǒng)中的服務(wù)。各個服務(wù)可以在 ZooKeeper 上注冊自己的地址和狀態(tài)，其他節(jié)點可以查詢這些信息以發(fā)現(xiàn)可用的服務(wù)。

5. 領(lǐng)導(dǎo)者選舉：ZooKeeper 通常用于選舉分布式系統(tǒng)中的領(lǐng)導(dǎo)者節(jié)點。它確保只有一個節(jié)點成為領(lǐng)導(dǎo)者，從而協(xié)調(diào)系統(tǒng)的操作。

6. 分布式任務(wù)隊列：ZooKeeper 可用于創(chuàng)建分布式任務(wù)隊列，多個節(jié)點可以將任務(wù)推送到隊列中，然后從隊列中獲取任務(wù)進行處理。

7. 分布式協(xié)同協(xié)作：ZooKeeper 提供了分布式協(xié)調(diào)服務(wù)，可以用于構(gòu)建分布式應(yīng)用程序，確保多個節(jié)點協(xié)同協(xié)作并實現(xiàn)一致性。

8. 分布式文件系統(tǒng)：雖然 ZooKeeper 不是一個文件系統(tǒng)，但它可以用于管理分布式系統(tǒng)中的文件和配置信息，作為分布式文件系統(tǒng)的一部分。

參考資料：從Paxos到Zookeeper ?分布式一致性原理與實踐 [倪超著]文章來源地址http://www.zghlxwxcb.cn/news/detail-718890.html

到了這里，關(guān)于聊聊分布式架構(gòu)10——Zookeeper入門詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！