Hadoop生態圈-Zookeeper的工作原理分析

　　　　　　　　　　　　　　　Hadoop生態圈-Zookeeper的工作原理分析

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　　作者：尹正傑

版權聲明：原創作品，謝絕轉載！否則將追究法律責任。

 

 　　無論是是Kafka集群，還是producer和consumer都依賴於Zookeeper集群保存一些mate信息，來保證系統可用性！這個特點會產生一個現象，即會產生大量的網絡IO，所以說在企業生產環境中會單獨開3到5台集群，這三台集群什么都不干，只開Zookeeper集群。所以說Zookeeper開放的節點一定要開網絡監控告警，這是一個大數據運維的基本功！

 

 

 

一.Zookeeper簡介

1>.什么是zookeeper

　　Zookeeper是一個開源的分布式的，為分布式應用提供協調服務的Apache項目。

2>.從設計模式角度來理解Zookeeper

　　zookeeper是一個基於觀察者模式設計的分布式服務管理框架，它負責存儲和管理大家都關心的數據，然后接受觀察者的注冊，一旦這些數據的狀態發生變化，Zookeeper就將負責通知已經在Zookeeper上注冊的那些觀察者做出反應，從而實現集群中類似與hadoop高可用中的active/standby管理模式。

3>.Zookeeper工作機制剖析

 

結合上圖所述，我們可以說：Zookeeper = 文件系統 + 通知機制

文件系統：
    每個Zookeeper集群中存放着每個服務器的狀態信息，雖然存儲的數據較小(每個節點默認不可超過1M)，但它也是一個文件系統，支持存儲小文件數據信息。
    
通知機制：
    服務器端和客戶端都需要在Zookeeper中注冊信息，他們負責監聽Zookeeper節點信息，一旦數據發生變化他們會做相應的動作。
    
    
Zookeeper的特點：
    1>.Zookeeper：一個領導者（leader），多個跟隨者（follower）組成的集群。
    2>.Leader負責進行投票的發起和決議，更新系統狀態。
    3>.Follower用於接收客戶請求並向客戶端返回結果，在選舉Leader過程中參與投票。
    4>.集群中只要有半數以上節點存活，Zookeeper集群就能正常服務。
    5>.全局數據一致：每個server保存一份相同的數據副本，client無論連接到哪個server，數據都是一致的。
    6>.更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行。
    7>.數據更新原子性，一次數據更新要么成功，要么失敗。
    8>.實時性，在一定時間范圍內，client能讀到最新數據。


Zookeeper的數據結構
    ZooKeeper數據模型的結構與Unix文件系統很類似，整體上可以看作是一棵樹，每個節點稱做一個ZNode。每一個ZNode默認能夠存儲1MB的數據，每個ZNode都可以通過其路徑唯一標識。

 

二.Zookeeper的應用場景

　　Zookeeper提供的服務包括：統一命名服務、統一配置管理、統一集群管理、服務器節點動態上下線、軟負載均衡等。

1>.統一命名服務

 　　在分布式環境下，經常需要對應用/服務進行統一命名，便於識別不同服務。類似於域名與IP之間對應關系，IP不容易記住，而域名容易記住。通過域名來火氣資源或服務的地址，提供者等信息。

 

2>.統一配置管理

 　　分布式環境下，配置文件管理和同步是一個常見問題。一個集群中，所有節點的配置信息是一致的，比如hadoop集群。對配置文件修改后，希望能夠快速同步到各個節點上。

 

3>.統一集群管理

 　　分布式環境中，實時掌握每個節點的狀態是必要的。可以根據節點實時狀態做出一些調整。可將節點信息寫入Zookeeper上的一個Znode，監聽這個Znode可獲得他的實時狀態變化。典型應用為HBase的Master狀態監控和選舉。

 

4>.服務器節點動態上下線

 

5>.軟負載均衡

 

三.Zookeeper內部原理

1>.選舉機制

　　在選舉leader節點時，首先會比較事務id，其次比較myid，如果集群中已經有一半機器參加選舉，那么次leader就是整個集群中的leader。

　　為了方便理解，我畫了兩幅圖，便於理解上面的一句話，當事物id一致時推選leader如下：

　　當事物id不一致時推選leader如下：

2>.Zookeeper概念知識掃描整理

一.Znode有兩種類型：
    1>.短暫（ephemeral）：客戶端和服務器端斷開連接后，創建的節點自己刪除
    2>.持久（persistent）：客戶端和服務器端斷開連接后，創建的節點不刪除

二.Znode有四種形式的目錄節點（默認是persistent ）
    1>.持久化目錄節點（PERSISTENT）
        客戶端與zookeeper斷開連接后，該節點依舊存在。
    2>.持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）
        客戶端與zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號。
    3>.臨時目錄節點（EPHEMERAL）
        客戶端與zookeeper斷開連接后，該節點被刪除。
    4>.臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）
        客戶端與zookeeper斷開連接后，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號。
 
三.創建znode時設置順序標識，znode名稱后會附加一個值，順序號是一個單調遞增的計數器，由父節點維護

四.在分布式系統中，順序號可以被用於為所有的事件進行全局排序，這樣客戶端可以通過順序號推斷事件的順序


五.stat結構體
    1>.czxid- 引起這個znode創建的zxid，創建節點的事務的zxid
        每次修改ZooKeeper狀態都會收到一個zxid形式的時間戳，也就是ZooKeeper事務ID
        事務ID是ZooKeeper中所有修改總的次序。每個修改都有唯一的zxid，如果zxid1小於zxid2，那么zxid1在zxid2之前發生
    2>.ctime - znode被創建的毫秒數(從1970年開始)
    3>.mzxid - znode最后更新的zxid
    4>.mtime - znode最后修改的毫秒數(從1970年開始)
    5>.pZxid-znode最后更新的子節點zxid
    6>.cversion - znode子節點變化號，znode子節點修改次數
    7>.dataversion - znode數據變化號
    8>.aclVersion - znode訪問控制列表的變化號
    9>.ephemeralOwner- 如果是臨時節點，這個是znode擁有者的session id。如果不是臨時節點則是0
    10>.dataLength- znode的數據長度
    11>.numChildren - znode子節點數量

3>.監聽器原理

 

如上圖所示，Zookeeper監聽器原理詳解：
    1>.首先由一個main()線程;
    2>.在main線程中創建Zookeeper客戶端，這時就會創建兩個線程，一個負責網絡鏈接通信(connet)，一個負責監聽(linster);
    3>.通過connect線程將注冊的監聽事件發送給Zookeeper;
    4>.在Zookeeper的注冊監聽器中將注冊的監聽事件添加到列表中;
    5>.Zookeeper監聽到有數據或路徑變化，就會將這個消息發送給listener線程;
    6>.listener線程內部調用了process()方法;
    
常見的監聽:
    1>.監聽節點數據的變化 get path    [watch]
    2>.監聽子節點增減的變化 ls path    [watch]

4>.寫數據流程

 

 

四.部署Zookeeper

1>.zookeeper本地搭建

　　詳情請參考：https://www.cnblogs.com/yinzhengjie/p/9103008.html

2>.zookeeper完全分布式部署

　　詳情請參考：https://www.cnblogs.com/yinzhengjie/p/9154265.html

3>.zookeeper的API用法詳解

　　詳情請參考：https://www.cnblogs.com/yinzhengjie/p/9154283.html