（一）、ZooKeeper介紹

ZooKeeper介紹

       ZooKeeper是一個開源的分佈式服務框架，它是ApacheHadoop項目的一個子項目，主要用來解決分佈式應用場景中存在的一些問題，如：統一命名服務、狀態同步服務、集羣管理、分佈式應用配置管理等，它支持Standalone模式和分佈式模式，在分佈式模式下，能夠爲分佈式應用提供高性能和可靠地協調服務，而且使用ZooKeeper可以大大簡化分佈式協調服務的實現，爲開發分佈式應用極大地降低了成本。

      ZooKeeper對分佈式開發帶來很多便利，利用ZK的獨有特性巧妙地解決了很多難題，很多分佈式技術用到ZooKeeper或多或少特性，尤其是新生代分佈式技術幾乎都會依賴ZooKeeper特性，如HBase、火爆的Storm。

• ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。
• ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
• ZooKeeper包含一個簡單的原語集，提供Java和C的接口。
• ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口，代碼在zookeeper-3.4.3\src\recipes。其中分佈鎖和隊列有Java和C兩個版本，選舉只有Java版本。

ZooKeeper應用場景

集羣管理

• Storm集羣：ZooKeeper作爲nimbus（master）和supervisor（slave）的中間樞紐，保存Storm集羣和作業的所有信息，並肩負nimbus和supervisor的全部通信。
• HBase集羣：HBase集羣：ZooKeeper作爲“協調器”，爲HBase提供穩定服務和failover機制，HRegionServer也會把自己作爲以Ephemeral方式註冊到ZooKeeper中，使得HMaster可以隨時感知到各個HRegionServer的健康狀態（可用於監控RegionServer）。此外，ZooKeeper也避免了HMaster的單點問題。

應用三大塊：

• Storm應用開發，Storm集羣監控
• MapReduce應用開發
• HBase開發

分佈式配置管理

   發佈和訂閱即所謂的配置管理，顧名思義就是將數據發佈到ZK節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如：全局的配置信息，地址列表等就非常適合使用。

   配置的管理在分佈式應用環境中很常見，例如同一個應用系統需要多臺PC Server運行，但是它們運行的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那麼就必須同時修改每臺運行這個應用系統的PC Server ，這樣非常麻煩而且容易出錯。像 這樣的配置信息完全可以交給 ZooKeeper 來管理，將配置信保存在ZooKeeper 的某個目錄節點中，然後將所有需要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每臺應用機器就會收到 ZooKeeper 的通知，然後從 ZooKeeper 獲取新的配置信息應用到系統中。

  

統一命名服務

       Name Service:這個主要是作爲分佈式命名服務，通過調用ZK的Create Node API,能夠和容易的創建一個全局的Path，這個Path就可以作爲一個名稱。 

      分佈式應用中，通常需要有一套完整的命名規則，既能夠產生唯一的名稱又便於人識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重複。說到這裏你可能想到了 JNDI，沒錯 Zookeeper 的 Name Service 與 JNDI 能夠完成的功能是差不多的，它們都是將有層次的目錄結構關聯到一定資源上，但是 Zookeeper 的 Name Service 更加是廣泛意義上的關聯，也許你並不需要將名稱關聯到特定資源上，你可能只需要一個不會重複名稱，就像數據庫中產生一個唯一的數字主鍵一樣。

分佈式通知\協調

        ZooKeeper中特有Watcher註冊與異步通知機制，能夠很好的實現分佈式環境下不同系統之間的通知協調，實現對數據變更的實時處理。處理方法通常是不同系統對應ZK上的一個ZNode進行註冊，監聽ZNode的變化（包括ZNode本身內容以及子節點的），其中有個系統Update了ZNode，那麼另外一個系統就能夠收到通知，並做相應處理。  

分佈式鎖

      分佈式鎖，這個主要得益於ZooKeeper爲我們保證了數據的強一致性，即用戶只要完全相信每時每刻，ZK集羣中任意節點（一個ZK Server）上的相同ZNode的數據是一定相同的。鎖服務可以分爲兩類，一個保持獨佔，另一個控制時序。

     共享鎖在同一個進程中很容易實現，但是在跨進程或者在不同 Server 之間就不好實現了。Zookeeper 卻很容易實現這個功能，實現方式也是需要獲得鎖的 Server 創建一個 EPHEMERAL_SEQUENTIAL 目錄節點，然後調用 getChildren方法獲取當前的目錄節點列表中最小的目錄節點是不是就是自己創建的目錄節點，如果正是自己創建的，那麼它就獲得了這個鎖，如果不是那麼它就調用 exists(String path, boolean watch) 方法並監控 Zookeeper 上目錄節點列表的變化，一直到自己創建的節點是列表中最小編號的目錄節點，從而獲得鎖，釋放鎖很簡單，只要刪除前面它自己所創建的目錄節點就行了。

分佈式隊列

      隊列方面，一種常規的先進先出隊列，另一種等到隊列成員聚集之後才統一順序執行。
      對於第二種先進先出隊列，增加分佈式鎖以控制時序場景。

      同步隊列用 Zookeeper 實現的實現思路如下：
      創建一個父目錄 /synchronizing，每個成員都監控標誌（Set Watch）位目錄 /synchronizing/start 是否存在，然後每個成員都加入這個隊列，加入隊列的方式就是創建 /synchronizing/member_i 的臨時目錄節點，然後每個成員獲取 / synchronizing 目錄的所有目錄節點，也就是 member_i。判斷 i 的值是否已經是成員的個數，如果小於成員個數等待 /synchronizing/start 的出現，如果已經相等就創建 /synchronizing/start。