某天程序員小白參加面試：

幾番苦戰之后，面試進入白熱化階段。面試官大開大合，小白見招拆招。一時之間，難解難分，兩人對拆數十回合不分勝負。說時遲，那時快，小白的左手像火焰一般炙熱，右手像冰霜一樣寒冷…

面試官：我看你簡歷上寫了熟悉zookeeper，你項目里用zookeeper干什么了？

小白：主要用來做dubbo的注冊中心、分布式鎖以及統一配置等

面試官：那你熟悉zookeeper集群模型嗎？

小白：zookeeper集群是一主多從的模型，節點分成三種角色：leader、follower和observer。leader負責寫、follower和observer負責讀。（小白內心：面試官接下來該問我follower和observer的區別了）

面試官：你說zookeeper是一主多從，那么主掛掉了怎么辦（單點故障）？

（小白內心：我勒個擦，怎么不按套路出牌。記得redis主從復制模型中，master掛掉之后是靠sentinel自動完成故障轉移的。zookeeper好像沒有sentinel…不過這可難不倒我）小白：我們系統的zookeeper非常穩定，leader不會掛

面試官：

可靠性

從zookeeper官網上的描述可以知道，zookeeper自稱是高可用的，像這種自帶高可用的中間件可不多見。zookeeper一主多從的模型，leader只有一個，注定會成為單點故障。

leader掛了不可怕，可怕的是沒有leader。古代皇帝駕崩之后，大臣通常會說這樣一句話：國不可一日無君，然后勸太子早承大統。

zookeeper的做法也是一樣，就是盡最快的速度，從存活的follower中選出一個新leader。那么現在問題來了，皇帝駕崩之前往往已經立了太子，或者由嫡長子自動繼承。但是對zookeeper來說，不可能提前選好下一個預備leader，并且follower之間也沒有嫡庶之分，換言之，每個follower的身份都是平等的。

zookeeper采用了ZAB算法來解決選舉的問題。

ZAB

ZAB（Zookeeper Atomic Broadcast，zookeeper原子廣播），ZAB協議用來保證zookeeper各個節點之間數據的一致性。

ZAB協議包括如下特點：

follower節點上所有的寫請求都轉發給leader
寫操作嚴格有序
ZooKeeper使用改編的兩階段提交協議來保證各個節點的事務一致性

兩階段提交

二階段提交（英語：Two-phase Commit）是指在計算機網絡以及數據庫領域內，為了使基于分布式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種算法。通常，二階段提交也被稱為是一種協議（Protocol）。在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的組件來統一掌控所有節點（稱作參與者）的操作結果并最終指示這些節點是否要把操作結果進行真正的提交（比如將更新后的數據寫入磁盤等等）。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

兩階段提交就是把提交分成2個階段。預提交階段和提交階段

整個提交過程分為4個步驟

協調者詢問所有的參與者是不是可以提交了
參與者回復yes or no
協調者收到所有的yes之后執行commit否則執行rollback
參與者執行完成后回復ACK

zookeeper采用的是改編過的兩階段提交，就是在第三步的時候，不需要所有的參與者回復yes，只需要超過半數（剛好半數也不行）的參與者回復yes。之所以是超過半數而不是所有參與者回復yes，是為了避免少量的參與者出現單點故障或者網絡波動導致協調者長時間收不到回復。

zookeeper集群的狀態分為兩種：正常狀態和異常狀態。也就是有leader（能提供服務）和沒有leader（進入選舉）

廣播模式

廣播模式就是指zookeeper正常工作的模式。正常情況下，一個寫入命令會經過如下步驟被執行

leader從客戶端或者follower那里收到一個寫請求
leader生成一個新的事務并為這個事務生成一個唯一的Zxid，
leader將這個事務發送給所有的follows節點
follower節點將收到的事務請求加入到歷史隊列(history queue)中，并發送ack給leader
當leader收到大多數follower（超過法定數量）的ack消息，leader會發送commit請求
當follower收到commit請求時，會判斷該事務的Zxid是不是比歷史隊列中的任何事務的Zxid都小，如果是則commit，如果不是則等待比它更小的事務的commit

恢復模式

當leader故障之后，zookeeper集群進入無主模式，此時zookeeper集群不能對外提供服務，必須選出一個新的leader完成數據一致后才能重新對外提供服務。zookeeper官方宣稱集群可以在200毫秒內選出一個新leader。

正常模式下的幾個步驟，每個步驟都有可能因為leader故障而中斷。但是恢復過程只與leader有沒有commit有關。

首先看前三個步驟，只做了一件事，把事務發送出去。

如果事務沒有發出去，所有follower都沒有收到這個事務，leader故障了。所有的follower都不知道這個事務的存在，根據心跳檢測機制，follower發現leader故障，重新選出一個leader。會根據每個節點Zxid來選擇，誰的Zxid最大，表示誰的數據最新，自然會被選舉成新的leader。如果Zxid都一樣，表示在follower故障之前，所有的follower節點數據完全一致，此時選擇myid最大的節點成為新的leader，因為有一個固定的選舉標準會加快選舉流程。新的leader選出來之后，所有節點的數據本身就是一致的，此時就可以對外提供服務。

假設新的leader選出來之后，原來的leader又恢復了，此時原來的leader會自動成為follower，之前的事務即使重新發送給新的leader，因為新的leader已經開啟了新的紀元，而原先的leader中Zxid還是舊的紀元，自然會被丟棄。并且該節點的Zxid也會更新成新的紀元。

紀元的意思就是標識當前leader是第幾任leader，相當于改朝換代時候的年號。

如果在leader故障之前已經commit，zookeeper依然會根據Zxid或者myid選出數據最新的那個follower作為新的leader。新leader與follower建立FIFO的隊列，先將自身有而follower缺失的事務發送給它，再將這些事務的commit命令發送給 follower，這便保證了所有的follower都保存了所有的事務、所有的follower都處理了所有的消息。