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 實現高可靠服務.