文章目錄

• 集群
• • 集群角色
  • 選舉
  • • 服務器啟動時期的選舉
    • 服務器運行時期的選舉
  • 集群的機器數量

---

集群

集群角色

通常在分布式系統中，構成一個集群的每一臺機器都有自己的角色，最常見的集群模式就是Master/Slave模式（主從模式），在這種模式中，通常Maste服務器作為主服務器提供寫服務，其他的Slave服務器從服務器通過異步復制的方式獲取Master服務器最新的數據提供讀服務。

但是ZooKeeper并沒有沿用傳統的主從模式，而是引入了Leader、Follower和Observer三種角色，如下圖所示：

ZooKeeper集群中的三種角色

ZooKeeper集群中的所有機器通過一個Leader 選舉過程來選定一臺稱為Leader的機器，Leader既可以為客戶端提供寫服務又能提供讀服務。除了Leader外，Follower和Observer都只能提供讀服務。Follower和Observer唯一的區別在于Observer機器不參與Leader的選舉過程，也不參與寫操作的“過半寫成功”策略，因此Observer機器可以在不影響寫性能的情況下提升集群的讀性能。

集群中的角色

• Leader：為客戶端提供讀和寫的服務，負責投票的發起和決議，更新系統狀態。
• Follower：為客戶端提供讀服務，如果是寫服務則轉發給Leader。在選舉過程中參與投票。
• Observer：與Follower工作原理基本一致，唯一的區別是Observer不參與任何形式的投票。Observer主要用來在不影響寫性能的情況下提升集群的讀性能，是ZooKeeper3.3中新增的角色。

ZooKeeper用以下四種狀態來表示各個節點

• LOOKING：競選狀態。
• LEADING：Leader狀態。
• FOLLOWING：Follower狀態。
• OBSERVING：Observer狀態。

選舉

Leader選舉是ZooKeeper中最重要的技術之一，也是保證分布式數據一致性的關鍵所在。

當ZooKeeper集群中的一臺服務器出現以下兩種情況之一時，就會開始進入Leader選舉

• 服務器初始化啟動
• 服務器運行期間無法和Leader保持連接

在介紹選舉之前，首先介紹三個重要參數

• 服務器ID（myid）：編號越大在選舉算法中權重越大。
• 事務ID（zxid）：值越大說明數據越新，權重越大。
• 邏輯時鐘（epoch-logicalclock）：同一輪投票過程中的邏輯時鐘值是相同的，每投完一次值會增加。

服務器啟動時期的選舉

ZooKeeper集群初始化時，當滿足以下兩個條件時，就會開始進入Leader選舉流程：

• 集群規模至少為2臺機器
• 集群內的機器能夠互相通信

選舉流程圖

如上圖，選舉流程如下：

每個服務器會發出一個投票：由于是初始化狀態，每一個節點都會將自己作為Leader來進行投票，每次投票的內容包含：推舉服務器的myid（在集群中的機器序號）和ZXID（事務ID），以(myid, ZXID)的形式表示。初始化階段每個節點都會將票投給自己，然后將這個投票發給集群總其他所有機器。

接受來自各個服務器的投票：每個服務器都會接收來自其他服務器的投票，在接收投票后首先會判斷該投票的有效性，如是否為本輪投票（邏輯時鐘）、是否來自LOOING狀態的服務器。

處理投票：在接收到來自其他服務器的投票后，針對每一個投票，服務器都需要將別人的投票和自己的投票進行PK，PK規則如下

• 優先檢查ZXID，ZXID較大的優先作為Leader。
• 如果Leader相同則比較myid，myid較大的作為Leader。
  

統計投票：每次投票后，服務器都會統計所有投票，判斷是否已經有過半的機器接收到相同的投票信息。當票數達到半數以上時，此時就認為已經選出了Leader。

改變服務器狀態：一旦確認了Leader，則每個服務器開始改變自己的狀態。如果是Follower則更改成FOLLOWING；如果是Observer則更改成OBSERVING；如果是Leader則更改成LEADING；

服務器運行時期的選舉

在ZooKeeper集群正常運行中，一旦選出一個Leader，那么所有服務器的集群角色一般不會再發生變化——也就是說Leader服務器將一直作為集群的Leader，即使集群中有非Leader機器掛了或者是有機器加入集群也不會影響Leader。但是一旦Leader所在的機器掛掉，那么此時整個集群將暫時無法對外服務，馬上進入新一輪的Leader選舉。

服務器運行期間的Leader選舉和啟動時期的Leader選舉基本是一致的，只增加了一個變更狀態的步驟，流程如下：

變更狀態：當Leader掛了之后，剩下的所有非Observer服務器都會將自己的服務器狀態變更為LOOKING，然后開始進入Leader選舉流程。

每個服務器會發出一個投票

接受來自各個服務器的投票

處理投票

統計投票

改變服務器狀態

集群的機器數量

為什么ZooKeeper提倡集群的機器數量最好要做奇數臺呢？

ZooKeeper 集群在宕掉幾個 ZooKeeper 服務器之后，如果剩下的 ZooKeeper 服務器個數大于宕掉的個數的話整個 ZooKeeper 才依然可用。假如我們的集群中有 n 臺 ZooKeeper 服務器，那么也就是剩下的服務數必須大于 n/2。先說一下結論，2n 和 2n-1 的容忍度是一樣的，都是 n-1，大家可以先自己仔細想一想，這應該是一個很簡單的數學問題了。 比如假如我們有 3 臺，那么最大允許宕掉 1 臺 ZooKeeper 服務器，如果我們有 4 臺的的時候也同樣只允許宕掉 1 臺。 假如我們有 5 臺，那么最大允許宕掉 2 臺 ZooKeeper 服務器，如果我們有 6 臺的的時候也同樣只允許宕掉 2 臺。

綜上，何必增加那一個不必要的 ZooKeeper 呢？

總結

以上是生活随笔為你收集整理的ZooKeeper 集群：集群概念、选举流程、机器数量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。