zookeeper工做原理以及基礎概念

  ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：數據發佈/發佈、負載均衡、配置維護、域名服務、分佈式同步、組服務等。而咱們爲什麼選擇zookeeper，由於Zookeeper具備如下特性：

特色	說明
最終一致性	爲客戶端展現同一個視圖，這是zookeeper裏面一個很是重要的功能
可靠性	若是消息被到一臺服務器接受，那麼它將被全部的服務器接受。
實時性	Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口
獨立性	各個Client之間互不干預
原子性	更新只能成功或者失敗，沒有中間狀態。
順序性	全部Server，同一消息發佈順序一致。

1.zookeeper設計目標

 Zookeeper致力於提供一個高性能、高可用、且具備嚴格的順序訪問控制能力（主要是寫操做的嚴格順序性）的分佈式協調服務，其具備以下的設計目標：

1. 簡單的數據模型，Zookeeper使得分佈式程序可以經過一個共享的樹形結構的名字空間來進行相互協調，即Zookeeper服務器內存中的數據模型由一系列被稱爲ZNode的數據節點組成，Zookeeper將全量的數據存儲在內存中，以此來提升服務器吞吐、減小延遲的目的。
2. 可構建集羣，一個Zookeeper集羣一般由一組機器構成，組成Zookeeper集羣的而每臺機器都會在內存中維護當前服務器狀態，而且每臺機器之間都相互通訊。
3. 順序訪問，對於來自客戶端的每一個更新請求，Zookeeper都會分配一個全局惟一的遞增編號，這個編號反映了全部事務操做的前後順序。
4. 高性能，Zookeeper將全量數據存儲在內存中，並直接服務於客戶端的全部非事務請求，所以它尤爲適用於以讀操做爲主的應用場景。

2.zookeeper架構圖

zookeeper角色：

角色	描述
leader	負責進行投票的發起和決議以及更新系統狀態
learner	包括跟隨者（follower）和觀察者（observer），follower用於接受客戶端請求並想客戶端返回結果，在選主過程當中參與投票.Observer能夠接受客戶端鏈接，將寫請求轉發給leader，但observer不參加投票過程，只同步leader的狀態，observer的目的是爲了擴展系統，提升讀取速度
client	請求發起方

其中每一個Server在工做過程當中有三種狀態：

1. LOOKING：當前Server不知道leader是誰，正在搜尋
2. LEADING：當前Server即爲選舉出來的leader
3. FOLLOWING：leader已經選舉出來，當前Server與之同步

那如何選舉server leader呢？
半數經過 ，奇數選舉
– 3臺機器 掛一臺 2>3/2
– 4臺機器 掛2臺 2！>4/2
具體選舉流程：
» 每一個Server啓動之後都詢問其它的Server它要投票給誰。
» 對於其餘server的詢問，server每次根據本身的狀態都回複本身推薦的leader的id和上一次處理事務的zxid（系統啓動時每一個server都會推薦本身）
» 收到全部Server回覆之後，就計算出zxid最大的哪一個Server，並將這個Server相關信息設置成下一次要投票的Server。
» 計算這過程當中得到票數最多的的sever爲獲勝者，若是獲勝者的票數超過半數，則改server被選爲leader。不然，繼續這個過程，直到leader被選舉出來 » leader就會開始等待server鏈接
» Follower鏈接leader，將最大的zxid發送給leader
» Leader根據follower的zxid肯定同步點
» 完成同步後通知follower 已經成爲uptodate狀態
» Follower收到uptodate消息後，又能夠從新接受client的請求進行服務了

3.zookeeper工做原理

  Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步，實現這個機制的協議叫作Zab協議。 Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和server具備相同的系統狀態。
  一旦leader已經和多數的follower進行了狀態同步後，他就能夠開始廣播消息了，即進入廣播狀態。這時候當一個server加入zookeeper服務中，它會在恢復模式下啓動，發現leader，並和leader進行狀態同步。待到同步結束，它也參與消息廣播。 Zookeeper服務一直維持在Broadcast狀態，直到leader崩潰了或者leader失去了大部分的followers支持。
  廣播模式須要保證proposal被按順序處理，所以zk採用了遞增的事務id號(zxid)來保證。全部的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64爲的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。
   當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的server都恢復到一個正確的狀態。

4.Zookeeper的數據模型

»層次化的目錄結構，命名符合常規文件系統規範
» 每一個節點在zookeeper中叫作znode,而且其有一個惟一的路徑標識
» 節點Znode能夠包含數據和子節點，可是EPHEMERAL類型的節點不能有子節點
» Znode中的數據能夠有多個版本，好比某一個路徑下存有多個數據版本，那麼查詢這個路徑下的數據就須要帶上版本
» 客戶端應用能夠在節點上設置監視器
» 節點不支持部分讀寫，而是一次性完整讀寫

5.Zookeeper的節點

» Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）

» Znode的類型在建立時肯定而且以後不能再修改

» 短暫znode的客戶端會話結束Zookeeper的保證時，zookeeper會將該短暫znode刪除，短暫znode不能夠有子節點

» 持久znode不依賴於客戶端會話，只有當客戶端明確要刪除該持久znode時纔會被刪除

» Znode有四種形式的目錄節點

1. PERSISTENT、
2. EPHEMERAL
3. PERSISTENT_SEQUENTIAL、
4. EPHEMERAL_SEQUENTIAL

6.Zookeeper的保證

» 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行
» 數據更新原子性，一次數據更新要麼成功，要麼失敗
» 全局惟一數據視圖，client不管鏈接到哪一個server，數據視圖都是一致的
» 實時性，在必定事件範圍內，client能讀到最新數據

7.ACL

Zookeeper採用ACL（Access Control Lists）策略來進行權限控制，其定義了以下五種權限：

 · CREATE：建立子節點的權限。

 · READ：獲取節點數據和子節點列表的權限。

 · WRITE：更新節點數據的權限。

 · DELETE：刪除子節點的權限。

 · ADMIN：設置節點ACL的權限。

歡迎轉載，標明出處！！