zookeeper是乙個高可用的分布式資料管理與系統協調框架。基於對paxos演算法的實現，使該框架保證了分布式環境中資料的強一致性，也正是基於這樣的特性，使得zookeeper能夠應用於很多場景。網上對zk的使用場景也有不少介紹，本文將結合作者身邊的專案例子，系統的對zk的使用場景進行歸類介紹。 值得注意的是，zk並不是生來就為這些場景設計，都是後來眾多開發者根據框架的特性，摸索出來的典型使用方法。因此，也非常歡迎你分享你在zk使用上的奇技淫巧。
場景類別典型場景描述（zk特性，使用方法）應用中的具體使用
資料發布與訂閱發布與訂閱即所謂的配置管理，顧名思義就是將資料發布到zk節點上，供訂閱者動態獲取資料，實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊，位址列表等就非常適合使用。
1. 索引資訊和集群中機器節點狀態存放在zk的一些指定節點，供各個客戶端訂閱使用。2. 系統日誌（經過處理後的）儲存，這些日誌通常2-3天後被清除。
3. 應用中用到的一些配置資訊集中管理，在應用啟動的時候主動來獲取一次，並且在節點上註冊乙個watcher，以後每次配置有更新，實時通知到應用，獲取最新配置資訊。
4. 業務邏輯中需要用到的一些全域性變數，比如一些訊息中介軟體的訊息佇列通常有個offset，這個offset存放在zk上，這樣集群中每個傳送者都能知道當前的傳送進度。
5. 系統中有些資訊需要動態獲取，並且還會存在人工手動去修改這個資訊。以前通常是暴露出介面，例如jmx介面，有了zk後，只要將這些資訊存放到zk節點上即可。
name service這個主要是作為分布式命名服務，通過呼叫zk的create node api，能夠很容易建立乙個全域性唯一的path，這個path就可以作為乙個名稱。
分布通知/協調zookeeper中特有watcher註冊與非同步通知機制，能夠很好的實現分布式環境下不同系統之間的通知與協調，實現對資料變更的實時處理。使用方法通常是不同系統都對zk上同乙個znode進行註冊，監聽znode的變化（包括znode本身內容及子節點的），其中乙個系統update了znode，那麼另乙個系統能夠收到通知，並作出相應處理。
1. 另一種心跳檢測機制：檢測系統和被檢測系統之間並不直接關聯起來，而是通過zk上某個節點關聯，大大減少系統耦合。2. 另一種系統排程模式：某系統有控制台和推送系統兩部分組成，控制台的職責是控制推送系統進行相應的推送工作。管理人員在控制台作的一些操作，實際上是修改了zk上某些節點的狀態，而zk就把這些變化通知給他們註冊watcher的客戶端，即推送系統，於是，作出相應的推送任務。
3. 另一種工作匯報模式：一些類似於任務分發系統，子任務啟動後，到zk來註冊乙個臨時節點，並且定時將自己的進度進行匯報（將進度寫回這個臨時節點），這樣任務管理者就能夠實時知道任務進度。
總之，使用zookeeper來進行分布式通知和協調能夠大大降低系統之間的耦合。
分布式鎖分布式鎖，這個主要得益於zookeeper為我們保證了資料的強一致性，即使用者只要完全相信每時每刻，zk集群中任意節點（乙個zk server）上的相同znode的資料是一定是相同的。鎖服務可以分為兩類，乙個是保持獨佔，另乙個是控制時序。
所謂保持獨佔，就是所有試圖來獲取這個鎖的客戶端，最終只有乙個可以成功獲得這把鎖。通常的做法是把zk上的乙個znode看作是一把鎖，通過create znode的方式來實現。所有客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。
控制時序，就是所有檢視來獲取這個鎖的客戶端，最終都是會被安排執行，只是有個全域性時序了。做法和上面基本類似，只是這裡 /distribute_lock 已經預先存在，客戶端在它下面建立臨時有序節點（這個可以通過節點的屬性控制：createmode.ephemeral_sequential來指定）。zk的父節點（/distribute_lock）維持乙份sequence,保證子節點建立的時序性，從而也形成了每個客戶端的全域性時序。
集群管理利用zookeeper有兩個特性，就可以實時另一種集群機器存活性監控系統：a. 客戶端在節點 x 上註冊乙個watcher，那麼如果 x 的子節點變化了，會通知該客戶端。b. 建立ephemeral型別的節點，一旦客戶端和伺服器的會話結束或過期，那麼該節點就會消失。
例如，監控系統在 /clusterservers 節點上註冊乙個watcher，以後每動態加機器，那麼就往 /clusterservers 下建立乙個 ephemeral型別的節點：/clusterservers/. 這樣，監控系統就能夠實時知道機器的增減情況，至於後續處理就是監控系統的業務了。
2.master選舉則是zookeeper中最為經典的使用場景了。
在分布式環境中，相同的業務應用分布在不同的機器上，有些業務邏輯（例如一些耗時的計算，網路i/o處理），往往只需要讓整個集群中的某一台機器進行執行，其餘機器可以共享這個結果，這樣可以大大減少重複勞動，提高效能，於是這個master選舉便是這種場景下的碰到的主要問題。
利用zookeeper的強一致性，能夠保證在分布式高併發情況下節點建立的全域性唯一性，即：同時有多個客戶端請求建立 /currentmaster 節點，最終一定只有乙個客戶端請求能夠建立成功。
利用這個特性，就能很輕易的在分布式環境中進行集群選取了。
另外，這種場景演化一下，就是動態master選舉。這就要用到 ephemeral_sequential型別節點的特性了。
上文中提到，所有客戶端建立請求，最終只有乙個能夠建立成功。在這裡稍微變化下，就是允許所有請求都能夠建立成功，但是得有個建立順序，於是所有的請求最終在zk上建立結果的一種可能情況是這樣： /currentmaster/-1 , /currentmaster/-2 , /currentmaster/-3 ….. 每次選取序列號最小的那個機器作為master，如果這個機器掛了，由於他建立的節點會馬上小時，那麼之後最小的那個機器就是master了。
分布式佇列佇列方面，我目前感覺有兩種，一種是常規的先進先出佇列，另一種是要等到佇列成員聚齊之後的才統一按序執行。對於第二種先進先出佇列，和分布式鎖服務中的控制時序場景基本原理一致，這裡不再贅述。
第二種佇列其實是在fifo佇列的基礎上作了乙個增強。通常可以在 /queue 這個znode下預先建立乙個/queue/num 節點，並且賦值為n（或者直接給/queue賦值n），表示佇列大小，之後每次有佇列成員加入後，就判斷下是否已經到達佇列大小，決定是否可以開始執行了。這種用法的典型場景是，分布式環境中，乙個大任務task a，需要在很多子任務完成（或條件就緒）情況下才能進行。這個時候，凡是其中乙個子任務完成（就緒），那麼就去 /tasklist 下建立自己的臨時時序節點（createmode.ephemeral_sequential），當 /tasklist 發現自己下面的子節點滿足指定個數，就可以進行下一步按序進行處理了。
Zookeeper應用場景
分布式佇列 fifo 先進先出 barrier 同步佇列 共享鎖集群管理 leader選舉 命名服務 分布式應用配置項的管理等 fifo設計思路 1.在 queue fifo的目錄下建立 sequential 型別的子目錄 x i 這樣就能保證所有成員加入佇列時都是有編號的。2.出佇列時通過 get...
Zookeeper應用場景
zookeeper 分布式服務框架是 apache hadoop 的乙個子專案，主要是用來解決分布式應用中經常遇到的一些資料管理問題。如 集群管理 統一命名服務 分布式配置管理 分布式訊息佇列 分布 式鎖 分布式通知協調等。越來越多的分布式計算開始強依賴zk，比如storm hbase zookee...
ZooKeeper典型應用場景
zookeeper 是乙個開源的高可用的分布式資料管理與系統協調框架，基於對 paxos 演算法的實現，保證了分布式環境中資料的強一致性。發布與訂閱模型 發布者發布資料到 zk 節點上，供訂閱者動態獲取資料。在資料量很少，但是資料更新快的場景下 訊息中介軟體中的發布者和訂閱者的負載均衡，linked...