Zookeeper簡介

Zookeeper是一個開源的分佈式協調服務，它是集羣的管理者，監視着集羣中各個節點的狀態。根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效，功能穩定的系統提供給用戶。

分佈式應用程序可基於Zookeeper實現諸如數據發佈/訂閱，負載均衡，命名服務，分佈式協調/通知，集羣管理，Master選舉，分佈式鎖和分佈式隊列等功能

客戶端的讀請求可以被集羣中的任意一臺機器處理，如果讀請求在節點上註冊了監聽器，這個監聽器也是由所連接的zookeeper機器來處理。對於寫請求，這些請求會同時發給其他zookeeper機器並且達成一致後，請求才會返回成功。因此，隨着zookeeper的集羣機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。

有序性是zookeeper中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱爲zxid（Zookeeper Transaction Id）。而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid。

1.Zookeeper角色

Zookeeper 集羣是一個基於主從複製的高可用集羣，每個服務器承擔如下三種角色中的一種

1>Leader

一個Zookeeper集羣同一時間只會有一個實際工作的Leader，它會發起並維護與各個Follower及Observer間的心跳
所有的寫操作必須要通過Leader完成，再由Leader將寫操作廣播給其他服務器。只要有超過半數節點（不包括Observer節點）寫入成功，該寫請求就會被提交

2>Follower

一個Zookeeper集羣中可能同時存在多個Follower，它會響應Leader的心跳
Follower可直接處理並返回客戶端的讀請求，同時會將寫請求轉發給Leader處理
並且在Leader處理寫請求時對請求進行投票

3>Observer

角色與Follower相似，但沒有投票權。Zookeeper需保證高可用和強一致性，爲了支持更多的客戶端，需要增加更多Server；Server增多，投票階段延遲增大，影響性能；引入Observer節點，Observer不參與投票；Observer接受客戶端的連接，並將寫請求轉發給Leader節點；加入更多Observer節點，提高伸縮性，同時不影響吞吐率。

2.ZAB協議

事務編號zxid（事務請求計數器+epoch）：
在ZAB（Zookeeper Atomic Broadcast，ZooKeeper原子廣播協議）協議的事務編號zxid的設計中，zxid是一個64位的數字，其中低32位是一個簡單的單調遞增的計數器，針對客戶端每一個事務請求，計數器+1；而高32位代表Leader週期epoch編號，每當選舉產生一個新的Leader服務器，就會從這個Leader服務器上取出其本地日誌最大的zxid，並從中讀取epoch值，然後+1，以此作爲新的epoch，並將低32位從0開始計數。
zxid，用於標識一次更新操作的Proposal（提議ID）。爲了保證順序性，該zxid必須單調遞增

ZAB協議有兩種模式：恢復模式（選主），廣播模式（同步）：
當服務啓動或者Leader宕機後，ZAB就進入了恢復模式；當Leader被選舉出來，且絕大多數Server完成了和Leader的狀態同步後，恢復模式就結束了。狀態同步保證了Server和Leader具有相同的系統狀態

ZAB協議4階段：

1.Leader Election（選舉階段，選出準Leader）
節點在一開始都處於選舉階段，只要有一個節點得到超過半數節點的票數，它就可以當選準Leader。只有到達廣播階段（Broadcast），準Leader纔會成爲真正的Leader。
2.Discovery（發現階段，生成epoch，接受epoch）
在這個階段，Followers與準Leader進行通信，同步Followers最近接收的事務提議。這一個階段的主要目的是發現當前大多數節點接收的最新提議，並且準Leader生成新的epoch，讓Followers接受，更新它們的accepted Epoch。
一個Follower只會連接一個Leader，如果一個節點f任務另一個Follower p是Leader，f在嘗試連接p時會被拒絕，f被拒絕之後就會進入重新選舉階段
3.Synchronization（同步階段，同步Follower副本）
同步階段主要是利用Leader前一階段獲得的最新提議歷史，同步集羣中所有的副本。只有當大多數節點都同步完成，準Leader纔會成爲真正的Leader。Follower只接受zxid比自己的lastZxid大的提議
4.Broadcast（廣播階段，Leader消息廣播）
到了這個階段，Zookeeper集羣才能正式對外提供事務服務，並且Leader可以進行事務廣播。同時如果有新的節點加入，還需要對新節點進行同步

ZAB提交事務不像2PC一樣需要全部Follower都ACK，只需要得到超過半數節點的ACK就可以了

ZAB協議的JAVA實現（發現階段和同步階段合併成恢復階段），所以ZAB的實現只有三個階段：Fast Leader Election；Recovery Phase；Broadcast Phase

3.投票機制

每個Server首先給自己投票，然後用自己的選票和其他Server對比，權重大的勝出，使用權重更大的更新自身選票箱，具體選舉過程如下：

1.每個Server啓動後都詢問其他的Server投票給誰。對於其他Server的詢問，Server每次根據自己的狀態都回復自己推薦的Leader的id和上一次處理事務的zxid（系統啓動時每個Server會推薦自己）
2.收到所有Server回覆以後，就計算出zxid最大的那個Server，並將這個Server相關信息設置成下一次要投票的Server
3.計算這過程中獲得選票最大的Server爲獲勝者，如果獲勝者的票數超過半數，則改Server爲Leader。否則繼續這個過程，直到Leader被選舉出來。
4.Leader會開始等待Server連接
5.Follower連接Leader，將最大的zxid發送給Leader
6.Leader根據Follower的zxid確定同步點，至此選舉階段完成
7.選舉階段完成Leader同步後通知Follower已經成爲Update狀態
8.Follower收到Update消息後，又可以重新接受Client的請求進行服務了

例子：

4.Zookeeper文件系統

Zookeeper的命名空間就是Zookeeper應用的文件系統，它和Linux文件系統很像，也是樹狀，這樣就可以確定每個路徑都是唯一的。對於命名空間的操作必須都是絕對路徑。但Linux文件系統有目錄和文件的區別，而Zookeeper統一叫znode，一個znode既可以包含子znode，也可以包含數據，但只能存儲小於1M的數據。

znode在類型上分爲4種：

PERSISTENT：持久的節點。
EPHEMERAL：暫時的節點。
PERSISTENT_SEQUENTIAL：持久化順序編號目錄節點。
EPHEMERAL_SEQUENTIAL：暫時化順序編號目錄節點。

相關命令：

//1.查看目錄(指定znode下的子znode)
ls /

//2.查看目錄內容(znode種存儲的數據)
get /config

//3.創建znode
create /config/test abc

delete path [version] #刪除目錄，但是隻能刪除沒有子目錄的
rmr path # 什麼都可以刪除
get path [watch] # 獲取信息
create [-s] [-e] path data acl # 創建目錄
quit # 退出當前的shell

Zookeeper簡介