之前在項目中使用過zooKeeper，但是隻是簡單的應用和配置，這當然不能滿足我這渴望求知的心，於是我打算重新完整深入學習一下ZooKeeper，做到知其然知其所以然！
ZooKeeper是什麼？
中心觀點：它可以在分佈式系統中協作多個任務。
在計算機發展初期，所有的程序運行和計算都在同一臺計算機上，服務也相對簡單，但是隨着計算機的告訴發展以及各種服務的複雜度不斷提升，單體應用已經不能滿足實際需求，應用也變成由多個主機同時運行。
對於開發人員來說，精力已經不能簡單的放在業務邏輯的開發上，還要分出更多的精力去協同一個應用中多個程序相互合作。人的精力是有限的，當開發一個不可靠的統一協調器去處理這些問題，那麼很可能會引發單點問題。
所以Zookeeper出現了，它保證自身的可靠性，並且使開發人員專注於業務邏輯開發。它提供一組簡單的API，使得開發人員可以選舉主節點，管理組內成員關係，管理元數據等。ZooKeeper包括一個應用開發庫（提供了Java和C兩種語言的API），和一個用Java實現的服務組件。ZooKeeper的服務組件運行在一組專用服務器上，保證了高容錯性和可擴展性。
ZooKeeper怎麼協調多個任務？
協調包含兩個方面
協作：協作意味着多個進程需要一同處理某些事情，一些進程採取某些行動使得其他進程可以繼續工作。在典型的主-從工作模式中，從節點處於空閒狀態時會通知主節點可以接受工作，於是主節點就會分配任務給從節點。
管理競爭：與協作不同，它指的是兩個進程不能同時處理工作的情況，一個進程必須等待另一個進程。同樣在主-從工作模式中，我們想有一個主節點，但是很多進行都想成爲主節點，因此我們需要實現互斥排他鎖。可以認爲獲取主節點身份的過程其實就是獲取鎖的過程，獲得主節點控制權鎖的進程就是主節點進程。
ZooKeeper不適用場景
ZooKeeper適合管理應用協作的關鍵數據，不適合作爲海量數據存儲。因此在設計應用時，最佳實踐是應該將應用數據和協同數據獨立開。
構建分佈式系統需要注意問題
消息延遲：消息傳輸會發生任意延遲，當網絡發生擁堵的時候，先發送的消息未必會先完成發送
處理器性能：操作系統的調度和超載也可能導致消息處理的任意延遲。進程之間發送消息時，延遲時間約等於發送端消耗時間，傳輸時間，接收端處理時間的總和。
時鐘偏移：處理器時鐘並不可靠，它們之間也會發生任意的偏移。因此，依賴處理器時鐘也許會
主從應用
對ZooKeeper來說，這種架構非常具有代表性。要實現主-從模式的系統，我們必須解決下面這些問題：
主節點崩潰：如果主節點發生錯誤，那麼系統將無法分配新的任務或重新分配已失敗的錯誤。
主節點失效時，需要有一個備份主節點來接管主節點的角色。新的主節點不能直接接管新的請求，首先需要恢復到舊的主節點崩潰時的狀態，我們不能依靠崩潰的舊主節點來獲取這些信息，而需要從ZooKeeper獲取。
其中會遇到這樣的問題。當主節點有效，但是由於消息發生延遲（可能由於負載過高，網絡延遲），備份主節點將會接管成爲主節點的角色來執行程序，成爲第二個主節點。並且有可能一些從節點無法同之前的主節點進行通信，這些從節點可能會與第二個主要節點建立主從關係。這個場景導致的問題，我們一般稱之爲腦裂(splitbrain)。描述的是系統中多個部分開始獨立工作，導致整體行爲不一致。
從節點崩潰：如果從節點崩潰，那麼無法完成已分配的任務。
主節點需要具備檢測從節點是否崩潰的能力。一般客戶端向主節點提交任務，然後主節點將任務分配給有效的從節點，從節點執行完任務後會向主節點報告執行狀態。一個從節點崩潰，也許它已經執行了部分任務，也許全部執行，但沒有報告結果。如果整個過程還有其他作用，還需要機制來恢復之前的狀態。
通信故障：如果通信發生故障，那麼主節點無法未從節點分配新的任務。
如果一個從節點與主節點的網絡連接斷開，重新分配一個任務可能會導致兩個從節點執行相同的任務。需要根據任務是否允許多次執行，判斷是否需要處理這種情況。對任務加鎖並不能保證一個任務被執行多次，因爲多個從節點執行同一個任務沒有步驟交錯，因此需要”僅一次“和”最多一次“語義學來處理類似情況。