1.什麼是zookeeper
zookeeper是一個高效可靠的分佈式協調服務，提供了諸如統一命名服務、配置管理和分佈式鎖等分佈式服務。是一個典型的分佈式數據一致性的解決方案，分佈式應用程序可以基於它實現諸如數據發佈/訂閱、負載均衡、分佈式協調通知、Master選舉、分佈式鎖和分佈式隊列等功能。zookeeper可以保證如下分佈式一致性特性。
順序一致性
從同一個客戶端發起的事務請求，最終將會嚴格的按照發起順序應用到zookeeper中去。
原子性
所有事務請求的處理結果在整個集羣中的所有機器上應用情況是一致的，也就是說，要麼整個集羣所有機器都成功應用到了某個事務，要麼都沒有應用，一定不會出現集羣中部分機器應用了該事務，而另外一部分沒有應用的情況。
2.zookeeper基本概念（整體介紹）
集羣角色
最典型的集羣模式就是Master/Slave模式（主備模式）。在zookeeper中，這些概念被顛覆了 。它沒有引用Master/Salve概念，而是引入了Leader、Follower和Observer三種角色。Zookeeper集羣中所有機器通過一個Leader選舉過程來選定一臺Leader服務器，Leader服務器爲客戶端提供讀和寫服務。除Leader服務外，其它機器包括Follower和Observer，只能提供讀服務。Observer機器不參與Leader選舉，也不參與寫操作的“過半寫成功”策略，因此Observer可以在不影響寫性能的情況下提升集羣的讀性能。
會話（Session）
Session是指客戶端會話。在Zookeeper中，一個客戶端連接是指客戶端和服務端之間的一個tcp長連接。Zookeeper對外的默認端口是2181，客戶端啓動的時候，首先會與服務器建立一個TCP連接，從第一次建立連接，客戶端會話的生命週期也開始了，通過這個連接，客戶端能夠通過心跳檢測與服務器保持有效的會話。不僅可以向服務器發送請求，也可以接收來自服務器的Watch事件通知。
數據節點（Znode）
zookeeper節點分爲兩類，第一類☞構成集羣的機器，機器節點；第二類☞數據模型中的數據單元，我們稱之爲數據節點-Znode。Zookeeper將所有數據存儲在內存中，數據模型是一顆樹，由斜槓（/）進行分割的路徑就是一個節點。節點可以分爲持久節點和臨時節點。持久節點一旦被創建，除非主動移除，否則將一直保存在Zookeeper上；臨時節點就不一樣了，它的生命週期和客戶端會話綁定，一旦客戶端會話實現，那麼這個客戶端創建的所有臨時節點都會被移除。另外，Zookeeper還允許用戶爲每個節點添加一個特殊屬性：sequential。一旦這個節點被標記上這個屬性，節點被創建的時候，Zookeeper會自動在其節點後面追加一個整數型字，這個整數型字是一個由父節點維護的自增數字。
版本
Zookeeper的每個Znode上都會存儲數據。數據中記錄了Znode的三個數據版本，分別是version（當前Znode的版本）、cversion（當前Znode子節點的版本）、aversion（當前Znode的ACL版本）。
ACL
權限控制。Zookeeper定義了5中權限
create：創建子節點的權限。
read：獲取節點數據和子節點列表的權限。
writer：更新節點數據的權限。
delete：刪除子節點的權限。
admin：設置節點acl的權限。
Watch（事件監聽）
Zookeeper允許用戶在指定節點上註冊一些Watch，並且在一些特定事件觸發的時候，Zookeeper服務會將事件同時到感興趣的客戶端上去。
3. Zookeeper的ZAB協議
ZAB（Zookeeper atomic broadcast）協議是分佈式協調服務Zookeeper專門設計的一種支持崩潰恢復的原子廣播協議。用來實現集羣中各個副本的數據一致性。
ZAB協議的核心是定義了那些改變Zookeeper服務器數據狀態事務請求處理方式：所有事務請求必須由一個全局唯一的服務器來協調處理，這樣的服務器稱之爲Leader服務器，而餘下的其他服務器則成爲Follower服務器。leader服務器負責將一個客戶端事務請求轉換爲一個事務proposal（提議），並將該proposal分發給集羣中所有的Follower服務器。之後leader服務器要等待所有follower服務器的反饋，一旦超過半數的follower服務器進行了正確的反饋後，那麼leader就會再次向所有的follower服務器發送分發commit消息，要求將前一個proposal進行提交。
ZAB協議兩種基本模式：分別是崩潰恢復和消息廣播。
消息廣播協議
是一個原子廣播協議，類似於一個二階段提交過程。針對客戶端的事務請求，leader服務器會爲其生成對應的事務proposal，並將其發送給集羣中其餘多有的機器，然後再分別收集各自的選票，最後進行事務提交。ZAB協議涉及的二階段提交過程則與其略有不同。在ZAB協議中二階段提交中，移除了中斷邏輯，所有服務器要麼正常反饋，要麼拋棄leader服務器。同時ZAB協議將二階段提交中的中斷邏輯移除，意味着我們可以在過半的Follower服務器已經反饋ack之後就開始提交事務proposal，而不需要等待集羣中所有的follower服務器都反饋響應。此模式下無法解決leader服務器崩潰帶來的數據不一致問題，解決方案：崩潰恢復協議。另外廣播協議基於具有FIFO特性的TCP協議來進行通信的。保證了消息廣播過程中消息的接收和發送的順序性。在整個廣播協議中，leader服務器會爲每個事物請求生成對應的proposal來進行廣播，並且在廣播之前，首先爲這個事務proposal分配一個全局單調遞增的唯一ID，稱之爲事務ID（ZXID 64位前32位記錄當前朝代，後32位記錄事務id 在廣播協議中事務id是遞增的）。由於ZAB協議需要保證每一個消息嚴格的因果關係，因此必須將每一個事務proposal按照其zxid的先後順序來進行排序和處理。
在消息廣播過程中，Leader服務器會爲每一個Follower服務器都各自分配一個單獨的隊列，然後將需要的廣播事務proposal一次放入這些隊列中去，並且根據FIFO策略進行消息發送。每一個Follower服務器在接收到這個事務proposal之後，都會首先將其以事務日誌的形式寫入到本地磁盤中去，並且成功寫入後反饋給leader服務器一個ack響應。當leader服務器接收到超過半數Follower的ack響應收，就會廣播一個commit消息給所有的follower服務器通知其進行事務提交，同時leader自身也會完成對事物的提交，而每個follower服務器在接收到commit消息後，也會完成對事物的提交。
崩潰恢復協議
選舉
基本特性
ZAB協議需要確保那些已經在Leader服務上提交的事務proposal最終被所有機器提交。
假設一個事務在leader服務器上被提交了，並且已經得到過半的Follower服務器的ack返回，但是在它將commit消息發送給所有的follower機器之前（部分機器收到 部分沒有收到），leader服務器掛了。ZAB協議需要確保事務proposal在所有的服務器上提交成功
ZAB協議需要確保丟棄那些只在leader服務器上被提出的事務
leader服務在發出commit之前掛掉了，需要確保選舉後以及該服務器重新連接後，整個集羣丟棄該事務proposal。
數據同步
完成Leader選舉之後沒在這是開始工作（即接收客戶端的事務請求，然後提出新的提案）之前，Leader服務器會首先確認事務日誌中的所有proposal是否都已經被集羣中過半的機器提交了，即是否完成數據同步。
Leader服務器會爲每一個Follower服務器都準備一個隊列，並將哪些沒有被各個Follower服務器同步的事務以proposal消息逐個發送給Follower服務器，並在每一個proposal消息後面緊接着在發送一個commit消息，以表示該事物已經被提交。等待Follower服務器將所有其尚未同步的事務proposal都從Leader服務器同步過來併成功應用到本地數據庫中後，leader服務器就會將該Follower服務器加入到真正可用的follower列表中，並開始之後的其他流程。
事務丟棄
ZAB處理丟棄的事務proposal。在ZAB協議的事務編號ZXID設計中，是一個由64位的數字，低32位可以看做一個簡單的遞增的計數器，針對客戶端的每一個事務請求，Leader服務器在產生一個新的事務proposal時，都會對計數器進行加1操作。而高32位則代表了Leader週期epoch朝代的編號。每當選舉一個新的Leader服務器，就會總這個Leader服務器中取出本地日誌中最大事務Proposal的ZXID，並解析出epoch，然後對其進行加一，並將低32位設置爲0，最爲新的事務ZXID。基於這樣的策略，當包含上一個Leader週期中尚未提交的事務Proposal的服務器啓動時，其肯定無法成爲leader，原因集羣中一定包含一個Quorum（集羣中處於過半UP（活躍）狀態的進程組成的子集）集合該集合中的機器一定包含了了更高epoch的事務提議。同時Leader服務器會根據自己服務器上最後被提交的proposal來和Follower服務器進行比對，比對結果是Leader會要求Follower進行一個回退，回退到一個確實已經被集羣中過半提價的最新事務中（即會退到Leader與該Follower服務器同朝代的最大的事務id ）