歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

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

2019-03-09 分類：後端 閱讀(355) 評論(0)

文章來自：恆生技術之眼頻道。
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運維等，點選下麵圖片檢視具體詳情。