zookeeper-1. zookeeper簡介說明

1.1 zookeeper介紹

  zookeeper是一個高可用的分佈式管理與協調框架，基於ZAB算法(原子消息廣播協議)的實現。

可以很好保證分佈式環境中數據的一致性。正是基於這樣的特性，使得zookeeper成爲了解決分佈式一致性問題的利器。

·順序一致性：從一個客戶端發起的事務請求，最終會嚴格的按照其發起的順序被應用到zookeeper中。

·原子性：全部事務請求的處理結果在整個集羣中全部的機器上的應用狀況是一致的。也就是說要麼整個集羣全部的機器都成功應用了某一事務，要麼沒有應用。

·單一視圖：不管客戶端鏈接的是哪個zookeeper服務器，其看到的服務器端數據模型都是一致的。

·可靠性：一旦服務器成功的應用了一個事務，並完成對客戶端的響應，那麼該事務引發的服務器狀態將會被一致保留下來。除非有另外一個事務對其修改。

·實時性：一般所說的實時性是指一旦事務被成功應用，那麼客戶端能馬上從服務器上獲取更新後的新數據，zookeeper僅僅能保證在一段時間內，客戶端最終必定能從服務器端讀取最新的數據狀態。

1.2 zookeeper設計目標

1）簡單的數據結構：zookeeper就是以簡單的樹形結構來進行相互協調的。

2）能夠構建集羣：通常zookeeper集羣一般是由一組機器構成的，通常3-5臺機器就能夠組成一個zookeeper集羣了。只要集羣中超過半數以上的機器可以正常工做，那麼整個集羣就可以正常對外提供服務了。

3）順序訪問：對於每個客戶端的每個請求，zookeeper都會分配一個全局惟一的遞增編號，這個編號反應了全部事務操做的前後順序，應用程序可使用zookeeper的這個特性來實現更高層次的同步。

4）高性能：因爲zookeeper將所有數據存儲在內存中，並直接服務與全部的非事務請求，所以尤爲在讀操做爲主的場景下性能很是突出。

1.3 zookeeper的結構

  zookeeper會維護一個具備層次關係的數據結構，它很是相似於一個標準的文件系統。

1.4 zookeeper數據模型

1）每個子目錄項如NameService都被稱做爲znode，這個znode是被它所在的路徑惟一標識的。如Server1這個znode的標識爲 /NameService/Server1。

2）znode能夠有子節點目錄。而且每一個znode能夠存儲數據、數據是有版本的。每一個znode中存儲的數據能夠有多個版本，也就是一個訪問路徑能夠存儲多分數據。

3）znode能夠是臨時節點，一旦建立這個znode的客戶端與服務器失去聯繫，這個znode也將刪除，zookeeper的客戶端和服務器通訊採用長鏈接方式，經過心跳來保持鏈接，這個鏈接狀態稱session，若是znode是臨時節點，這個session失效，znode也就刪除了。

4）znode能夠被監控，包括這個目錄節點中存儲的數據的修改，子節點目錄的變化等，一旦變化能夠通知設置監控的客戶端，這個是zookeeper的核心特性。

1.5 zookeeper組成

1）Leader：負責客戶端的write請求；

2）Follower：負責客戶端的read請求，參與leader選舉等；

3）Observer：特殊的Follower，其能夠接受客戶端read請求，但不參與選舉；擴容系統支撐能力，提升了讀取速度。由於他不能接受任何同步的寫入請求，只負責與leader同步數據；