zookeeper

zookeeper

使用場景

• Zookeeper做爲一個分佈式協調系統提供了一項基本服務：分佈式鎖服務，分佈式鎖是分佈式協調技術實現的核心內容。像配置管理、任務分發、組服務、分佈式消息隊列、分佈式通知/協調等，這些應用實際上都是基於這項基礎服務由用戶本身摸索出來的。
• 數據發佈與訂閱實現配置管理：發佈與訂閱即所謂的配置管理，顧名思義就是將數據發佈到zk節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如全局的配置信息，地址列表等就很是適合使用。
• NameService：做爲分佈式命名服務，經過調用zk的create node api，可以很容易建立一個全局惟一的path，這個path就能夠做爲一個名稱。
• 分佈通知/協調：ZooKeeper 中特有watcher註冊與異步通知機制，可以很好的實現分佈式環境下不一樣系統之間的通知與協調，實現對數據變動的實時處理。使用方法一般是不一樣系統都對 ZK上同一個znode進行註冊，監聽znode的變化（包括znode自己內容及子節點的），其中一個系統update了znode，那麼另外一個系統能 夠收到通知，並做出相應處理。使用zookeeper來進行分佈式通知和協調可以大大下降系統之間的耦合。
• 分佈式鎖：主要得益於ZooKeeper爲咱們保證了數據的強一致性，即用戶只要徹底相信每時每刻，zk集羣中任意節點（一個zk server）上的相同znode的數據是必定是相同的。鎖服務能夠分爲兩類，一個是保持獨佔，另外一個是控制時序。控制時序中Zk的父節點（/distribute_lock）維持一份sequence,保證子節點建立的時序性，從而也造成了每一個客戶端的全局時序。

數據結構

• ZooKeeper命名空間中的Znode，兼具文件和目錄兩種特色。既像文件同樣維護着數據、元信息、ACL、時間戳等數據結構，又像目錄同樣能夠做爲路徑標識的一部分。
• 每一個Znode由3部分組成:
  • stat狀態信息：描述該Znode的版本, 權限等信息
  • data：與該Znode關聯的數據(配置文件信息、狀態信息、聚集位置)，數據大小至多1M
  • children：該Znode下的子節點
• ZooKeeper中的每一個節點存儲的數據要被原子性的操做。也就是說讀操做將獲取與節點相關的全部數據，寫操做也將替換掉節點的全部數據。
• 另外，每個節點都擁有本身的ACL(訪問控制列表)，這個列表規定了用戶的權限，即限定了特定用戶對目標節點能夠執行的操做。

watch機制

• ZooKeeper能夠爲全部的讀操做設置watch，包括：exists()、getChildren()及getData()。數據watch(data watches)：getData和exists負責設置數據watch,孩子watch(child watches)：getChildren負責設置孩子watch
• 當節點狀態發生改變時(Znode的增、刪、改)將會觸發watch所對應的操做。當watch被觸發時，ZooKeeper將會向客戶端發送且僅發送一條通知，由於watch只能被觸發一次，這樣能夠減小網絡流量。

節點類型

• ZooKeeper中的節點有兩種，分別爲臨時節點和永久節點(還可再分爲有序無序)。
• 節點的類型在建立時即被肯定，而且不能改變。
• 臨時節點：該節點的生命週期依賴於建立它們的會話。一旦會話(Session)結束，臨時節點將被自動刪除，固然能夠也能夠手動刪除。雖然每一個臨時的Znode都會綁定到一個客戶端會話，但他們對全部的客戶端仍是可見的。另外，ZooKeeper的臨時節點不容許擁有子節點。（分佈式隊列）
• 永久節點：該節點的生命週期不依賴於會話，而且只有在客戶端顯示執行刪除操做的時候，他們才能被刪除。

zookeeper 架構

• 當集羣節點數目逐漸增大爲了支持更多的客戶端，須要增長更多Server，然而Server增多，投票階段延遲增大，影響性能。爲了權衡伸縮性和高吞吐率，引入Observer：
• 每一個Server在工做過程當中有三種狀態
  • LOOKING：當前Server不知道leader是誰，正在搜尋。
  • LEADING：當前Server即爲選舉出來的leader。

  • FOLLOWING：leader已經選舉出來，當前Server與之同步。

    zookeeper工做原理

• 爲了保證各個Server之間的同步， Zookeeper的核心是採用原子廣播，實現這個原子廣播的協議叫作Zab協議。
• 狀態同步保證了leader和Server具備相同的系統狀態。
• Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）

zab何時會進入恢復模式

• 當整個服務框架在啓動過程當中
• 當Leader服務器出現網絡中斷崩潰退出與重啓等異常狀況
• 當有新的服務器加入到集羣中且集羣處於正常狀態（廣播模式），新服會與leader進行數據同步，而後進入消息廣播模式

zab恢復模式幹了什麼

• 選舉產生新的Leader服務器，同時集羣中已有的過半的機器會與該Leader完成狀態同步，這些工做完成後，ZAB協議就會退出崩潰恢復模式

zab恢復模式選主過程

• 當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式須要從新選舉出一個新的leader，讓全部的 Server都恢復到一個正確的狀態。
• Zk的選舉算法有兩種：一種是基於basic paxos實現的，另一種是基於fast paxos算法實現的。系統默認的選舉算法爲fast paxos。
• Basic paxos：當前Server發起選舉的線程,向全部Server發起詢問,選舉線程收到全部回覆,計算zxid最大Server,並推薦此爲leader，若此提議得到n/2+1票經過,此爲leader，不然重複上述流程，直到leader選出。

• Fast paxos:某Server首先向全部Server提議本身要成爲leader，當其它Server收到提議之後，解決epoch和 zxid的衝突，並接受對方的提議，而後向對方發送接受提議完成的消息，重複這個流程，最後必定能選舉出Leader。(即提議方解決其餘全部epoch和 zxid的衝突,即爲leader)。

  zk讀寫

• 同步流程

• （1）Leader等待server鏈接；
• （2）Follower鏈接leader，將最大的zxid發送給leader；
• （3）Leader根據follower的zxid肯定同步點，完成同步後通知follower 已經成爲uptodate狀態；
• （4）Follower收到uptodate消息後，又能夠從新接受client的請求進行服務了

同步過程當中的事務

• 爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。全部的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。

何時進入廣播模式

• 集羣狀態穩定，有了leader且過半機器狀態同步完成，退出崩潰恢復模式後進入消息廣播模式

  廣播模式幹了什麼

• 正常的消息同步，把平常產生數據從leader同步到learner的過程

zk四字操做命令

• nc爲netcat命令的簡寫

echo stat | nc localhost 2181

conf: 輸出相關服務配置的詳細信息。
cons: 列出全部鏈接到服務器的客戶端的徹底的鏈接 / 會話的詳細信息。包括「接受 / 發送」的包數量、會話 id 、操做延遲、最後的操做執行等等信息。
dump: 列出未經處理的會話和臨時節點。
envi: 輸出關於服務環境的詳細信息（區別於 conf 命令）。
reqs: 列出未經處理的請求
ruok: 測試服務是否處於正確狀態。若是確實如此，那麼服務返回「 imok 」，不然不作任何相應。
stat: 輸出關於性能和鏈接的客戶端的列表。
wchs: 列出服務器 watch 的詳細信息。
wchc: 經過 session 列出服務器 watch 的詳細信息，它的輸出是一個與 watch 相關的會話的列表。
wchp: 經過路徑列出服務器 watch 的詳細信息。它輸出一個與 session 相關的路徑。
crst: 重置當前這臺服務器全部鏈接/會話的統計信息
srst: 重置服務器的統計信息
srvr: 輸出服務器的詳細信息。zk版本、接收/發送包數量、鏈接數、模式（leader/follower）、節點總數。

還可使用telnet查看是否啓動成功
telnet 10.1.101.162 2181鏈接後按回車，而後輸入四字命令

zk異常

• 在Java API中的每個ZooKeeper操做都在其throws子句中聲明瞭兩種類型的異常，分別是InterruptedException和KeeperException。