歡迎光臨
每天分享高質量文章

分佈式協調神器 ZooKeeper 之整體概述

文章來自:恆生技術之眼頻道。
ZooKeeper 最早起源於雅虎研究院的一個研究小組。當時,雅虎內部很多大型系統基本都需要依賴一個類似的系統來進行分佈式協調,但是這些系統往往都存在分佈式單點問題。所以,雅虎的開發人員就試圖開發一個通用的無單點問題的分佈式協調框架,以便讓開發人員將精力集中在處理業務邏輯上。
立項初期,考慮到之前內部很多專案都是使用動物的名字來命名的(例如著名的 Pig 專案),雅虎的工程師希望給這個專案也取一個動物的名字。當時研究院的首席科學家 RaghuRamakrishnan 開玩笑說:“再這樣下去,我們這兒就變成動物園了!”是不是很有趣,順勢大家就表示既然已經是動物園了,它就叫動物園管理員吧!各個以動物命名的分佈式組件放在一起,雅虎的整個分佈式系統看上去就像一個大型的動物園了,而 ZooKeeper 正好要用來進行分佈式環境的協調一一於是,ZooKeeper 的名字也就由此誕生了!


ZooKeeper概述

ZooKeeper 是一種用於分佈式應用程式的分佈式開源協調服務。它公開了一組簡單的原語,分佈式應用程式可以構建這些原語,以實現更高級別的服務,以實現同步,配置維護以及組和命名。它被設計為易於編程,並使用在熟悉的檔案系統目錄樹結構之後設計的資料模型。它在Java中運行,並且具有Java和C的系結。
眾所周知,協調服務很難做到。他們特別容易出現諸如競爭條件和死鎖等錯誤。ZooKeeper 背後的動機是減輕分佈式應用程式從頭開始實施協調服務的責任。


集群模型

Leader 服務器是整個 ZooKeeper 集群工作機制中的核心,其主要工作有以下兩個:
  1. 事務請求的唯一調度和處理者,保證集群事務處理的順序性。

  2. 集群內部各服務器的調度者。

從角色名字上可以看出,Follewer 服務器是 ZooKeeper 集群狀態的跟隨者,其主要工作有以下三個:
  1. 處理客戶端非事務請求,轉發事務請求給 Leader 服務器。

  2. 參與事務請求 Proposal 的投票。

  3. 參與 Leader 選舉投票。

Observer 充當了一個觀察者的角色,在工作原理上基本和 Follower 一致,唯一的區別在於,它不參與任何形式的投票。
資料結構


樹形結構

首先我們來看上述資料節點示意圖,從而對 ZooKeeper 上的資料節點有一個大體上的認識,在 ZooKeeper 中,每一個節點都被稱為一個 ZNode,所有 ZNode 按層次化機構進行組織,形成一棵樹。ZNode 節點路徑標識方式和 Unix 檔案系統路徑非常相似,都是由一系列使用斜杠(/)進行分割的路徑表示,開發人員可以向這個節點中寫入資料,也可以在節點下麵創建子節點。
節點操作流程

  1. 在 Client 向 Follower 發出一個寫請求。

  2. Follower 把請求轉發給 Leader。

  3. Leader 接收到以後開始發起投票並通知 Follower 進行投票。

  4. Follower 把投票結果發送給 Leader。

  5. Leader 將結果彙總後,如果需要寫入,則開始寫入,同時把寫入操作通知給 Follower,然後 commit。

  6. Follower 把請求結果傳回給 Client。

設計標的

  1. 順序一致性,來自任意特定客戶端的更新都會按其發送順序被提交。也就是說,如果一個客戶端將 Znode z 的值更新為 a,在之後的操作中,它又將 z 的值更新為 b,則沒有客戶端能夠在看到z的值是b之後再看到值 a(如果沒有其他對z的更新)。

  2. 原子性,每個更新要麼成功,要麼失敗。這意味著如果一個更新失敗,則不會有客戶端會看到這個更新的結果。

  3. 單一系統映像,一個客戶端無論連接到哪一臺服務器,它看到的都是同樣的系統視圖。這意味著,如果一個客戶端在同一個會話中連接到一臺新的服務器,它所看到的系統狀態不會比 在之前服務器上所看到的更老。當一臺服務器出現故障,導致它的一個客戶端需要嘗試連接集合體中其他的服務器時,所有滯後於故障服務器的服務器都不會接受該 連接請求,除非這些服務器趕上故障服務器。

  4. 持久性,一個更新一旦成功,其結果就會持久存在並且不會被撤銷。這表明更新不會受到服務器故障的影響。

整體架構

  • ServerCnxnFactory,ZooKeeper服務端網絡連接工廠。在早期版本中,ZooKeeper 都是自己實現 NIO 框架,從 3.4.0 版本開始,引入了 Netty。可以通過 zookeeper.serverCnxnFactory 來指定使用具體的實現。

  • SessionTracker,ZooKeeper 服務端會話管理器。創建時,會初始化 expirationInterval、nextExpirationTime、sessionsWithTimeout(用於儲存每個會話的超時時間),同時還會計算出一個初始化的sessionID。

  • RequestProcessor,ZooKeeper的請求處理方式是典型的責任鏈樣式,在服務端,會有多個請求處理器依次來處理一個客戶的請求。在服務器啟動的時候,會將這些請求處理器串聯起來形成一個請求處理鏈。基本的請求處理鏈如下:

  • LearnerCnxAcceptor,Learner服務器(等於 Follower 服務器)連接請求接收器。負責 Leader 服務器和 Follower 服務器保持連接,以確定集群機器存活情況,並處理連接請求。

  • LearnerHandler,Leader 接收來自其他機器的連接創建請求後,會創建一個 LearnerHandler 實體。每個 LearnerHandler 實體都對應了一個 Leader 和 Learner 服務器之間的連接,其負責 Leader 和 Learner 服務器之間幾乎所有的訊息通信和資料同步。

  • ZKDatabase,ZooKeeper 記憶體資料庫,負責管理 ZooKeeper 的所有會話記錄以及 DataTree 和事務日誌的儲存。

  • FileTxnSnapLog,ZooKeeper 上層服務和底層資料儲存之間的對接層,提供了一系列的運算元據檔案的接口,包括事務檔案和快照資料檔案。ZooKeeper 根據 zoo.cfg 檔案中解析出的快照資料目錄 dataDir 和事務日誌目錄 dataLogDir 來創建 FileTxnSnapLog。

  • LeaderElection,ZooKeeper 會根據 zoo.cfg 中的配置,創建相應的 Leader 選舉演算法實現。在 ZooKeeper 中,預設提供了三種 Leader 選舉演算法的實現,分別是 LeaderElection、AuthFastLeaderElection、FastLeaderElection,可以通過配置檔案中 electionAlg 屬性來指定,分別用 0 ~ 3 來表示。從 3.4.0 版本開始,ZooKeeper 廢棄了前兩種演算法,只支持 FastLeaderEletion 選舉演算法。

原文鏈接:http://rdc.hundsun.com/portal/article/952.html

Service Mesh入門與進階實戰培訓

Service Mesh實戰培訓將於2019年3月22日在北京開課,3天時間帶你系統掌握Service Mesh,學習效果不好可以繼續學習。本次培訓包括:Istio介紹、核心功能、使用場景、安裝與配置、升降級,Envoy介紹、架構、內部實現,Istio控制面板,Mixer核心功能與規則、監控、工作原理,Pilot介紹與配置,Istio安全,主要資源配置,策略配置,遙測,落地實踐,傳統微服務架構改造,Istio運維等,點擊下麵圖片查看具體詳情。