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本地搭建

　　詳情請參考：http://www.javashuo.com/article/p-gwlgsrpd-cx.html

2>.zookeeper徹底分佈式部署

　　詳情請參考：http://www.javashuo.com/article/p-uyrnfzny-cn.html

3>.zookeeper的API用法詳解

　　詳情請參考：http://www.javashuo.com/article/p-aprnjfhj-bq.html