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

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

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

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

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

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

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

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

面試官：

可靠性

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

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

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

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

ZAB

ZAB（Zookeeper Atomic Broadcast，zookeeper原子廣播），ZAB協(xié)議用來保證zookeeper各個節(jié)點之間數(shù)據(jù)的一致性。

ZAB協(xié)議包括如下特點：

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

兩階段提交

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

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

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

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

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

zookeeper集群的狀態(tài)分為兩種：正常狀態(tài)和異常狀態(tài)。也就是有l(wèi)eader（能提供服務）和沒有l(wèi)eader（進入選舉）

廣播模式

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

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

恢復模式

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

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

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

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

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

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

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