**：
zookeeper使用了zab(zookeeper atomic broadcast)協議，進行了訊息廣播，崩潰恢復，資料同步
基於該協議，zookeeper 實現了一種主備模式的系統架構來保持集群中各個副本之間的資料一致性，同時其崩潰恢復過程也確保zk集群的高可用性,所以leader是主，follower是備是副本？
zookeeper使用乙個單一主程序來接收並處理客戶端的所有事務請求，並採用zab的原子廣播協議，將伺服器資料的狀態變更以事務proposal的形式廣播到所有的副本程序上，並且zab協議能夠保證乙個全域性的變更序列。
zab協議的核心是定義了對於那些會改變zookeeper伺服器資料狀態的事務請求的處理方式。當有寫請求時，就把事務提交給loader,loader會廣播這個事務讓所有的副本都寫入這個資料
zookeeper 客戶端會隨機連線到 zookeeper 集群的乙個節點，如果是讀請求，就直接從當前節點中讀取資料；如果是寫請求且當前節點不是leader，那麼節點就會向 leader 提交事務，leader 會廣播事務，只要有超過半數節點寫入成功，該寫請求就會被提交（類 2pc 協議）。
那麼問題來了：
主從架構下，leader 崩潰，資料一致性怎麼保證？
選舉 leader 的時候，整個集群無法處理寫請求,所以自然不會有資料一致性的問題
如何快速進行 leader 選舉？
所以zab協議重要的就是：1. 訊息廣播協議（leader向其他節點廣播事務） 2. leader選舉（快速選舉過程fast leader election，集群剛啟動時(還沒有loader)，leader崩潰或leader與集群中超過一半的節點斷連後(整個集群沒法用)） 3. leader重新選舉後，如何進行資料同步到一致狀態
事務id的概念
在 zab 協議的事務編號 zxid 設計中，zxid 是乙個 64 位的數字，其中低 32 位是乙個簡單的單調遞增的計數器，針對客戶端每乙個事務請求，計數器加 1；而高 32 位則代表 leader 週期 epoch 的編號，每選產生乙個新的 leader 伺服器時，就會從這個 leader 伺服器上取出其本地日誌中最大事務的zxid(因為所有follower的事務是一樣的)，並從中讀取 epoch 值，然後加 1，以此作為新的 epoch，並將低 32 位從 0 開始計數。
epoch：可以理解為當前集群所處的年代或者週期，每個 leader 就像皇帝，都有自己的年號，所以每次改朝換代，leader 變更之後，都會在前乙個年代的基礎上加 1。這樣就算舊的 leader 崩潰恢復之後，也沒有人聽他的了，因為 follower 只聽從當前年代的 leader 的命令。
zab協議的兩種基本模式：崩潰恢復模式和訊息廣播模式。其過程為：
當系統啟動或leader伺服器出現故障時，進入故障恢復模式，將會開啟新的一輪選舉，選舉產生的leader會與過半的follower進行同步，使資料一致，當與過半的機器同步完成後，就退出恢復模式，進入訊息廣播模式。當一台遵從zab協議的伺服器啟動時，如果檢測到leader在廣播訊息，會自動進入恢復模式，當其完成與leader的同步之後，則進入廣播模式。所以，zk還可以保證易擴充套件性。（沒進行資料同步，就不能加入真正可用的follower列表）
ZooKeeper的工作原理
zookeeper是乙個分布式的，開放原始碼的分布式應用程式協調服務，它包含乙個簡單的原語集，分布式式應用程式可以基於它實現同步服務，配置維護和命名服務等。zookeeper是hadoop的乙個子專案。在分布式應用中，由於工程師不能很好的使用鎖機制，以及基於訊息的協調機制不適合在某些應用中使用，因此...
zookeeper的工作原理
zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做zab協議。zab協議有兩種模式，它們分別是恢復模式和廣播模式。當服務啟動或者在領導者崩潰後，zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步以後，恢復...
Zookeeper之工作原理
zookeeper是乙個分布式的，開放原始碼的分布式應用程式協調服務，它包含乙個簡單的原語集，分布式應用程式可以基於它實現同步服務，配置維護和命名服務等。zookeeper是hadoop的乙個子專案，其發展歷程無需贅述。在分布式應用中，由於工程師不能很好地使用鎖機制，以及基於訊息的協調機制不適合在某...