關於zookeeper常見的8個面試問題
1. zookeeper是什麼,都有哪些功能
Zookeeper是一個樹形資料結構的高效能的分散式應用程式的協調服務。
擁有以下功能：
1、命名服務（naming）: 是指通過指定的名字來獲取資源或者服務的地址，提供者的資訊。保證服務全域性唯一。
2、配置管理（configuration management）： 將配置資訊儲存在Zookeeper的某個目錄節點中，然後將所有需要修改的應用機器監控配置資訊的狀態，一旦配置資訊發生變化，每臺應用機器就會收Zookeeper的通知，然後從Zookeeper獲取新的配置資訊應用到系統中。
3、分散式鎖（synchronization）： 解決分散式資源訪問衝突的問題。
4、叢集管理（group services）:
多臺 Server 組成一個服務叢集，那麼必須要一個“總管”知道當前叢集中每臺機器的服務狀態，一旦有機器不能提供服務，叢集中其它叢集必須知道，從而做出調整重新分配服務策略。同樣當增加叢集的服務能力時，就會增加一臺或多臺 Server，同樣也必須讓“總管”知道。
2. zk 有幾種部署模式
- 單機模式
- 叢集模式（配置 zoo.cfg）
- 偽叢集模式（一臺伺服器啟動多個zookeeper例項執行）
3. zk 的通知機制
客戶端端會對某個 znode 建立一個 watcher 事件，當該 znode 發生變化時，這些客戶端會收到 zookeeper 的通知，然後客戶端可以根據 znode 變化來做出業務上的改變。
4. zk 的分散式鎖實現方式
在講zk分佈鎖之前，先看下zookeeper中幾個關於節點的有趣的性質：
- 有序節點：假如當前有一個父節點為/lock，我們可以在這個父節點下面建立子節點；zookeeper提供了一個可選的有序特性，例如我們可以建立子節點“/lock/node-”並且指明有序，那麼zookeeper在生成子節點時會根據當前的子節點數量自動新增整數序號，也就是說如果是第一個建立的子節點，那麼生成的子節點為/lock/node-0000000000，下一個節點則為/lock/node-0000000001，依次類推。
- 臨時節點：客戶端可以建立一個臨時節點，在會話結束或者會話超時後，zookeeper會自動刪除該節點。
- 事件監聽：在讀取資料時，我們可以同時對節點設定事件監聽，當節點資料或結構變化時，zookeeper會通知客戶端。當前zookeeper有如下四種事件： 1、節點建立；2、節點刪除；3、節點資料修改；4、子節點變更。
下面描述使用zookeeper實現分散式鎖的演演算法流程，假設鎖空間的根節點為/lock：
- 客戶端連線zookeeper，並在/lock下建立臨時的且有序的子節點，第一個客戶端對應的子節點為/lock/lock-0000000000，第二個為/lock/lock-0000000001，以此類推。
- 客戶端獲取/lock下的子節點列表，判斷自己建立的子節點是否為當前子節點列表中序號最小的子節點，如果是則認為獲得鎖，否則監聽/lock的子節點變更訊息，獲得子節點變更通知後重復此步驟直至獲得鎖；
- 執行業務程式碼；
- 完成業務流程後，刪除對應的子節點釋放鎖。
5. zk 採用的哪種分散式一致性協議? 還有哪些分散式一致性協議
zab協議是zookeeper專門設計的支援崩潰恢復的原子廣播協議。目的是實現分散式zoopkeeper各個節點資料一致性。
zab協議約定zk節點有兩種角色leader和follower,zk客戶端會隨機的連結到 zookeeper 叢集中的一個節點，如果是讀請求，就直接從當前節點中讀取資料；如果是寫請求，那麼節點就會向 Leader 提交事務，Leader 接收到事務提交，會廣播該事務，只要超過半數節點寫入成功，該事務就會被提交。
ZAB協議包括兩種基本的模式：訊息廣播和崩潰恢復。
整個 Zookeeper 就是在這兩個模式之間切換。 簡而言之，當 Leader 服務可以正常使用，就進入訊息廣播模式，當 Leader 不可用時，則進入崩潰恢復模式。
以上其實大致經歷了三個步驟：
- 崩潰恢復：主要就是Leader選舉過程。
- 資料同步：Leader伺服器與其他伺服器進行資料同步。
- 訊息廣播：Leader伺服器將資料傳送給其他伺服器。
支援崩潰恢復後資料準確性的就是資料同步了，資料同步基於事務的 ZXID 的唯一性來保證。通過 + 1 操作可以辨別事務的先後順序。
ZAD和Paxos演演算法的聯絡和區別
共同點：
- 兩者都存在一個類似於Leader程式的角色，由其負責協調多個Follow程式的執行。
- Leader程式都會等待超過半數的Follower做出正確的反饋後，才會將一個提案進行提交。
- 在ZAB協議中，每個Proposal中都包含了一個epoch值，用來代表當前Leader週期，在Paxos演演算法中，同樣存在這樣一個標識，只是名字變成了Ballot。 不同點：
Paxos演演算法中，一個新的選舉產生的主程式會進行兩個階段的工作
- 讀階段，新的主程式會通過和所有其他程式進行通訊的方式來蒐集上一個主程式提出的提案，並將它們提交。
- 寫階段，當前主程式開始提出它自己的提案。
- ZAB在Paxos基礎上額外新增一個同步階段。同步階段之前，ZAB協議存在一個和Paxos讀階段類似的發現（Discovery）階段
同步階段中，新的Leader會確儲存在過半的Follower已經提交了之前Leader週期中的所有事務Proposal
- 發現階段的存在，確保所有程式都已經完成對之前所有事物Proposal的提交
- ZAB協議主要用於構建一個高可用的分散式資料主備系統，例如ZooKeeper，Paxos演演算法則是用於構建一個分散式的一致性狀態機系統
6. zk 是怎樣保證主從節點的狀態同步
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。
恢復模式：當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以後，恢復模式就結束了。
因此，選主得到的leader保證了同步狀態的進行，狀態同步又保證了leader和Server具有相同的系統狀態，當leader失去主權後可以在其他follower中選主新的leader。
7. 叢集中為什麼要有主節點
在分散式環境中，有些業務邏輯只需要叢集中的某一臺機器進行執行，
其他的機器可以共享這個結果，這樣可以大大減少重複計算，提高效能，所以就需要主節點
8. leader 選舉過程
有兩種情況會發起Leader選舉：
- 伺服器啟動的時候
- 伺服器執行的時候當Leader宕機
在講解流程之前，先說明一下選舉流程中涉及到的角色：
- LOOKING：尋找Leader狀態，處於該狀態需要進入選舉流程（只有該節點才可以投票）
- LEADING：領導者狀態，處於該狀態的節點說明是角色已經是Leader
- FOLLOWING：跟隨者狀態，表示Leader已經選舉出來，當前節點角色是follower
- OBSERVER：觀察者狀態，表明當前節點角色是observer（該節點不參與競選）
三個核心選舉原則：
- Zookeeper叢集中只有超過半數以上的伺服器啟動，叢集才能正常工作；
- 在叢集正常工作之前，myid小的伺服器給myid大的伺服器投票，直到叢集正常工作，選出Leader；
- 選出Leader之後，之前的伺服器狀態由Looking改變為Following，以後的伺服器都是Follower。
下面以一個簡單的例子來說明整個選舉的過程：
假設有五臺伺服器組成的Zookeeper叢集，它們的id從1-5，同時它們都是最新啟動的，也就是沒有歷史資料，在存放資料量這一點上，都是一樣的。
假設這些伺服器從id1-5，依序啟動：
因為一共5臺伺服器，只有超過半數以上，即最少啟動3臺伺服器，叢集才能正常工作。
（1）伺服器1啟動，發起一次選舉。
伺服器1投自己一票。此時伺服器1票數一票，不夠半數以上（3票），選舉無法完成；
伺服器1狀態保持為LOOKING；
（2）伺服器2啟動，再發起一次選舉。
伺服器1和2分別投自己一票，此時伺服器1發現伺服器2的id比自己大，更改選票投給伺服器2；
此時伺服器1票數0票，伺服器2票數2票，不夠半數以上（3票），選舉無法完成；
伺服器1，2狀態保持LOOKING；
（3）伺服器3啟動，發起一次選舉。
與上面過程一樣，伺服器1和2先投自己一票，然後因為伺服器3id最大，兩者更改選票投給為伺服器3；
此次投票結果：伺服器1為0票，伺服器2為0票，伺服器3為3票。此時伺服器3的票數已經超過半數（3票），伺服器3當選Leader。
伺服器1，2更改狀態為FOLLOWING，伺服器3更改狀態為LEADING；
（4）伺服器4啟動，發起一次選舉。
此時伺服器1，2，3已經不是LOOKING狀態，不會更改選票資訊。交換選票資訊結果：伺服器3為3票，伺服器4為1票。
此時伺服器4服從多數，更改選票資訊為伺服器3；
伺服器4並更改狀態為FOLLOWING；
（5）伺服器5啟動，同4一樣投票給3，此時伺服器3一共5票，伺服器5為0票；
伺服器5並更改狀態為FOLLOWING；
（6）選舉結果
最終Leader是伺服器3，狀態為LEADING；
其餘伺服器是Follower，狀態為FOLLOWING。