一、Zookeeper概述
Zookeeper作為Hadoop項目中的一個子項目，是Hadoop叢集管理的一個必不可少的子產品，它主要用來控制叢集中的資料，如它管理Hadoop叢集中的NameNode，還有
Hbase中Master Election、Server 之間狀态同步等。
Zoopkeeper提供了一套很好的分布式叢集管理的機制，就是它這種基于層次型的目錄樹的資料結構，并對樹中的節點進行有效管理，進而可以設計出多種多樣的分布式的資料管理模型。Zookeeper并不是用來專門存儲資料，它的作用主要是用來維護和監控你存儲的資料的狀态變化。通過監控這些資料狀态的變化，進而可以達到基于資料的叢集管理。
二、Zookeeper特性
1、結構簡單
類似于檔案系統的樹狀結構
2、單系統鏡像
無論用戶端連接配接到哪一個伺服器，他将看到相同的、Zookeeper試圖
3、有序性
有序的事務編号，用戶端的更新順序與它們被發送的順序相一緻
4、原子性
更新操作要麼成功要麼失敗，沒有第三種結果
二、Zookeeper工作原理
Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實作這個機制的協定叫做Zab協定。Zab協定有兩種模式，它們分别是恢複模式(選主)和廣播模式(同步)。當服務啟動或者在上司者崩潰後，Zab就進入了恢複模式，當上司者被選舉出來，且大多數server的完成了和leader的狀态同步以後，恢複模式就結束了。狀态同步保證了leader和server具有相同的系統狀态。
為了保證事務的順序一緻性，zookeeper采用了遞增的事務id号（zxid）來辨別事務。所有的提議（proposal）都在被提出的時候加上了zxid。實作中zxid是一個64位的數字，它高32位是epoch用來辨別leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch，辨別目前屬于那個leader的統治時期。低32位用于遞增計數。
每個Server在工作過程中有三種狀态：LOOKING：目前Server不知道leader是誰，正在搜尋LEADING：目前Server即為選舉出來的leaderfollowing：leader已經選舉出來，目前Server與之同步
三、Leader工作流程
1、Leader主要有三個功能：
a.恢複資料
b.維持與Follower的心跳，接收Follower請求并判斷Follower的請求消息類型
c.Follower的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據不同的消息類型，進行不同的處理
四、Follower工作流程
1、Follower主要有四個功能:
a、向Leader發送請求（PING消息、REQUEST消息、ACK消息、REVALIDATE息）
b、接收Leader消息并進行處理
c、接收Client的請求，如果為寫請求，發送給Leader進行投票傳回Client結果
2、Follower的消息循環處理如下幾種來自Leader的消息:
a、PING消息： 心跳消息
b、PROPOSAL消息：Leader發起的提案，要求Follower投票
c、COMMIT消息：伺服器端最新一次提案的資訊
d、UPTODATE消息：表明同步完成
e、REVALIDATE消息：根據Leader的REVALIDATE結果，關閉待revalidate的session還是允許其接受消息
f、SYNC消息：傳回SYNC結果到用戶端，這個消息最初由用戶端發起，用來強制得到最新的更新。
五、Zookeeper的目錄結構
1、每個znode的名稱都是絕對路徑名來組成的，如“/app1/p_1”等。
2、讀取或寫入znode中的資料都是原子操作，read會擷取znode中的所有位元組, write會整個替換znode中的資訊.每個znode都包含一個通路控制清單(ACL)以限制該節點的通路者和權限。
3、有些znode是臨時節點，臨時節點在建立它的session的生命周期記憶體活, 當其session終止時，此類節點将會被删除。
4、zookeeper提供znode監聽器的概念. Client可以在某個znode上設定監聽器以監聽該znode的變更. 當znode有變更時, 這些Client将會收到通知,并執行預先敲定好的函數。
六、Zookeeper的節點
1、每個節點在zookeeper中叫做znode,并且其有一個唯一的路徑辨別
2、znode有三種類型，臨時的（ EPHEMERAL ）、持久的（ PERSISTENT ）和有序的 (SEQUENTIAL)
3、znode的類型在建立時确定并且之後不能再修改znode可以包含資料和子節點，但是EPHEMERAL類型的節點不能有子節點
4、znode中的資料可以有多個版本，比如某一個路徑下存有多個資料版本，那麼查詢這個路徑下的資料就需要帶上版本
5、節點不支援部分讀寫，而是一次性完整讀寫
6、短暫znode的用戶端會話結束時，zookeeper會将該短暫znode删除，短暫znode不可以有子節點
7、持久znode不依賴于用戶端會話，隻有當用戶端明确要删除該持久znode時才會被删除
8、用戶端應用可以在節點上設定螢幕
七、觀察(watcher)
Watcher 在 zookeeper 是一個核心功能，Watcher 可以監控目錄節點的資料變化以及子目錄的變化，一旦這些狀态發生變化，伺服器就會通知所有設定在這個目錄節點上的 Watcher，進而每個用戶端都很快知道它所關注的目錄節點的狀态發生變化，而做出相應的反應
八、Zookeeper的讀寫機制
zookeeper是一個由多個server組成的叢集
一個leader，多個follower
每個server儲存一份資料副本
全局資料一緻
分布式讀寫
更新請求轉發，由leader實施
更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行
資料更新原子性，一次資料更新要麼成功，要麼失敗
全局唯一資料視圖，client無論連接配接到哪個server，資料視圖都是一緻的
實時性，在一定事件範圍内，client能讀到最新資料
九、Zookeeper的API接口
String create(String path, byte[] data, List<ACL> acl, CreateMode createMode) //建立一個節點
void delete(String path, int version) //删除一個節點
void setData(String path, byte[] data, int version) //設定一個節點的資料
Boolean exists(String path, boolean watch) //檢視一個節點的狀況，如果沒有傳回null,可注入watcher
byte[] getData(String path, boolean watch, Stat stat) //擷取一個節點的資料, 可注入watcher
List<String> getChildren(String path, boolean watch) //擷取一個節點的子節點, 可注入watcher
void addAuthInfo(String scheme, byte[] auth) //設定權限
Stat setACL(String path, List<ACL> acl, int version) //設定權限
List<ACL> getACL(String path, Stat stat) //擷取權限清單
十、配置管理
配置的管理在分布式應用環境中很常見，例如同一個應用系統需要多台 PC Server運作，但是它們運作的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那麼就必須同時修改每台運作這個應用系統的 PC Server，這樣非常麻煩而且容易出錯。
将配置資訊儲存在 Zookeeper 的某個目錄節點中，然後将所有需要修改的應用機器監控配置資訊的狀态，一旦配置資訊發生變化，每台應用機器就會收到 Zookeeper 的通知，然後從 Zookeeper 擷取新的配置資訊應用到系統中。
十一、命名服務
分布式應用中，通常需要有一套完整的命名規則，既能夠産生唯一的名稱又便于人識别和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重複。
Name Service 是 Zookeeper 内置的功能，隻要調用 Zookeeper 的 API 就能實作。