1.什麼是ZK
ZK是一個高效的分散式協調服務，它暴露了一些公用服務，比如命名/配置管理/同步控制/群組服務等。我們可以使用ZK來實現比如達成共識/叢集管理/leader選舉等。
ZK是一個高可用的分散式管理與協調框架，基於ZAB演算法（原子訊息廣播協議）的實現。改框架能夠很好地保證分散式環境中資料的一致性。也正是基於這樣的特性，使得ZK成為解決分散式一致性問題的利器。

• 順序一致性：從一個客戶端發起的事務請求，最終將會嚴格地按照其發起的順序被應用到ZK中去。
• 原子性：所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一致的，也就是說，要麼整個叢集所有機器都成功應用了某一事務，要麼沒有應用，一定不會出現部分奇蹟應用了該事務，而另一部分沒有應用的情況。
• 單一試圖：無論客戶端連線的是哪一個ZK伺服器，其看到的伺服器端資料模型都是一致的。
• 可靠性：一旦伺服器成功地應用了一個事務，並完成對客戶端的響應，那麼該事務所引起的伺服器端狀態將會被一致保留下來。除非有另外一個事務對其更改。
• 實時性：通常所說的實時性就是指一旦事務被成功應用，那麼客戶端就能立刻從伺服器上獲取變更後的新資料，ZK僅僅能保證在一段時間內，客戶端最終一定能從伺服器端讀取最新的資料狀態。

2.ZK設計目標

• 目標1：簡單的資料結構。ZK就是以簡單的樹形結構來進行相互協調的。（也叫樹形名字空間）
• 目標2：可以構建叢集。一般ZK叢集通常由一組機器構成，一般3~5臺機器就可以組成一個ZK叢集 了。只要叢集中超過半數以上的機器能夠正常工作，那麼整個叢集就能夠正常對外提供服務。
• 目標3：順序訪問。對於來自每一個客戶端的每一個請求，ZK都會分配一個全域性唯一的遞增編號，這個編號反應了所有事務操作的先後順序，應用程式可以使用ZK這個特性來實現更高層次的同步。
• 目標4：高效能。由於ZK將全量資料儲存在記憶體中，並直接服務於所有的非事務請求，因此尤其在讀操作為主的場景下效能非常突出。在JMaster壓力測試下（100%讀請求場景下），其結果大約在12~13W的QPS。

3.ZK組成
ZK server根據其身份特性分為三種：leader,Follower,Observer，其中Follower和Observer又統稱Learner（學習者）
Leader:負責客戶端的write型別請求
Follower:負責客戶端的reader型別請求，參與leader選舉等。
Observer:特殊的”Follower”，其可以接受客戶端reader請求，但不參與選舉。（擴容系統支撐能力，提高讀取速度。因為它不接受任何同步的寫入請求，只負責與leader同步資料）

4.ZK典型應用場景
ZK從設計模式角度來看，是一個基於觀察者模式設計的分散式服務管理框架，它負責儲存和管理大家都關心的資料，然後接受觀察者的註冊，一旦這些資料的狀態發生變化，ZK就將負責通知已經在ZK上註冊的那些觀察者做出相應的反應，從而實現叢集中類似Master/Slave管理模式.

• 管理配置：配置的管理在分散式應用環境中很常見，比如我們在平常的應用系統中，經常會碰到這樣的需求：如機器的配置列表、執行時的開關配置、資料庫配置資訊等。這些全域性配置資訊通常具備以下3個特性：
  1）資料量比較小
  2）資料內容在執行時動態發生變化
  3）叢集中各個節點共享資訊，配置一致。
• 叢集管理：ZK不僅能夠幫助你維護當前的叢集中機器的服務狀態，而且能夠幫你選出一個“總管”，讓這個總管來管理叢集，這就是ZK的另一個功能Leader，並 實現叢集容錯功能。
  1）希望知道當前叢集中究竟有多少機器工作。
  2）對叢集中每天叢集的執行時狀態進行資料收集
  3）對叢集中每臺叢集進行上下線操作
• 釋出與訂閱：ZK是一個典型的釋出/訂閱模式的分散式數控管理與協調框架，開發人員可以使用它來進行分散式資料的釋出與訂閱。
• 資料庫切換：比如我們初始化ZK的時候讀取其節點上的資料庫配置檔案，當配置一旦發生變更時，ZK就能幫助我們把變更的通知傳送到各個客戶端，每個互動在接收到這個變更通知後，就可以重新進行最新資料的獲取。
• 分散式日誌的收集：我們可以做一個日誌系統收集叢集中所有的日誌資訊，進行統一管理。
• 分散式鎖、佇列管理等等

5.ZK的特性就是在分散式場景下高可用，但是原生的API實現分散式功能非常困難，團隊去實現也太浪費時間，即使實現了也未必穩定。那麼可以採用第三方的客戶端的完美實現，比如Curator框架，他時Apache的頂級專案。