阿里P8架构师谈：Zookeeper的原理和架构设计，以及应用场景
什么是?Zookeeper
Zookeeper 分布式服務框架是Apache Hadoop 的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：
Zookeeper已經成為Hadoop生態系統中的基礎組件。
Zookeeper的基本原理和架構
1、Zookeeper的角色
??領導者（leader）：負責進行投票的發起和決議，更新系統狀態。
??學習者（learner）：包括跟隨者（follower）和觀察者（observer），follower用于接受客戶端請求并想客戶端返回結果，在選主過程中參與投票。
??Observer：可以接受客戶端連接，將寫請求轉發給leader，但observer不參加投票過程，只同步leader的狀態，observer的目的是為了擴展系統，提高讀取速度
??客戶端（client）：請求發起方
? 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即為選舉出來的leader
FOLLOWING：leader已經選舉出來，當前Server與之同步
其他文檔：http://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html
2、Zookeeper 的讀寫機制
? Zookeeper是一個由多個server組成的集群
? 一個leader，多個follower
? 每個server保存一份數據副本
? 全局數據一致
? 分布式讀寫
? 更新請求轉發，由leader實施
3、Zookeeper 的保證
? 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行
? 數據更新原子性，一次數據更新要么成功，要么失敗
? 全局唯一數據視圖，client無論連接到哪個server，數據視圖都是一致的
? 實時性，在一定事件范圍內，client能讀到最新數據
4、Zookeeper節點數據操作流程
1.在Client向Follwer發出一個寫的請求
2.Follwer把請求發送給Leader
3.Leader接收到以后開始發起投票并通知Follwer進行投票
4.Follwer把投票結果發送給Leader
5.Leader將結果匯總后如果需要寫入，則開始寫入同時把寫入操作通知給Leader，然后commit;
6.Follwer把請求結果返回給Client
?
5、Zookeeper工作原理
??Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。
Zab協議有兩種模式，它們分別是：恢復模式和廣播模式。
當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步以后，恢復模式就結束了。
6、數據一致性與paxos 算法
? 據說Paxos算法的難理解與算法的知名度一樣令人敬仰，所以我們先看如何保持數據的一致性，這里有個原則就是：
? 在一個分布式數據庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那么他們最后能得到一個一致的狀態。
? Paxos算法解決的什么問題呢，解決的就是保證每個節點執行相同的操作序列。好吧，這還不簡單，master維護一個全局寫隊列，所有寫操作都必須 放入這個隊列編號，那么無論我們寫多少個節點，只要寫操作是按編號來的，就能保證一致性。沒錯，就是這樣，可是如果master掛了呢。
? Paxos算法通過投票來對寫操作進行全局編號，同一時刻，只有一個寫操作被批準，同時并發的寫操作要去爭取選票，
只有獲得過半數選票的寫操作才會被 批準（所以永遠只會有一個寫操作得到批準），其他的寫操作競爭失敗只好再發起一
輪投票，就這樣，在日復一日年復一年的投票中，所有寫操作都被嚴格編號排 序。編號嚴格遞增，當一個節點接受了一個
編號為100的寫操作，之后又接受到編號為99的寫操作（因為網絡延遲等很多不可預見原因），它馬上能意識到自己 數據
不一致了，自動停止對外服務并重啟同步過程。任何一個節點掛掉都不會影響整個集群的數據一致性（總2n+1臺，除非掛掉大于n臺）。
總結
? Zookeeper 作為 Hadoop 項目中的一個子項目，是 Hadoop 集群管理的一個必不可少的模塊，它主要用來控制集群中的數據，
如它管理 Hadoop 集群中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態同步等。
關于Paxos算法可以查看文章 Zookeeper全解析——Paxos作為靈魂
推薦書籍：《從Paxos到Zookeeper分布式一致性原理與實踐》
7、Observer
? Zookeeper需保證高可用和強一致性；
? 為了支持更多的客戶端，需要增加更多Server；
? Server增多，投票階段延遲增大，影響性能；
? 權衡伸縮性和高吞吐率，引入Observer
? Observer不參與投票；
? Observers接受客戶端的連接，并將寫請求轉發給leader節點；
? 加入更多Observer節點，提高伸縮性，同時不影響吞吐率
8、 為什么zookeeper集群的數目，一般為奇數個？
?Leader選舉算法采用了Paxos協議；
?Paxos核心思想：當多數Server寫成功，則任務數據寫成功如果有3個Server，則兩個寫成功即可；如果有4或5個Server，則三個寫成功即可。
?Server數目一般為奇數（3、5、7）如果有3個Server，則最多允許1個Server掛掉；如果有4個Server，則同樣最多允許1個Server掛掉由此，
我們看出3臺服務器和4臺服務器的的容災能力是一樣的，所以為了節省服務器資源，一般我們采用奇數個數，作為服務器部署個數。
9、Zookeeper 的數據模型
? 層次化的目錄結構，命名符合常規文件系統規范
? 每個節點在zookeeper中叫做znode,并且其有一個唯一的路徑標識
? 節點Znode可以包含數據和子節點，但是EPHEMERAL類型的節點不能有子節點
? Znode中的數據可以有多個版本，比如某一個路徑下存有多個數據版本，那么查詢這個路徑下的數據就需要帶上版本
? 客戶端應用可以在節點上設置監視器
? 節點不支持部分讀寫，而是一次性完整讀寫
10、Zookeeper 的節點
? Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）
? Znode的類型在創建時確定并且之后不能再修改
? 短暫znode的客戶端會話結束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節點
? 持久znode不依賴于客戶端會話，只有當客戶端明確要刪除該持久znode時才會被刪除
? Znode有四種形式的目錄節點
? PERSISTENT（持久的）
? EPHEMERAL（暫時的）
? PERSISTENT_SEQUENTIAL（持久化順序編號目錄節點）
? EPHEMERAL_SEQUENTIAL（暫時化順序編號目錄節點）
Zookeeper的應用場景
1. 配置管理
這個好理解，分布式系統都有好多機器，比如我在搭建hadoop的HDFS的時候，需要在一個主機器上（Master節點）配置好HDFS需要的各種配置文件，然后通過scp命令把這些配置文件拷貝到其他節點上，這樣各個機器拿到的配置信息是一致的，才能成功運行起來HDFS服務。
Zookeeper提供了這樣的一種服務：一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的都可以獲得變更。這樣就省去手動拷貝配置了，還保證了可靠和一致性。
2. 名字服務
這個可以簡單理解為一個電話薄，電話號碼不好記，但是人名好記，要打誰的電話，直接查人名就好了。
分布式環境下，經常需要對應用/服務進行統一命名，便于識別不同服務；
- 類似于域名與ip之間對應關系，域名容易記住；
- 通過名稱來獲取資源或服務的地址，提供者等信息
3. 分布式鎖
碰到分布二字貌似就難理解了，其實很簡單。單機程序的各個進程需要對互斥資源進行訪問時需要加鎖，那分布式程序分布在各個主機上的進程對互斥資源進行訪問時也需要加鎖。很多分布式系統有多個可服務的窗口，但是在某個時刻只讓一個服務去干活，當這臺服務出問題的時候鎖釋放，立即fail over到另外的服務。這在很多分布式系統中都是這么做，這種設計有一個更好聽的名字叫Leader Election（leader選舉）。舉個通俗點的例子，比如銀行取錢，有多個窗口，但是呢對你來說，只能有一個窗口對你服務，如果正在對你服務的窗口的柜員突然有急事走了，那咋辦？找大堂經理（zookeeper）!大堂經理指定另外的一個窗口繼續為你服務！
4. 集群管理
在分布式的集群中，經常會由于各種原因，比如硬件故障，軟件故障，網絡問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出集群。這個時候，集群中有些機器（比如Master節點）需要感知到這種變化，然后根據這種變化做出對應的決策。我已經知道HDFS中namenode是通過datanode的心跳機制來實現上述感知的，那么我們可以先假設Zookeeper其實也是實現了類似心跳機制的功能吧！
你可能也喜歡:
總結
以上是生活随笔為你收集整理的阿里P8架构师谈：Zookeeper的原理和架构设计，以及应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android 兼容 Java 8 语法
- 下一篇： DataMan-美团旅行数据质量监管平台