最近在學習ZooKeeper（以後都用ZK代稱），爲了驗證自己的學習，希望對ZK相關的知識進行整理，一方面檢驗學習成果，一方面進行筆記整理。
一般而言，我們學習一件東西的動機是這個東西對我們有用，不管是當前立即能帶來效用還是長遠看能帶來好的收穫。學習ZK也一樣，首先要明白學習它幹嘛？我們在開發中能用ZK做些什麼？通過使用ZK能帶來哪些便利？能解決哪些開發中的痛點？在我的今後的開發中要不要用它？這些問題需要我們搞清楚，這樣才能提高我們的開發效率，才能真正發揮ZK的優點。
（1）ZK是什麼？
ZK最早是由雅虎研究院的一個研究小組研發的，當時他們面對的問題是在其內部的大型分佈式系統都需要一個分佈式協調的一個系統，早起的開發的系統往往都由單點問題，爲了保證一致性往往只有一個主節點去完成整個系統的一致性功能。後來，雅虎的開發人員就試着去開發一個通用的無單點問題的分佈式協調框架，這樣一來，開發人員就可以把精力放在業務邏輯的開發上來，而不用過多關注系統的協調問題。所以，總的來說，ZK是一個分佈式的、開源的、分佈式應用程序協調服務。
（2）利用ZK能做些什麼工作？
光說它是一個分佈式應用程序協調服務可能不是那麼明顯，讀到這兒可能仍然會有疑惑，到底是個什麼東西。接下來通過ZK可以具體實現的功能，配合ZK的典型使用場景來說明它到底能幹什麼。
- 數據發佈/訂閱
數據發佈/訂閱系統，典型的就是所謂的配置中心，通過配置中心可以對系統中的配置信息進行修改和推送。應用系統發佈者可以把數據發佈到ZK的一個或者一些列的節點上，而信息的訂閱者可以進行訂閱，通過對這些節點的數據進行監聽，從而達到配置的動態更新等服務，實現配置信息的集中式管理和數據的動態更新。在我工作過程中，一些小的動態的配置信息就是通過ZK進行動態配置的，一個例子就是系統管理員信息，通過這些配置，可以在管理員變更的時候，不重啓機器，達到管理員信息的動態變更。
- 負載均衡
負載均衡是用來對多個計算機、網絡連接、cpu、磁盤等資源進行分配的負載，主要是爲了達到資源的最大化利用、最大化吞吐、最小化響應時間和避免某些服務器過載。通過利用ZK集羣可以實現動態的DNS域名解析服務，每個應用自己解析ip和port，我們可以將DNS信息配置在ZK中的節點之上，然後應用通過在節點註冊watcher來動態監聽域名配置，這樣在域名ip動態變化是可以監聽到，及時進行信息更新。這種一般在公司內部開發時使用，這樣可以避免過多的本地host綁定，讓你的PE去動態維護就好了，開發只關注自己的業務邏輯即可。
- 命名服務
命名服務也是在分佈式系統中常用的一種公共服務，而利用ZK可以實現一套分佈式的全局唯一ID的分配機制。ZK的幾點中有一種特殊的節點--順序節點。這種節點在創建完成以後，ZK會自動在其名字後面加上節點的順序，ZK可以保證在分佈式系統中，名字的順序性，其機制就是利用ZK的一致性來保證併發訪問時的節點的唯一性。
- 分佈式協調/通知
分佈式協調/通知服務是分佈式系統中的重要一環，將不同的分佈式的組建有機的結合在一起。通過引入協調者，可以讓分佈式協調的職責從應用分離，可以減小系統之間的耦合性，提高系統的可擴展性。這種功能的實現比較簡單，主要是利用ZK的watcher機制，通過監聽節點的變化，從而感知相應的通知信息，然後作出不同的響應處理。
- 集羣管理
集羣管理的功能應用較多，可以通過ZK實現集羣機器運行狀態蒐集、集羣機器的工作狀態、機器的上下線等操作。在我工作總，主要利用ZK實現狀態蒐集、任務的上下線、機器機器工作狀態蒐集等，這些實現也相對簡單，利用ZK的節點監聽的功能就可以很好的實現。
- master選舉
ZK節點的創建有一個特點就是：如果同時有多個客戶端請求創建同一個節點，那麼最終只會有一個客戶端的請求會創建成功，利用這個特點，當需要進行master選舉時，只需要都進行創建請求即可，請求成功的爲master。我在工作中，在master不需要本人控制時就利用這個機制去創建。這裏創建的節點不可控，由zk決定，如果你希望可控，可以再創建一個固定節點，把希望成爲leader的節點信息寫入，當出發選舉時，多一步判斷操作即可。
- 分佈式鎖
同樣利用上面的特性，需要鎖時就向特定目錄發起創建節點請求即可，不需要是就刪除該節點。
- 分佈式隊列
分佈式隊列的實現利用ZK的順序節點，在隊列節點下創建順序節點，在取數據時，首先獲得所有子節點，然後確定自己即誒單序號在子節點中的順序，如果自己不是最小的子節點，那麼就等待，同時向比自己小的最後一個節點註冊watcher，接收到watcher通知後重覆上述步驟即可。