ZooKeeper的基礎原理及應用場景

一、ZooKeeper是什麼？

     1. 是一個爲用戶的分佈式應用程序提供協調的服務
              是爲別的分佈式程序服務的
             本身也是一個分佈式程序(只要半數以上節點存儲，就能正常提供服務)
     2.目標是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶

二、ZooKeeper的架構是什麼？

      1. 核心組件：

          Server：數目一般選擇爲奇數(3,5,7)
          Leader
          Follower
          Client

       2.架構圖：

        

三、ZooKeeperd的核心是什麼？

        仲裁機制，目錄式數據結構

      1.仲裁機制：

           ZooKeeper需要在所有的服務(可理解爲服務器)中選舉出一個Leader，然後讓這個Leader來負責管理集羣。此時，集羣中的其他服務器則成了此Leader的follower。並且，當Leader出現故障的時候，ZooKeeper要能夠快速地在Follower中選舉出下一個Leader。這就是ZooKeeper的Leader機制制（leader選舉），具體的實現方法請參考其他博客。

       2.目錄式數據結構：

            Zookeeper 會維護一個具有層次關係的數據結構，它非常類似於一個標準的文件系統，如圖 所示：

        

            Zookeeper 這種數據結構有如下這些特點(znode有兩種類型，一種臨時的(ephemeral)，一種持久的(persistent))：
                     1.每個子目錄項如 NameService 都被稱作爲 znode，這個 znode 是被它所在的路徑唯一標識，如 Server1 這個 znode 的標識爲 /NameService/Server1
                     2.znode 可以有子節點目錄，並且每個 znode 可以存儲數據，注意 EPHEMERAL 類型的目錄節點不能有子節點目錄
                     3.znode 是有版本的，每個 znode 中存儲的數據可以有多個版本，也就是一個訪問路徑中可以存儲多份數據
                     4.znode 可以是臨時節點，一旦創建這個 znode 的客戶端與服務器失去聯繫，這個 znode 也將自動刪除，Zookeeper 的客戶端和服務器通信採用長連接方式，每個客戶端和服務器通過心跳來保持連接，這個連接狀態稱爲 session，如果 znode 是臨時節點，這個 session 失效，znode 也就刪除了
                     5.znode 的目錄名可以自動編號，如 App1 已經存在，再創建的話，將會自動命名爲 App2
                     6.znode 可以被監控，包括這個目錄節點中存儲的數據的修改，子節點目錄的變化等，一旦變化可以通知設置監控的客戶端，這個是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基於這個特性實現的，後面在典型的應用場景中會有實例介紹

四、ZooKeeper的應用場景 

        1. 配置管理
             (1)在分佈式集羣中，各個節點的配置文件同步文件。對集羣中的一臺機器的配置信息修改之後，希望能夠快速同步到其他各個節點上，這可以交由ZooKeeper來實現
             (2)將配置文件信息寫入到ZooKeeper的一個znode上，各個節點監聽這個znode即可

        2.集羣管理              (1)在分佈式集羣中，各個節點的實時狀態統計              (2)將節點信息寫入到ZooKeeper的一個znode上，監聽這個znode可以獲取它的實時狀態變化              (3)Hbase中Master狀態監控和選舉