【轉】【Apache ZooKeeper】官方文檔

原文連接 http://blog.csdn.net/kobejayandy/article/details/11836051

 

ZooKeeper是一個高性能的用於協調分佈式應用程序的服務。它將公共服務，好比命名、配置管理、同步化和集羣服務封裝進一個簡單的接口，

能夠直接用於實現共識（consensus）、集羣管理、領導者選舉和存在（presence ）協議。

能夠在其上構建本身的分佈式應用程序。

 

ZooKeeper使用一種相似文件系統目錄樹的數據模型，它能夠運行於Java上而且具備Java和C的封裝。

 

ZooKeeper的設計目標

簡單——ZooKeeper容許分佈式進程之間經過一個共享的層級命名空間來相互協做，這個命名空間以相似於文件系統的方式組織起來。

命名空間中的數據單元被稱爲znode，它至關於文件或者目錄。與典型文件系統不一樣的是，文件系統用於持久化存儲，

而ZooKeeper的數據是保持在內存中的，這意味着ZooKeeper能達到很高的吞吐量和低延遲。

 

ZooKeeper的實現十分注重高性能、高可用性，和嚴格的順序訪問。高性能使得ZooKeeper能用於大規模分佈式系統，

高可用性能避免單點故障，嚴格的順序化意味着複雜的同步操做能夠在客戶端實現。

集羣化——ZooKeeper自己也是有集羣化的。以下圖：

 

 

    客戶端與單個服務端相連，它維持一個TCP鏈接，在其上發送請求，得到響應，得到監控事件和發送心跳檢測。

若是到服務端的TCP鏈接斷了，客戶端會鏈接另外一個服務端。組成ZooKeeper服務的每一個服務端都知道其它服務端的存在，

它們維護一個服務端狀態的內存鏡像，連同事務日誌和快照保存在持久化存儲中，只要大部分服務端可用，ZooKeeper服務就可用。

 

順序化——ZooKeeper爲每一個更新操做都標記一個號碼以反映事務的順序。後來的操做使用這個順序來實現高度的抽象，好比同步原語。

快速——這個特性在以讀操做爲主的工做中尤其明顯。ZooKeeper應用程序運行於數以千計的機器中，當讀操做與寫操做的比例爲10:1時，ZooKeeper能得到最佳性能。

 

數據模型和層級命名空間

ZooKeeper提供的命名空間極像一個標準的文件系統，一個名字是一個以/分隔的路徑元素的序列，ZooKeeper命名空間的每一個節點經過路徑來標識。

 

節點和臨時節點

與標準文件系統不一樣，ZooKeeper命名空間中的全部節點均可以有數據和子節點，這就像文件系統中容許一個文件同時是一個目錄。

（ZooKeeper被設計用來存儲管理服務的數據：狀態信息、配置、位置信息等，因此每一個節點存儲的數據一般很小，幾字節到幾K字節不等。）

咱們使用znode這個術語來表示ZooKeeper的數據節點。

znode維持一個stat結構，它包含數據變化的版本號、ACL變化和時間戳，以容許cache校驗和協調化的更新。

每當znode的數據變化時，版本號將增長。一個客戶端收到數據時，它也會收到數據的版本號。

 

保存在每一個znode中的數據都是自動讀寫的。讀操做獲取znode的全部數據，寫操做替換掉znode的全部數據。

每一個節點有一個訪問控制表（ACL）來限制誰能作哪些操做。

ZooKeeper也有臨時節點的概念，這些znode只存在於建立znode的會話中。當會話結束，這些節點也就被刪除了。

 

 

條件化更新和監控

ZooKeeper支持監控的概念。客戶端能夠在zonode上設置一個觀察員。這個觀察員會在znode發生變化時觸發和移除

。當觀察員被觸發時，客戶端會接收到一個說明znode發生變化的包

。若是客戶端和服務端的鏈接斷了，客戶端會收到一個本地的通知。這些能夠用於[tbd]

 

保證

ZooKeeper很是快，也很是簡單。由於它的目標是成爲構建複雜服務的基礎，因此它提供一系列保證：

 

• 順序一致性——來自客戶端的更新操做將以它們發送的順序來執行。
• 原子性——更新操做只有成功和失敗兩種結果，沒有局部化結果。
• 單個系統鏡像——無論客戶端鏈接的服務器是哪一個，全部客戶端看到的服務都是一個樣子。
• 可靠性——一旦更新操做被執行，它將被持久化保存直到被下次更新所覆蓋。
• 及時性——客戶端所看到的系統在一個時間範圍內是最新的。

 

簡單的API

ZooKeeper的一個設計目標是易於編程。因此，它只支持以下操做：

create

    在命名空間的某個位置建立一個節點

delete

    刪除一個節點

exists

    測試某位置的節點是否存在

get data

    從一個節點讀取數據

set data

    往一個節點寫數據

get children

    獲取一個節點的子節點列表

sync

等待數據被傳播以同步數據

 

 

實現

下圖從較高層次說明了ZooKeeper的構成。除了請求處理單元，組成ZooKeeper服務的每一個服務端都會備份它的每一個組件。

 

集羣數據庫是存在於內存中的數據庫，保存命名空間的全部數據。

更新操做會被記錄到硬盤中以便恢復，寫操做先被序列化到硬盤中，再應用到內存數據庫中。

每一個ZooKeeper服務端爲一個或多個客戶端服務。客戶端鏈接一個服務端來提交請求。

 

讀操做請求由每一個服務端數據庫的本地副本提供服務。

 

可以改變服務狀態的請求、寫操做請求，按協議處理。

做爲協議的一部分，來自客戶端的全部寫操做請求會導向一個服務端，叫作leader。其餘服務端叫作follower。

全部follower從leader接收消息建議而且對消息轉發達成一致。由消息傳送層來處理失敗時替換leader，同步follower和leader的工做。

ZooKeeper使用自定義的原子性消息協議。因爲消息傳送層是原子性的，ZooKeeper可以保證本地副本不產生分歧。

當leader收到一個寫請求，它會計算出當寫操做完成後系統將會是什麼狀態，接着將之轉變爲一個事務。