關於zookeeper常見的8個面試問題

1. zookeeper是什麼,都有哪些功能

Zookeeper是一個樹形數據結構的高性能的分佈式應用程序的協調服務。

擁有如下功能：

一、命名服務（naming）: 是指經過指定的名字來獲取資源或者服務的地址，提供者的信息。保證服務全局惟一。

二、配置管理（configuration management）： 將配置信息保存在Zookeeper的某個目錄節點中，而後將全部須要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每臺應用機器就會收Zookeeper的通知，而後從Zookeeper獲取新的配置信息應用到系統中。

三、分佈式鎖（synchronization）： 解決分佈式資源訪問衝突的問題。

四、集羣管理（group services）:

多臺 Server 組成一個服務集羣，那麼必需要一個「總管」知道當前集羣中每臺機器的服務狀態，一旦有機器不能提供服務，集羣中其它集羣必須知道，從而作出調整從新分配服務策略。一樣當增長集羣的服務能力時，就會增長一臺或多臺 Server，一樣也必須讓「總管」知道。

2. zk 有幾種部署模式

1. 單機模式
2. 集羣模式（配置 zoo.cfg）
3. 僞集羣模式（一臺服務器啓動多個zookeeper實例運行）

3. zk 的通知機制

客戶端端會對某個 znode 創建一個 watcher 事件，當該 znode 發生變化時，這些客戶端會收到 zookeeper 的通知，而後客戶端能夠根據 znode 變化來作出業務上的改變。

4. zk 的分佈式鎖實現方式

在講zk分佈鎖以前，先看下zookeeper中幾個關於節點的有趣的性質：

1. 有序節點：假如當前有一個父節點爲/lock，咱們能夠在這個父節點下面建立子節點；zookeeper提供了一個可選的有序特性，例如咱們能夠建立子節點「/lock/node-」而且指明有序，那麼zookeeper在生成子節點時會根據當前的子節點數量自動添加整數序號，也就是說若是是第一個建立的子節點，那麼生成的子節點爲/lock/node-0000000000，下一個節點則爲/lock/node-0000000001，依次類推。
2. 臨時節點：客戶端能夠創建一個臨時節點，在會話結束或者會話超時後，zookeeper會自動刪除該節點。
3. 事件監聽：在讀取數據時，咱們能夠同時對節點設置事件監聽，當節點數據或結構變化時，zookeeper會通知客戶端。當前zookeeper有以下四種事件： 一、節點建立；二、節點刪除；三、節點數據修改；四、子節點變動。

下面描述使用zookeeper實現分佈式鎖的算法流程，假設鎖空間的根節點爲/lock：

1. 客戶端鏈接zookeeper，並在/lock下建立臨時的且有序的子節點，第一個客戶端對應的子節點爲/lock/lock-0000000000，第二個爲/lock/lock-0000000001，以此類推。
2. 客戶端獲取/lock下的子節點列表，判斷本身建立的子節點是否爲當前子節點列表中序號最小的子節點，若是是則認爲得到鎖，不然監聽/lock的子節點變動消息，得到子節點變動通知後重復此步驟直至得到鎖；
3. 執行業務代碼；
4. 完成業務流程後，刪除對應的子節點釋放鎖。

5. zk 採用的哪一種分佈式一致性協議? 還有哪些分佈式一致性協議

ZAB(Zookeeper Atomic Broadcast)協議是專門爲zookeeper設計的一致性協議。

ZAB協議包括兩種基本的模式：消息廣播和崩潰恢復

1. 當整個服務框架在啓動過程當中，或是當Leader服務器出現網絡中斷崩潰退出與重啓等異常狀況時，ZAB就會進入恢復模式並選舉產生新的Leader服務器。
2. 當選舉產生了新的Leader服務器，同時集羣中已經有過半的機器與該Leader服務器完成了狀態同步以後，ZAB協議就會退出崩潰恢復模式，進入消息廣播模式。
3. 當有新的服務器加入到集羣中去，若是此時集羣中已經存在一個Leader服務器在負責進行消息廣播，那麼新加入的服務器會自動進入數據恢復模式，找到Leader服務器，並與其進行數據同步，而後一塊兒參與到消息廣播流程中去。

以上其實大體經歷了三個步驟：

1. 崩潰恢復：主要就是Leader選舉過程。
2. 數據同步：Leader服務器與其餘服務器進行數據同步。
3. 消息廣播：Leader服務器將數據發送給其餘服務器。

ZAD和Paxos算法的聯繫和區別

共同點：

1. 二者都存在一個相似於Leader進程的角色，由其負責協調多個Follow進程的運行。
2. Leader進程都會等待超過半數的Follower作出正確的反饋後，纔會將一個提案進行提交。
3. 在ZAB協議中，每一個Proposal中都包含了一個epoch值，用來表明當前Leader週期，在Paxos算法中，一樣存在這樣一個標識，只是名字變成了Ballot。 不一樣點：

Paxos算法中，一個新的選舉產生的主進程會進行兩個階段的工做

1. 讀階段，新的主進程會經過和全部其餘進程進行通訊的方式來蒐集上一個主進程提出的提案，並將它們提交。
2. 寫階段，當前主進程開始提出它本身的提案。
3. 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選舉：

1. 服務器啓動的時候
2. 服務器運行的時候當Leader宕機

在講解流程以前，先說明一下選舉流程中涉及到的角色：

• LOOKING：尋找Leader狀態，處於該狀態須要進入選舉流程（只有該節點才能夠投票）
• LEADING：領導者狀態，處於該狀態的節點說明是角色已是Leader
• FOLLOWING：跟隨者狀態，表示Leader已經選舉出來，當前節點角色是follower
• OBSERVER：觀察者狀態，代表當前節點角色是observer（該節點不參與競選）

三個核心選舉原則：

1. Zookeeper集羣中只有超過半數以上的服務器啓動，集羣才能正常工做；
2. 在集羣正常工做以前，myid小的服務器給myid大的服務器投票，直到集羣正常工做，選出Leader；
3. 選出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。