? ? ? ? 在幾十年前，一個獨立的計算機上往往部署著一套完整的應用系統。當時因為網絡穩定性及速度的限制，將相關聯的服務部署在一臺機器上，讓它們使用系統機制通信——比如管道，文件等，往往是最穩定和最高效的。然而隨著網絡技術的發展，特別是“云計算”和“大數據”的盛行，我們越來越多的談到“分布式系統”——建立在網絡上的軟件系統。這樣部署在不同機器上的關聯服務就依賴于網絡以及它們自定義的“協議”和“機制”來構建出更加健壯和系統。之前在單機時代，“機制”是受限于操作系統；而網絡時代，“機制”將變得更加自由——不同廠商可以定義自己的“機制”以讓分布式系統運轉起來。（轉載請指明出于breaksoftware的csdn博客）

? ? ? ? 我們先閉眼冥想下：如果我們去構建分布式系統，需要考慮些什么問題？

1. 網絡通信協議。這個難度相對低些，我們忽略。
2. 異常處理方案。這個就非常復雜了，異常有來自網絡的，有來自系統的，有來自用戶錯誤的使用……
3. 分布式系統維護方案。如果系統內部發生機器增刪行為，怎么處理？如果某臺機器變得不穩定了，怎么辦？……
4. CAP。除了上述，我們還會遇到CAP定律（https://en.wikipedia.org/wiki/CAP_theorem）：一致性（Consistency），可用性（Availability）和分區容錯性（Partition Tolerance）最多只能同時滿足兩個。

? ? ? ? 簡單的說，就是在一個分布式系統中，如果發生網絡故障，我們無法同時滿足強一致性和可用性：

• 如果要滿足強一致性。請求落在故障機器上時，要一直等待該機器和其他機器同步完最新數據后才能返回。這就犧牲了可用性。
• 如果要滿足可用性。請求落在故障機器上后立即返回該機器上的數據，但是其數據可能不是最新的。這就犧牲了強一致性。

? ? ? ? 可見設計一套分布式系統還是要面臨很多問題，而且我們設計往往會結合自身業務特征，從而增加了重用的難度。如果每個公司都設計出自己的一套，其場景就像動物園里的動物：琳瑯滿目。雖然這對看客來說是件好事，但是增加動物園的管理負擔——比如喂養老虎的飼養員可能不會喂養兔子，需要雇傭更多的員工或者培訓現有的員工。這個時候，一個超級飼養員出現了——zookeeper——動物園（zoo）飼養員（keeper）。

? ? ? ? zookeeper設計了一套通用“機制”，提供了少量簡單的API，可以讓我們便捷的構建分布式協作系統。依然以動物飼養為例，一個飼養員如果是要給兔子去做飯，就可以用zookeeper提供的切割機去切草——多切幾次變得比較細；他要是去給老虎做飯，還可以使用zookeeper提供的切割機去切肉——只切一次讓老虎可以大口吃肉。

? ? ? ? zookeeper為什么大受歡迎？我覺得除了方案具有通用性外，還和其設計特點有關——將復雜的問題簡單化，把抽象的問題實例化。

? ? ? ? zookeeper并沒有讓各種信息邏輯糅雜在一個服務中。設想下，如果我們將業務邏輯、分布式系統維護邏輯都放在下面一臺機器上，則要求每臺機器互聯，而且一旦發生某臺機器斷網，其他機器都將要處理這樣的異常。這樣看似服務部署變得簡單，但是會導致服務內部比較雜亂。

? ? ? ? zookeeper則采用“分角色”的方案。在一個經典的zookeeper系統中，業務代碼只在Zookeeper Client中，這樣開發者只要專心于Client上的業務邏輯實現就行了，而分布式系統中大部分異常可以交由zookeeper提供的Zookeeper Server服務去解決。

? ? ? ? 那么Client和Server間交互的是什么信息呢？ 我們稱這樣的信息叫做“元信息”。元信息存在于Server上，而Client端通過網絡向Server端進行讀寫，從而達到“分布式協同”的功能。于是元信息的設計關系了整個系統的復雜程度。

? ? ? ? zookeeper設計的元信息結構和我們日常使用的文件目錄系統很像。這樣我們在遇到“分布式協同難題”時，可對照著“文件目錄系統”這樣“老知識”去梳理和解決，這無疑大大降低了理解的難度。

? ? ? ? 不同的Client可以同時讀寫同一個節點信息。Zookeeper Server可以保證信息要么被全部寫入，要么寫失敗。而信息讀取方，也只能一次性讀到全部數據，而不可以讀取部分數據。所以這種類似“原子性”的特性，可以讓Client設計者不用去關心臟數據的問題。

? ? ? ? Client還可以向Server端注冊對節點變動的監視。這樣就免除了Client端采用輪訓這種低效的模式。這和操作系統提供的監控文件變動功能也很像。當然Zookeeper設計的這套結構自然有自己的特點，比如臨時節點、有序節點、節點版本等，這些我們在之后的章節會介紹。

? ? ? ? 跳出這些微觀的設計，我們再看下基于zookeeper的分布式系統整體結構，發現Zookeeper Server之間的并非相互連接的。如果我們讓不同Server之間相互連接，會使得每個Server的設計變得非常復雜，因為它要兼顧到每個和其他Server的連接信息。

? ? ? ? zookeeper做了一個這樣的設計：選舉“領導”（leader）。這就像我們選舉領導一樣，一個集群里有選舉權的員工可以相互交流推選出一個領導，落選的自然成為“追隨者”(follower)。被推選為“領導”的服務負責維護各個Zookeeper Server的一致性和可用性。比如一個連接到“追隨者”的Client提交了一個修改信息的請求，“追隨者”會將“修改”提交給“領導”，“領導”要將這個修改同步給其他“追隨者”。這樣就達到整個系統的信息的一致性。為了讓“領導”可以專心做自己的事，所以不太建議Client端直接連接到Leader服務。

? ? ? ? 在大部分場景下，只有“領導”和“追隨者”是足夠的。但是如果這個集群的需要承載比較大的請求量，我們就需要增加機器，也就是增加“追隨者”。這樣雖然解決了問題，但是會帶來另外一個問題——太多的“追隨者”需要更多的時間去選舉“領導”，而且這個耗時會導致系統一段時間內部分功能不可用，最最關鍵的是這個時耗可能很長。于是我們就剝奪了一些“追隨者”的選舉權，讓它們成為“觀察員”。這樣在Leader失效時，只有少部分Follower進行投票選舉，從而降低了系統不可用的時間。

?

總結

以上是生活随笔為你收集整理的zookeeper快速入门——简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。