Zookeeper基本概念

引言

首先在學習Zookeeper之前，我們要知道Zookeeper是什麼東西，其次我們要知道Zookeeper能幹什麼。我通過自己的總結和自己的了解和大家一起分享一下Zookeeper的基本的概念的Zookeeper簡單叢集的搭建。

什麼是Zookeeper

Zookeeper是一個高可用的分布式管理和協調架構，基于ZAB（原子消息廣播協定，有興趣的可以了解一下）實作，而這個原子消息廣播機制又是基于Paxos算法實作，對于這個算法，在後面的部落格中會提到。對于ZAB來說能夠很好的保證分布式環境中資料的一緻性，同樣正是由于這些特性，才使得Zookeeper稱為在分布式系統中解決資料一緻性的最好的工具。

Zookeeper是一個高效的分布式協調服務架構，它暴露了一些公共的服務，例如命名、配置、管理、同步控制、群組服務等等。課可以使用Zookeeper來實作一些功能，例如共識、叢集管理、leader選舉等等的操作。在實際開發中也是比較高效的叢集管理架構。

一般情況下，我們大家Zookeeper叢集至少需要三個Linux的節點。而且在後期擴充的時候，更多的使用的是單數個節點，一個最主要的原因就是有利于Paxos算法的計算。當然實在是由偶數個節點也不是不可以。

Zookeeper特性

順序一緻性

從一個用戶端發起的事務請求，最終将嚴格按照其發起的順序被應用到Zookeeper中去。

原子性

所有事務請求的處理結果在整個叢集中的所有機器上的應用情況都是一緻的，也就是說，要在整個叢集中成功的應用了某個事務，那麼這個叢集中的所有的節點都會應用，不會出現一部分節點有這個事務，一部分節點上沒有這個事務。

例如有三個節點，兩個是從節點，一個是主節點，如果主節點挂掉之後從節點就會上升為一個主節點，整個叢集全部正常工作，這個就是叢集之間的原子消息廣播，如果修改了Zookeeper上的其中一個節點上的内容，其他節點上的内容也是一樣的。

單一視圖

對于單一視圖來說，無論用戶端連接配接的是哪個Zookeeper伺服器，其他看到的服務端資料模型都是一緻的，不會出現多種視圖。

可靠性

一旦伺服器上的某一個節點成功應用了一個事務，并對用戶端完成正确的響應，那麼由該事務引起的服務端狀态将會被保留下來，除非出現另一個事務将其修改。

實時性

通常我們所說的實時性就是指一個事務一旦被應用成功，那麼用戶端會立即從伺服器上擷取變化後的新的資料，但是Zookeeper僅僅能夠保證一段時間内，用戶端最終一定能從伺服器端讀取最新的資料狀态，想要資料持久化還是要加入其它的資料持久化的技術。

Zookeeper設計目标

• 1 簡單的資料結構，Zookeeper就是以比較簡單的樹形結構來進行互相協調（也被稱為是樹形命名空間）
• 2 可以建構叢集，一般情況下Zookeeper叢集通常是一組機器組成，一般情況下最少是三台，3-5台機器就課可以組成一個Zookeeper叢集，隻要叢集中超過半數以上的機器都能夠正常使用，那麼正規叢集就能夠正常對外部提供服務。
• 3 順序通路。對于一個來自用戶端的請求，Zookeeper都會配置設定一個全局唯一的遞增編号，這個編号反應了所有事務操作的先後順序，應用程式可以使用Zookeeper這個特性來實作更高層次的同步操作。
• 4 高性能，由于Zookeeper将會将全量的資料存儲在記憶體中，并直接服務于所有的非事務請求。是以尤其在讀操作方面性能是非常突出的，在Jmater壓力測試下（100%讀請求場景），結果大約在12-13w的QPS

Zookeeper的結構

Zookeeper維護的是一個具有層次關系的資料結構，也就是我們常說的樹形結構，但是也不完全是，它類似于Linux檔案系統。

Zookeeper的資料模型

Znode 可以簡單的了解為每個層級的節點

• 每個字目錄項如NameService都被稱為是一個Znode，這個Znode是被它所在的路徑唯一辨別的。
• Znode可以有子目錄和子節點，并且每個Znode可以存儲資料，注意EPHEMERAL類型的目錄是不支援子目錄的概念。
• Znode是由版本的（這個在後期的部落格中會有），每個Znode中存儲的資料可以有多個版本，也就是一個通路路徑中可以存儲多份資料。
• Znode可以是臨時節點，一旦建立這個Znode的用戶端與伺服器失去聯系，這個Znode節點就會被自動删除，Zookeeper用戶端與伺服器采用長連接配接方式，每個用戶端和伺服器通過心跳來保持連接配接。這個連接配接狀态被稱為Session，如果Znode是臨時節點，這個Session就會失效，Znode就會被删除。
• Znode 的目錄名稱是可以自動編号的，這個在之前的時候提到過自動編号來判斷事務的先後順序。例如APP1已經存在，如果再次建立就會被自動命名為APP2。
• Znode 可以被監控，這個監控也可以包括這個目錄中存儲的資料的修改、子節點目錄的變化等，一旦變化可以通知設定監控的用戶端，這個是Zookeeper的核心的特性，Zookeeper的很多的功能都是通過這個特性來實作的，這個就是我們之前提到過的實時性。

Zookeeper的組成

Zookeeper 服務根據其在叢集中的特性分為三種Leader、Follower、Observer，其中Follower和Observer統稱為Learner（學習者）

Leader：負責用戶端的writer類型的請求

Follower：負責用戶端reader類型的請求，參與Leader的選舉等

Observer：是一個特殊的Follower，它可以接收用戶端的reader請求，但是不參加選舉（擴容系統支援能力，提高讀取資料的速度，因為它不接受任何同步的寫入請求，隻負責Leader同步資料）

Zookeeper應用場景

經典應用場景

Zookeeper從設計模式的角度上來看，是一個基于觀察者模式設計的分布式服務管理架構，它負責存儲和管理大家共同關注的資料，然後接受觀察者的注冊，一旦這些資料狀态發生變化，Zookeeper就将負責通知已經在Zookeeper上注冊的那些觀察者作出正确的反應，進而實作了叢集中的而類似與Master/Slave管理模式

配置管理

配置管理在分布式應用中是比較常見的，例如在我現在做的分布式ESB系統中，對于各個應用的配置都會有自己的配置資訊。如機器的配置清單、運作的開關配置、資料配置資訊等等。這些都是全局的配置，而這些全局的配置有三個特點

• 資料量小
• 資料内容在運作時根據不同的環境發生變化
• 資料中各個節點的資訊的共享的，一緻性發生變化

叢集管理

Zookeeper可以幫助維護目前系統叢集中的機器的狀态，還為這些機器選擇了一個總管Leader，讓這個總管來管理整個叢集，主要就是支援一些簡單的容錯機制

• 知道目前叢集中有 多少個工作機器
• 對叢集中每天叢集中的運作時狀态進行資料收集
• 對叢集中的每台機器進行上下線操作

釋出訂閱

Zookeeper是一個比較典型的釋出/訂閱模式的分布式資料管理和協調架構，提到釋出/訂閱的概念現在有好多的工具都可以實作這種類似于釋出/訂閱的模式，例如Redis、各種MQ、Kafka等等。在Zookeeper中一個比較常用的場景就是資料庫的切換，Zookeeper能夠幫助把資料庫的切換通知發送到各個節點的用戶端上，每個用戶端收到變更之後，就可以重新擷取新的資料

分布式日志收集

可以做一個分布式日志收集系統收集所有日志資訊，進行統一管理，還有分布式鎖，隊列管理等等。

Zookeeper最主要的特性就是在分布式場景下高可用，但是原生的API實作分布式功能是非常困難的，對于一個團隊來說是比較浪費時間，就算是實作了也未必能夠穩定運作，這裡就推薦幾個第三方的用戶端。例如Curator架構，這個作為Apache的頂級項目，是比較推薦使用的。

Zookeeper的使用場景是非常廣泛的，例如Hadoop、Storm、消息中間件、RPC服務架構、資料庫增量訂閱與消費者元件（MySQL Binlong）、分布式資料庫同步系統、淘寶的Otter等等。都是Zookeeper的使用。另外，Zookeeper使用ZAB（原子消息廣播）作為底層實作。使用了CAS原子消息算法，Paxos複制算法，在分布式的應用中有比較好的應用。