（純乾貨）從幾個實例出發-----理解zookeeper概念（架構分析）
什麼是zookeeper，對於剛接觸分佈式的朋友（包括我）來說，這都是一個很難解釋的問題。我們在網上或者論文亦或是書籍中看到的zookeeper的概念解釋都十分生澀難懂。因此這裏我們通過幾個案例，我們通過分析這些工程的架構以及改進後的架構來引入zookeeper的概念。
1.現在有這樣一個需求，有一組（很多臺）服務器，他們構成了服務端，主要用來採集網絡上的數據，現在客戶端也是一組（很多臺）服務器，他們用來分析服務端傳過來的數據，因爲數據是實時源源不斷的流入服務端，因此它在進入客戶端服務器時也是實時流入的，具體架構如下圖：
這時候我們的客戶端服務器在分析數據時可能就會出問題，因爲數據實時流入，數據量過大就可能使某臺客戶機宕機。一旦某臺客戶服務器宕機，則該部分數據就無法分析，而新的數據還繼續流入服務端的服務器從而覆蓋了未分析的那些數據，可能會引發較爲嚴重的問題。這個時候，我們可能會思考，我們給每一臺客戶服務器都增加一個slave服務器（從服務器），這樣一旦某臺服務器宕機，它的slave將會代替原來的服務器繼續工作。其架構如下：
但是這樣做又會引發一系列的問題，如我們的slave如何才能知道主服務器（原來工作的服務器）的工作進度以實現能夠接續它原來的進度工作，如何獲取主服務器的配置信息？我們可以考慮引入數據庫，將這些記錄在數據庫中，一旦主服務器宕機，slave就從數據庫讀取信息繼續接着主服務器之後工作。但是在這種環境中配置數據庫又成了一件很困難的事，可能會連鎖遇到更多的問題，而且每一對主從服務器都需要記錄這樣的信息，往往集羣中有幾十臺幾百臺服務器，在添加這些記錄時很容易出錯且很麻煩。
這時候我們就想，如果有這樣一個第三方平臺，能夠記錄下每一臺服務器的工作進度，並且可以監控所有的服務器就好了。這時候，zookeeper登場了。它剛好可以做這樣兩件事，我們來看看它是不是解決了上面的問題。
首先，zookeeper記錄了所有的客戶服務器的工作進度和配置信息；其次，zookeeper可以幫助我們監控所有的服務。當某一臺服務器發生故障時，他能立刻檢測到，並給其他的服務器發通知，告知其他正常的服務器：某服務器發生故障不能正常工作，需要求助。這時空閒的服務器或是某負荷小的服務器（可以人爲敲代碼修改規則）就會從zookeeper讀取宕機服務器的工作進度和配置等信息，暫時接管當即服務器的工作。當宕機服務器恢復正常後再將工作交還給該服務器。
其架構如下：
只是在其中加入了一個第三方zookeeper，就完美的解決了上述令人頭疼的問題。這是因爲zookeeper本身是高可靠的。爲什麼說它高可靠呢。因爲zookeeper本身也是一個分佈式集羣，它的內部一般有奇數個服務器，只要有半數以上的服務器正常運行就可以保證zookeeper的正常運轉。
2.現在我們來看第二個實例，我們將需求反過來，現在有一個客戶端，想要訪問服務器，服務器有多臺，但是在一個時間段工作的服務器（master）只有一臺，其他的服務器是爲了防止當前工作的服務器宕機時備用的，都是slave。可是在最初的時候我們怎麼選取master主機呢。這就涉及到服務器主從選舉問題。
我們同樣可以引入zookeeper。我們人爲編寫代碼制定一套選舉主從服務器的規則（如誰的ip地址大就是主服務器）。指定完之後主服務器的信息以及工作進度就會記錄在zookeeper中，並且zookeeper可以監控這些服務器。客戶機發送的請求就會進入到master，由master完成交互。一旦master發生故障，其餘的slave再次根據制定的規則選出一個新的master並獲取原來master的工作記錄繼續繼承原master工作。怎麼樣，這個是不是不難理解吧！
我們通過上面兩個實際的案例分析，可以發現，他們都有一個共同的特點，就是他們都需要一個第三方平臺能夠保管數據，並且提供節點監聽。這正是zookeeper做的核心的兩件事。
這樣一來，大家應該對zookeeper究竟是做什麼的有一個比較直觀的瞭解了吧。關於具體的zookeeper的定義網上資料很多，這裏就不重複抄下來了。