一場面試已經進行了許久，幾番“交戰”下來，程序員Y已經是滿頭大汗…
面試官：這樣吧，你再來說說Zookeeper的工作原理
程序員Y（終於按捺不住自己心頭的怒火）：有事沒事問底層，有事沒事問原理，我TMD寫代碼又不是做學術，會用就行了，知道底層原理有屁用啊？
面試官：小夥子啊！你如果連某個技術的底層原理都搞不懂的話，那你又怎麼能把它運用自如呢？你又怎麼會知道在不同的場景下應該使用什麼樣的框架呢？
程序員Y：那我不管，我覺得我能在我所在的崗位做好我自己要做的事情就行了，熟知原理這些還浪費時間，工作中有用不到…
面試官：好了，既然你這樣想，你先回家等通知吧…（朝着門口）下一位…
程序員Y：憑什麼啊？我就面試一個7K的崗位，基礎的我都答上來了，來，你來跟我講講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 都恢復到一個正確的狀態。
如果往多了來講，它內部原理具體分爲以下十項：
- 請求、事務和標識符
- 羣首選舉
- Zab：狀態更新的廣播協議
- 觀察者
- 服務器的構成
- 本地存儲
- 服務器與會話
- 服務器與監視點
- 客戶端
- 序列化
面試官：怎麼樣小夥子？知道了嗎？
程序員Y：雖然聽了半天我也沒有聽懂你說的什麼，但是感覺很有道理的樣子，告辭！
程序員Y頭也沒回的走出了面試房間…
面試官趕忙擦了一把汗：還好是我知道的zk，要是前面幾個什麼kafka、RabbitMQ，就出醜大了
面試官（拿出手機，撥出一個電話）：喂，是人事嗎？你們怎麼回事？我這裏招的是中高級程序員，給出的薪資是24K，你們是不是把隔壁部門的初級崗位應聘者丟我這裏來了？
…
看完上面的小故事，小on就來給大家分享Zookeeper的相關知識了。
注意：以下內容摘自一份283頁的pdf，《Java核心技術點》↓
還有一些大廠面試真題↓
需要的程序員朋友，私信霸哥【面試】免費領取！
Zookeeper 概念
Zookeeper 是一個分佈式協調服務，可用於服務發現，分佈式鎖，分佈式領導選舉，配置管理等。Zookeeper 提供了一個類似於 Linux 文件系統的樹形結構（可認爲是輕量級的內存文件系統，但只適合存少量信息，完全不適合存儲大量文件或者大文件），同時提供了對於每個節點的監控與通知機制。
Zookeeper 角色
Zookeeper 集羣是一個基於主從複製的高可用集羣，每個服務器承擔如下三種角色中的一種
Leader
- 一個 Zookeeper 集羣同一時間只會有一個實際工作的 Leader，它會發起並維護與各 Follwer及Observer間的心跳。
- 所有的寫操作必須要通過 Leader 完成再由 Leader 將寫操作廣播給其它服務器。只要有超過半數節點（不包括 observeer 節點）寫入成功，該寫請求就會被提交（類 2PC 協議）。
Follower
- 一個 Zookeeper 集羣可能同時存在多個 Follower，它會響應 Leader 的心跳；
- Follower 可直接處理並返回客戶端的讀請求，同時會將寫請求轉發給 Leader 處理；
- 並且負責在 Leader 處理寫請求時對請求進行投票。
Observer
- 角色與 Follower 類似，但是無投票權。Zookeeper 需保證高可用和強一致性，爲了支持更多的客戶端，需要增加更多 Server；Server 增多，投票階段延遲增大，影響性能；引入 Observer，Observer 不參與投票； Observers 接受客戶端的連接，並將寫請求轉發給 leader 節點； 加入更多 Observer 節點，提高伸縮性，同時不影響吞吐率。
