[高級]Zookeeper介紹（二）——Zookeeper概述

在Zookeeper介紹（一）——背景知識中介紹過，隨着網站的不斷髮展，逐漸從集中式演變到分佈式。可是，在分佈式系統中存在着不少數據一致性的問題。那麼，有沒有什麼系統或者組件可以幫助咱們解決這些一致性問題呢？本文將簡單介紹一個分佈式服務協調組件——Zookeeper。

什麼是Zookeeper

Zookeeper是一個開放源碼的分佈式服務協調組件，是Google Chubby的開源實現。是一個高性能的分佈式數據一致性解決方案。他將那些複雜的、容易出錯的分佈式一致性服務封裝起來，構成一個高效可靠的原語集，並提供一系列簡單易用的接口給用戶使用。

Zookeeper提供了哪些特性

他解決的分佈式數據一致性問題，提供了順序一致性、原子性、單一視圖、可靠性、實時性等。

順序一致性：客戶端的更新順序與他們被髮送的順序相一致；

原子性：更新操做要麼所有成功，要麼所有失敗；

單一試圖：不管客戶端鏈接到哪個服務器，均可以看到相同的ZooKeeper視圖；

可靠性：一旦一個更新操做被應用，那麼在客戶端再次更新它以前，其值將不會被改變；

實時性：在特定的一段時間內，系統的任何變動都將被客戶端檢測到；

Zookeeper工做過程

上圖中，一個Zookeeper集羣中有五臺機器，在整個集羣剛剛啓動的時候，會進行Leader選舉，當Leader肯定以後，其餘機器自動成爲Follower，並和Leader創建長鏈接，用於數據同步和請求轉發等。當有客戶端機器的寫請求落到follower機器上的時候，follower機器會把請求轉發給Leader，由Leader處理該請求，好比數據的寫操做，在請求處理完以後再把數據同步給全部的follower。

CAP理論

在分佈式領域，有一個著名的理論——CAP理論。CAP理論的核心觀點是任何軟件系統都沒法同時知足一致性、可用性以及分區容錯性。

值得一提的是，做爲一個分佈式系統，分區容錯性是一個必需要考慮的關鍵點。一個分佈式系統一旦喪失了分區容錯性，也就表示放棄了擴展性。由於在分佈式系統中，網絡故障是常常出現的，一旦出如今這種問題就會致使整個系統不可用是絕對不能容忍的。因此，大部分分佈式系統都會在保證分區容錯性的前提下在一致性和可用性之間作權衡。

在CAP這三個關鍵的性質中，同時知足CA兩點的是著名的數據庫中ACID、同時知足AP兩點的是註明的BASE理論。

Zookeeper和CAP的關係

上面介紹過，沒有任何一個分佈式系統能夠同時知足CAP，Zookeeper通常以集羣的形式對外提供服務，那麼Zookeeper在CAP中是如何取捨的呢？

ZooKeeper是個CP（一致性+分區容錯性）的，即任什麼時候刻對ZooKeeper的訪問請求能獲得一致的數據結果，同時系統對網絡分割具有容錯性;可是它不能保證每次服務請求的可用性(注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序須要從新請求才能得到結果)。可是別忘了，ZooKeeper是分佈式協調服務，它的 職責是保證數據(注：配置數據，狀態數據)在其管轄下的全部服務之間保持同步、一致;因此就不難理解爲何ZooKeeper被設計成CP而不是AP特性的了，若是是AP的，那麼將會帶來恐怖的後果(注：ZooKeeper就像交叉路口的信號燈同樣，你能想象在交通要道忽然信號燈失靈的狀況嗎?)。並且， 做爲ZooKeeper的核心實現算法 Zab，就是解決了分佈式系統下數據如何在多個服務之間保持同步問題的。

若是 ZooKeeper下全部節點都斷開了，或者集羣中出現了網絡分割的故障(注：因爲交換機故障致使交換機底下的子網間不能互訪);那麼ZooKeeper 會將它們都從本身管理範圍中剔除出去，外界就不能訪問到這些節點了，即使這些節點自己是「健康」的，能夠正常提供服務的;因此致使到達這些節點的服務請求 被丟失了。