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

　　　　• Follower主要有四個功能：
　　　　• 1. 向Leader傳送請求（PING訊息、REQUEST訊息、ACK訊息、REVALIDATE訊息）；
　　　　• 2 .接收Leader訊息並進行處理；
　　　　• 3 .接收Client的請求，如果為寫請求，傳送給Leader進行投票；
　　　　• 4 .返回Client結果。
　　　　• Follower的訊息迴圈處理如下幾種來自Leader的訊息：
　　　　• 1 .PING訊息： 心跳訊息；
　　　　• 2 .PROPOSAL訊息：Leader發起的提案，要求Follower投票；
　　　　• 3 .COMMIT訊息：伺服器端最新一次提案的資訊；
　　　　• 4 .UPTODATE訊息：表明同步完成；
　　　　• 5 .REVALIDATE訊息：根據Leader的REVALIDATE結果，關閉待revalidate的session還是允許其接受訊息；
　　　　• 6 .SYNC訊息：返回SYNC結果到客戶端，這個訊息最初由客戶端發起，用來強制得到最新的更新。

5、Zookeeper leader 選舉　　

　　• 半數通過
　　　　– 3臺機器 掛一臺 2>3/2
　　　　– 4臺機器 掛2臺 2！>4/2

　　• A提案說，我要選自己，B你同意嗎？C你同意嗎？B說，我同意選A；C說，我同意選A。(注意，這裡超過半數了，其實在現實世界選舉已經成功了。

　　　但是計算機世界是很嚴格，另外要理解演算法，要繼續模擬下去。)
　　• 接著B提案說，我要選自己，A你同意嗎；A說，我已經超半數同意當選，你的提案無效；C說，A已經超半數同意當選，B提案無效。
　　• 接著C提案說，我要選自己，A你同意嗎；A說，我已經超半數同意當選，你的提案無效；B說，A已經超半數同意當選，C的提案無效。
　　• 選舉已經產生了Leader，後面的都是follower，只能服從Leader的命令。而且這裡還有個小細節，就是其實誰先啟動誰當頭。

6、zxid

　　• znode節點的狀態資訊中包含czxid, 那麼什麼是zxid呢?
　　• ZooKeeper狀態的每一次改變, 都對應著一個遞增的Transaction id, 該id稱為zxid. 由於zxid的遞增性質, 如果zxid1小於zxid2, 那麼zxid1肯定先於zxid2發生.

　　　建立任意節點, 或者更新任意節點的資料, 或者刪除任意節點, 都會導致Zookeeper狀態發生改變, 從而導致zxid的值增加.

7、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都恢復到一個正確的狀態。　

　　» 每個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的請求進行服務了

8、資料一致性與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分散式一致性原理與實踐》

9、Observer　　

　　• Zookeeper需保證高可用和強一致性；
　　• 為了支援更多的客戶端，需要增加更多Server；
　　• Server增多，投票階段延遲增大，影響效能；
　　• 權衡伸縮性和高吞吐率，引入Observer
　　• Observer不參與投票；
　　• Observers接受客戶端的連線，並將寫請求轉發給leader節點；
　　• 加入更多Observer節點，提高伸縮性，同時不影響吞吐率

10、 為什麼zookeeper叢集的數目，一般為奇數個？

　　•Leader選舉演算法採用了Paxos協議；
　　•Paxos核心思想：當多數Server寫成功，則任務資料寫成功如果有3個Server，則兩個寫成功即可；如果有4或5個Server，則三個寫成功即可。
　　•Server數目一般為奇數（3、5、7）如果有3個Server，則最多允許1個Server掛掉；如果有4個Server，則同樣最多允許1個Server掛掉由此，

　　  我們看出3臺伺服器和4臺伺服器的的容災能力是一樣的，所以為了節省伺服器資源，一般我們採用奇數個數，作為伺服器部署個數。

11、Zookeeper 的資料模型　

　　» 層次化的目錄結構，命名符合常規檔案系統規範
　　» 每個節點在zookeeper中叫做znode,並且其有一個唯一的路徑標識
　　» 節點Znode可以包含資料和子節點，但是EPHEMERAL型別的節點不能有子節點
　　» Znode中的資料可以有多個版本，比如某一個路徑下存有多個數據版本，那麼查詢這個路徑下的資料就需要帶上版本
　　» 客戶端應用可以在節點上設定監視器
　　» 節點不支援部分讀寫，而是一次性完整讀寫

12、Zookeeper 的節點

　　» Znode有兩種型別，短暫的（ephemeral）和持久的（persistent）
　　» Znode的型別在建立時確定並且之後不能再修改
　　» 短暫znode的客戶端會話結束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節點
　　» 持久znode不依賴於客戶端會話，只有當客戶端明確要刪除該持久znode時才會被刪除
　　» Znode有四種形式的目錄節點
　　» PERSISTENT（持久的）
　　» EPHEMERAL(暫時的)
　　» PERSISTENT_SEQUENTIAL（持久化順序編號目錄節點）
　　» EPHEMERAL_SEQUENTIAL（暫時化順序編號目錄節點）