zookeeper 實際使用場景舉例

   本人所在的項目組，目前在兩個地方使用到了zookeeper，分別是

     1.按期理財平臺：理財涉及到一個額度的問題，不一樣的渠道（如網站、手機、微信等）使用的是同一個額度，須要確保每一個渠道看到的都是同一個額度。所採起的方式就是在產品後臺數據庫維護產品的實時額度，而後經過zookeeper推送給不一樣的渠道。

     2.線上房貸平臺：這裏主要是用zookeeper進行樓盤信息的推送。後臺管理人員在後臺管理系統進行樓盤信息的編輯，全部的編輯以後的信息，再經過zookeeper推送到不一樣的平臺進行展現。

 

     另外收集了一些國際國內的典型應用，供你們參考：

     1. metaq：MetaQ（全稱Metamorphosis）是一個高性能、高可用、可擴展的分佈式消息中間件，思路起源於LinkedIn的Kafka，但並非Kafka的一個Copy。MetaQ具備消息存儲順序寫、吞吐量大和支持本地和XA事務等特性，適用於大吞吐量、順序消息、廣播和日誌數據傳輸等場景，目前在淘寶和支付寶有着普遍的應用。 metaq發送消息的時候，生產者在發送消息的時候必須選擇一臺broker上的一個分區來發送消息，所以metaq在運行過程當中，會把全部broker和對應的分區信息所有註冊到ZK指定節點上，默認的策略是一個依次輪詢的過程，生產者在經過ZK獲取分區列表以後，會按照brokerId和partition的順序排列組織成一個有序的分區列表，發送的時候按照從頭至尾循環往復的方式選擇一個分區來發送消息。消費負載均衡：在消費過程當中，一個消費者會消費一個或多個分區中的消息，可是一個分區只會由一個消費者來消費。MetaQ的消費策略是：

      每一個分區針對同一個group只掛載一個消費者。

      若是同一個group的消費者數目大於分區數目，則多出來的消費者將不參與消費。

      若是同一個group的消費者數目小於分區數目，則有部分消費者須要額外承擔消費任務。

在某個消費者故障或者重啓等狀況下，其餘消費者會感知到這一變化（經過 zookeeper watch消費者列表），而後從新進行負載均衡，保證全部的分區都有消費者進行消費。

     2. Dubbo：阿里巴巴集團開源的分佈式服務框架Dubbo中使用ZooKeeper來做爲其命名服務，維護全局的服務地址列表。在Dubbo實現中：

     服務提供者在啓動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入本身的URL地址，這個操做就完成了服務的發佈。

     服務消費者啓動的時候，訂閱/dubbo/${serviceName}/providers目錄下的提供者URL地址， 並向/dubbo/${serviceName} /consumers目錄下寫入本身的URL地址。

     注意，全部向ZK上註冊的地址都是臨時節點，這樣就可以保證服務提供者和消費者可以自動感應資源的變化。

     另外，Dubbo還有針對服務粒度的監控，方法是訂閱/dubbo/${serviceName}目錄下全部提供者和消費者的信息。

     3. Apache HBase：Hbase是一個一般與Hadoop一塊兒使用的數據倉庫。在Hbase中，zookeeper用於選舉一個集羣內的主節點，以便跟蹤可用的服務器，並保存集羣的元數據。