zookeeper 是乙個開源的高可用的分布式資料管理與系統協調框架，基於對 paxos 演算法的實現，保證了分布式環境中資料的強一致性。
發布與訂閱模型：發布者發布資料到 zk 節點上，供訂閱者動態獲取資料。
在資料量很少，但是資料更新快的場景下：
訊息中介軟體中的發布者和訂閱者的負載均衡，linkedin 開源的kafkamq和 阿里開源的metaq都是通過 zookeeper 來做到生產者 & 消費者的負載均衡：
生產者負載均衡：metaq 執行時，會把所有broker和對應的分割槽資訊全部註冊到zk 節點上，然後生產者通過 zk獲取分割槽列表之後，會依次輪詢的策略來選擇乙個分割槽來傳送訊息。
消費者負載均衡：乙個消費者可以消費（檢視）乙個或多個分割槽中的訊息，但是乙個分割槽的訊息只會由乙個消費者來消費。
metaq 的消費策略是：
當某個消費者故障或重啟時，其他消費者會感知到（通過 watch 消費者列表），然後重新進行負載均衡，保證所有分割槽都有消費者進行消費。
在分布式系統中，通過使用命名服務，客戶端應用通過指定名字來獲取資源、服務的位址等資訊。較為常見的：分布式服務框架中的服務位址列表。
阿里巴巴集團開源的分布式服務框架dubbo中使用zookeeper來作為其命名服務，維護全域性的服務位址列表。在 dubbo 實現中：
以上註冊的位址都是臨時節點，保證服務提供者和消費者能夠自動感應資源的變化。
zookeeper 中特有的watcher 註冊與非同步通知機制，實現分布式環境下不同系統之間的通知與協調，實現對資料變更的實時處理。
也就是說，不同系統都對 zk 上同乙個節點進行註冊，監聽節點的變化（包括節點本身內容及子節點的），其中乙個系統更新了節點，那麼另乙個系統能夠收到通知，並作出相應處理。
總之，使用 zookeeper 來進行分布式通知和協調能夠大大降低系統之間的耦合。
利用 zookeeper 兩個特性，就可以實現集群機器存活性監控系統：
master 選舉是 zookeeper 中最為經典的應用場景。
在分布式環境中，有些耗時的操作，往往只需讓整個集群中的某一台機器進行執行，其餘的機器可以共享這個結果。那麼誰去執行呢？於是就要靠master 選舉了。
首先利用 zookeeper 的強一致性，保證分布式高併發情況下節點建立的全域性唯一性。即：同時有多個客戶端請求建立 /currentmaster 節點，但最終一定只有乙個客戶端請求能夠建立成功。
其次，如果需要動態 master 選舉，那就要用到ephemeral_sequential型別節點。此時，允許所有的請求都能夠建立成功，但是有建立順序，於是每次選取序列號最小的那個機器作為 master，如果 master 機器掛了，那麼之後最小的機器繼續當 master。
鎖服務可以分為兩類：保持獨佔、控制時序。
佇列方面分兩種：先進先出佇列、等到佇列成員聚齊之後才統一按序執行。
第一種：fifo 佇列，與分布式鎖服務中你給的控制時序場景原理基本一致。
第二種：fifo 佇列的增強版。做法：在 /queue 這個節點下，預先建立乙個/queue/num節點，並且賦值為n，表示佇列的大小，當佇列成員數到達佇列大小時，就開始執行。
第二種用法的典型場景：分布式環境中，乙個大任務 taska，需要在很多子任務完成（或者條件就緒）情況下才能進行。此時，只要其中乙個子任務完成（就緒），就去 /tasklist 下建立自己的臨時節點，當 /tashlist 發現自己下面的子節點滿足指定個數，就可以進行下一步按序處理了。
ZooKeeper典型使用場景
zookeeper是乙個高可用的分布式資料管理與系統協調框架。基於對paxos演算法的實現，使該框架保證了分布式環境中資料的強一致性，也正是 基於這樣的特性，使得zookeeper能夠應用於很多場景。網上對zk的使用場景也有不少介紹，本文將結合作者身邊的專案例子，系統的對zk的使用場景 進行歸類介紹...
ZooKeeper的典型應用場景 資料發布 訂閱
資料發布 訂閱系統，即所謂的配置中心 發布者將資料發布到zookeeper的乙個或一系列節點上，供訂閱者進行資料訂閱，進而達到動態獲取資料的目的，實現配置資訊的集中式管理和資料的動態更新。zookeeper採用的是推拉相結合的方式 客戶端向伺服器端註冊自己需要關注的節點，一旦該服務端節點的資料發生變...
ZooKeeper典型應用場景一覽
b 資料發布與訂閱 配置中心 b 發布與訂閱模型，即所謂的配置中心，顧名思義就是發布者將資料發布到zk節點上，供訂閱者動態獲取資料，實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊，服務式服務框架的服務位址列表等就非常適合使用。應用中用到的一些配置資訊放到zk上進行集中管理。這類場景通常是這...