zookeeper 官方文檔——綜述

 

Zookeeper: 一個分佈式應用的分佈式協調服務

 

zookeeper 是一個分佈式的，開源的協調服務框架，服務於分佈式應用程序。

 

它暴露了一系列基礎操做服務，所以，分佈式應用可以基於這些服務構建出更高級別的服務，好比，同步，配置管理，命名和分組服務。

 

zookeeper設計上易於編碼，數據模型構建在咱們熟悉的樹形結構目錄風格的文件系統中。

zookeeper運行在java中，同時支持java和C 語言。正確的實現協調服務是公認的難乾的差事。 他們及其容易出錯,好比資源競爭和死鎖.

 

zookeeper 的使命和力量來源於，將分佈式應用從處理協調服務的泥潭中走出來。

 

 

 zookeeper的設計目標

 

 

zookeeper是很是簡單的. zookeeper容許分佈式應用，經過一個共享的樹形命名空間進行互相協調,這一命名空間跟文件系統的組織方式相似.

zookeeper命名空間由數據寄存器組成,zookeeper中,咱們稱他爲,znodes, 這跟文件和目錄很是相似..

不像一個典型的文件系統,其設計時就是爲了存儲數據.而zookeeper 數據是保存在內存中的,這也就意味着zookeeper能實現一個高吞吐量和低延遲.(由於內存操做效率高)

 

zookeeper實現對高性能,高可用性,嚴格的順序訪問分外關注,. Zookeeper性能比較優異也就意味着它可使用在大的分佈式系統中.

 

可靠性方面讓咱們遠離了單點故障. 嚴格的順序訪問意味着複雜的同步原語能夠在客戶端實現.

 

zookeeper是有副本的, 就像分佈式的處理協調服務同樣,zookeeper 自己就打算在服務器集羣中使用副本機制,咱們稱之爲全體.

 

組成zookeeper 服務的全部機器節點互相之間都必須感知到對方. 他們維護着當前機器狀態的內存快照,有事務日誌和持久化存儲的快照.

 

只要大多數的機器是可用的那麼整個zookeeper服務就是可用的.

 

客戶端鏈接到其中一臺zookeeper服務器,客戶端和zookeeper服務器保持一個tcp鏈接,經過tcp鏈接發送請求得到響應,

獲取事件監聽,發送心跳等等. 若是TCP鏈接被中斷了,客戶端會鏈接到另一臺zookeeper服務器.

zookeeper是有序的, zookeeper給每一次更新操做都賦予一個編號,他這個編號反應了對zookeeper的事務性修改順序.

隨後的操做可以使用這一順序去實現更高級別的抽象,好比同步原語.

 

 

zookeeper是很是快的,尤爲是針對讀佔據主要地位的應用負載的應用. zookeeper應用運行在成千上萬的機器中,

 

當讀寫比例爲10:1 狀況下,zookeeper的性能是最優的.

 

 

數據模型和命名空間的體系結構

 

 

zookeeper提供的命名空間很是想咱們標準的文件系統. 命名就是一系列用/分割的路徑元素. 每個zookeeper節點的命名空間都是用路徑進行標識的.

 

 

節點和臨時節點

不像標準的文件系統,zookeeper 命名空間中的每一個節點可以有數據關聯,也有子節點.

就比如是文件系統中一個文件對象便可以是一個文件也能夠是一個文件夾.(zookeeper被設計用來存儲協調數據:

狀態信息,配置信息,位置信息等等, 所以數據存儲在每一個節點中一般很是小,從幾個字節到幾千字節之間),

咱們使用znode這個術語來使得咱們討論zookeeper數據節點相關內容時語義更加清晰明確.

znode管理着包含這一個狀態結構數據,它包含數據修改的版本號,ACL修改及時間戳, 容許緩存校驗和協調更新.

znode數據每修改一次,版本號加一. 舉個實際的例子,每次客戶端收到數據的同時,也收到當前數據的版本號.

 

每個節點都有一個ACL訪問控制列表,嚴格控制着誰能進行操做.

zookeeper 也有會話級別的節點的語義支持,這些znode節點隨着會話的建立而激活,會話的結束的時候節點被刪除.

 

會話級別的節點在實現例子的時候很是有用.（臨時節點）

 

條件更新和監聽

zookeeper支持監聽, 客戶端可以設置監聽znode節點. 當znode節點變動時可能觸發或者移除監聽.當監聽事件被觸發了,

客戶端將會收到數據通知包,告訴客戶端節點數據被修改了. 同時若是當前客戶端和zookeeper節點的鏈接被斷開了.

 

客戶端將收到一個本地通知. 這些特性都能用在 具體例子中。

 

zookeeper的保證

zookeeper 簡單而性能優異. 因爲他簡單快速的目標,他成爲構建許多更加複雜服務的基礎,好比同步服務,他提供了一系列的保證.

1 順序一致性: 來自客戶端的更新操做將會按照順序被做用.

2 原子性操做: 更新要麼所有成功,要麼所有失敗,沒有部分的結果.

3 統一的系統鏡像： 不管客戶端連接的是哪臺服務器,都能得到一樣的服務視圖,也就是說他是無狀態的.

4 可靠性保證： 一旦寫入操做被執行(做用到服務器),這個狀態將會被持久化,直到其餘客戶端的修改生效.

5 時間線特性：客戶端訪問服務器系統鏡像能在一個特定時間訪問內保證當前系統是實時更新的

簡單的操做API  

zookeeper的設計原則之一就是提供簡單的編程接口. 所以,他僅僅提供瞭如下幾個操做.

 

1 建立——在目錄結構樹的某個位置建立一個節點。

 

2 刪除 ——刪除某個節點。

 

3 判斷是否存在——判斷某個位置上是否存在指定節點。

 

4 獲取數據——從節點中獲取數據。

 

5 設置/寫入數據——寫入數據到某個節點中。

 

6 同步——等待寫入數據傳播到其餘節點。

 

想要進一步深刻的探討這些特性和操做,以及他們是如何實現更高級別的操做,請參看使用示例的相關內容。

 

 

zookeeper實現 細節

 

 

 

zookeeper組件構成圖中 展現了zookeeper服務中比較高級的組件服務。

 

除了請求處理器的異常狀況以外.  組成zookeeper服務的每一臺zookeeper服務器保存着每一個組件自身備份的副本。

 

副本數據庫是一個內存數據庫,保存着整個目錄結構樹的數據。

 

全部的更新操做都記錄在磁盤日誌當中,用於異常狀況的恢復. 在更新做用到內存數據中以前,全部的寫入操做都是串行的,這就保證了數據的強一致性。

 

每一個zookeeper服務器節點服務若干個客戶端. 客戶端鏈接到某一個指定的服務器節點(隨機分配算法分配的吧)和zookeeper進行交互。

 

讀請求都是由每一個zookeeper服務器內存數據庫的本地副本進行服務的(能夠提升讀的性能,這也就是爲何zookeeper在讀寫比例爲10:1的狀況下,性能最佳的緣由)，

 

涉及到修改服務器狀態和數據的寫入操做,須要經過一致性協議進行處理。

 

一致性協議中規定: 全部的寫入操做都是由選舉出來的惟一機器，即咱們稱之爲leader(主節點) 的節點進行操做。

 

剩下的zookeeper機器,稱之爲從節點(跟隨者),接收來自leader節點的建議，並贊成傳輸過來的消息，也就是說對消息只有服從和傳輸的特性。

消息層關注的是當leader節點掛掉以後怎麼去替換它,並同步leader節點和follower節點之間的數據。

 

zookeeper 使用客戶端原子消息協議.由於消息層是原子的,zookeeper 能保證本地副本和服務器版本同步。

 

當leader節點接收到寫入請求時, leader節點會計算當前系統的狀態是什麼,何時將寫入做用到服務器,並把當前寫入操做轉換成一個事務並記錄下新的狀態。

 

使用狀況

zookeeper的編程接口 設計的很是簡單,可是用這些能實現一些其餘更高級別的操做,好比同步原語,對成員進行分組和選舉等等.

 

一些分佈式的應用用這些接口實現一些其餘比較高級的功能。

性能

zookeeper 被設計的號稱高性能框架,可是事實狀況如何呢?

來自雅虎的zookeeper開發團隊的研究證實了這點.

(能夠查看下zookeeper 吞吐量隨着讀寫比例變化的圖表,即上圖)

在讀佔主要比例的應用中,性能尤佳,由於寫操做涉及到服務器之間狀態的同步.尤爲是在協調服務這個典型案例中表現的尤爲突出.

zookeeper 吞吐量和讀寫比例的變化關係用的是zookeeper3.2版本,運行在 雙核 2Ghz 及SATA 15k RPM 處理器配置的服務器中.

其中一個負責zookeeper 日誌設備. 快照信息寫入操做系統驅動中.

寫入請求是1Kb寫入, 讀請求也是1kb的寫入(讀寫單元都是1Kb).

servers 標示着 整個zookeeper的集羣大小, 即組成zookeeper服務的服務器數.

 

整個zookeeper集羣有個限定,客戶端都不能直接鏈接zookeeper的leader 節點.

 

可靠性

爲了展現下,咱們系統隨着時間的推移及錯誤出現,咱們運行了一個一個由7個機器組成的zookeeper服務中,咱們使用和此前同樣飽和度的基準測試,

 

可是此次咱們設定寫入操做的比例爲30%, 這個比例是對咱們預期的負載的保守估計值.

 

 

這個圖中有幾個比較關鍵的觀測點.首先,若是從節點失敗並快速恢復了,即便從節點失敗了,zookeeper仍然可以承受住一個比較高的吞吐量.

可是,更爲重要的一點事,leader節點的選舉算法 能讓系統快速恢復,防止吞吐量在短期內迅速下降.觀察發現, zookeeper能在200毫秒內選舉出新的leader節點,

 

第三,隨着從節點的恢復,zookeeper的吞吐量能快速提高,一旦恢復的從節點開始處理請求.

 

zookeeper 項目

zookeeper 已經在許多企業級應用中得到成功,雅虎內部使用zookeeper 進行協調和失敗恢復服務,及消息中間人服務

 

消息中間人是一個高可擴展性的基於發佈-訂閱的消息系統,

他管理成千上萬個消息主題,能夠實現副本和數據傳輸的功能.

zookeeper在雅虎內部還用於數據抓取服務,即網絡爬蟲,同時致力於失敗恢復.

 

許多雅虎的廣告系統使用zookeeper 實現高可靠服務.