面試完騰訊，總結了這12道Zookeeper面試題！

前言

ZooKeeper 是一個開源的分佈式協調服務，能夠基於 ZooKeeper 實現諸如：數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master 選舉、配置維護，名字服務、分佈式同步、分佈式鎖和分佈式隊列等功能。

談下你對 Zookeeper 的認識？

ZooKeeper 是一個分佈式的，開放源碼的分佈式應用程序協調服務。它是一個爲分佈式應用提供一致性的服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。

ZooKeeper 的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

Zookeeper 都有哪些功能？

1. 集羣管理：監控節點存活狀態、運行請求等；

2. 主節點選舉：主節點掛掉了以後能夠從備用的節點開始新一輪選主，主節點選舉說的就是這個選舉的過程，使用 Zookeeper 能夠協助完成這個過程；

3. 分佈式鎖：Zookeeper 提供兩種鎖：獨佔鎖、共享鎖。獨佔鎖即一次只能有一個線程使用資源，共享鎖是讀鎖共享，讀寫互斥，便可以有多線線程同時讀同一個資源，若是要使用寫鎖也只能有一個線程使用。Zookeeper 能夠對分佈式鎖進行控制。

4. 命名服務：在分佈式系統中，經過使用命名服務，客戶端應用可以根據指定名字來獲取資源或服務的地址，提供者等信息。

談下你對 ZAB 協議的瞭解？

ZAB 協議是爲分佈式協調服務 Zookeeper 專門設計的一種支持崩潰恢復的原子廣播協議。ZAB 協議包括兩種基本的模式：崩潰恢復和消息廣播。

當整個 Zookeeper 集羣剛剛啓動或者Leader服務器宕機、重啓或者網絡故障致使不存在過半的服務器與 Leader 服務器保持正常通訊時，全部服務器進入崩潰恢復模式，首先選舉產生新的 Leader 服務器，而後集羣中 Follower 服務器開始與新的 Leader 服務器進行數據同步。當集羣中超過半數機器與該 Leader 服務器完成數據同步以後，退出恢復模式進入消息廣播模式，Leader 服務器開始接收客戶端的事務請求生成事物提案來進行事務請求處理。

Zookeeper 怎麼保證主從節點的狀態同步？

Zookeeper 的核心是原子廣播機制，這個機制保證了各個 server 之間的同步。實現這個機制的協議叫作 Zab 協議。Zab 協議有兩種模式，它們分別是恢復模式和廣播模式。

1. 恢復模式

當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數 server 完成了和 leader 的狀態同步之後，恢復模式就結束了。狀態同步保證了 leader 和 server 具備相同的系統狀態。

2. 廣播模式

一旦 leader 已經和多數的 follower 進行了狀態同步後，它就能夠開始廣播消息了，即進入廣播狀態。這時候當一個 server 加入 ZooKeeper 服務中，它會在恢復模式下啓動，發現 leader，並和 leader 進行狀態同步。待到同步結束，它也參與消息廣播。ZooKeeper 服務一直維持在 Broadcast 狀態，直到 leader 崩潰了或者 leader 失去了大部分的 followers 支持。

Zookeeper 有幾種部署模式？

Zookeeper 有三種部署模式：

1. 單機部署：一臺集羣上運行；

2. 集羣部署：多臺集羣運行；

3. 僞集羣部署：一臺集羣啓動多個 Zookeeper 實例運行。

說一下 Zookeeper 的通知機制？

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

集羣中爲何要有主節點？

在分佈式環境中，有些業務邏輯只須要集羣中的某一臺機器進行執行，其餘的機器能夠共享這個結果，這樣能夠大大減小重複計算，提升性能，因而就須要進行 leader 選舉。

集羣中有 3 臺服務器，其中一個節點宕機，這個時候 Zookeeper 還可使用嗎？

能夠繼續使用，單數服務器只要沒超過一半的服務器宕機就能夠繼續使用。

集羣規則爲 2N+1 臺，N >0，即最少須要 3 臺。歡迎你們關注個人公種浩【程序員追風】，文章都會在裏面更新，整理的資料也會放在裏面。

說一下兩階段提交和三階段提交的過程？分別有什麼問題？

兩階段提交協議 2PC

1. 第一階段（投票階段）：

（1）協調者節點向全部參與者節點詢問是否能夠執行提交操做(vote)，並開始等待各參與者節點的響應；

（2）參與者節點執行詢問發起爲止的全部事務操做，並將Undo信息和Redo信息寫入日誌。 （3）各參與者節點響應協調者節點發起的詢問。若是參與者節點的事務操做實際執行成功，則它返回一個」贊成」消息；若是參與者節點的事務操做實際執行失敗，則它返回一個」停止」消息。

2. 第二階段（提交執行階段）： 當協調者節點從全部參與者節點得到的相應消息都爲」贊成」時：

（1）協調者節點向全部參與者節點發出」正式提交(commit)」的請求；

（2）參與者節點正式完成操做，並釋放在整個事務期間內佔用的資源；

（3）參與者節點向協調者節點發送」完成」消息；

（4）協調者節點受到全部參與者節點反饋的」完成」消息後，完成事務。

兩階段提交存在的問題：

1. 執行過程當中，全部參與節點都是事務阻塞型的。當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態；

2. 參與者發生故障：協調者須要給每一個參與者額外指定超時機制，超時後整個事務失敗；

3. 協調者發生故障：參與者會一直阻塞下去。須要額外的備機進行容錯；

4. 二階段沒法解決的問題：協調者再發出 commit 消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了。那麼即便協調者經過選舉協議產生了新的協調者，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。

三階段提交協議 3PC

與兩階段提交不一樣的是，三階段提交有兩個改動點：

1. 引入超時機制。同時在協調者和參與者中都引入超時機制；

2. 在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。

也就是說，除了引入超時機制以外，3PC 把 2PC 的準備階段再次一分爲二，這樣三階段提交就有 CanCommit、PreCommit、DoCommit 三個階段。

1. CanCommit 階段 3PC 的 CanCommit 階段其實和 2PC 的準備階段很像。協調者向參與者發送 commit 請求，參與者若是能夠提交就返回 Yes 響應，不然返回 No 響應。

（1）事務詢問：協調者向參與者發送 CanCommit 請求。詢問是否能夠執行事務提交操做。而後開始等待參與者的響應。

（2）響應反饋：參與者接到 CanCommit 請求以後，正常狀況下，若是其自身認爲能夠順利執行事務，則返回 Yes 響應，並進入預備狀態。不然反饋 No。

2. PreCommit 階段 協調者根據參與者的反應狀況來決定是否能夠繼續事務的 PreCommit 操做。根據響應狀況，有如下兩種可能：

假如協調者從全部的參與者得到的反饋都是 Yes 響應，那麼就會執行事務的預執行。

（1）發送預提交請求：協調者向參與者發送 PreCommit 請求，並進入 Prepared 階段。

（2）事務預提交：參與者接收到 PreCommit 請求後，會執行事務操做，並將 undo 和 redo 信息記錄到事務日誌中。 （3）響應反饋：若是參與者成功的執行了事務操做，則返回 ACK 響應，同時開始等待最終指令。

假若有任何一個參與者向協調者發送了 No 響應，或者等待超時以後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。 （1）發送中斷請求：協調者向全部參與者發送 abort 請求。 （2）中斷事務：參與者收到來自協調者的 abort 請求以後（或超時以後，仍未收到協調者的請求），執行事務的中斷。

3. doCommit 階段 該階段進行真正的事務提交，也能夠分爲如下兩種狀況。

3.1 執行提交

（1）發送提交請求：協調接收到參與者發送的 ACK 響應，那麼他將從預提交狀態進入到提交狀態。並向全部參與者發送 doCommit 請求。

（2）事務提交：參與者接收到 doCommit 請求以後，執行正式的事務提交。並在完成事務提交以後釋放全部事務資源。

（3）響應反饋：事務提交完以後，向協調者發送 ACK 響應。

（4）完成事務：協調者接收到全部參與者的 ACK 響應以後，完成事務。

3.2 中斷事務

協調者沒有接收到參與者發送的 ACK 響應（多是接受者發送的不是 ACK 響應，也可能響應超時），那麼就會執行中斷事務。

（1）發送中斷請求：協調者向全部參與者發送 abort 請求。

（2）事務回滾：參與者接收到 abort 請求以後，利用其在階段二記錄的 undo 信息來執行事務的回滾操做，並在完成回滾以後釋放全部的事務資源。

（3）反饋結果：參與者完成事務回滾以後，向協調者發送 ACK 消息。

（4）中斷事務：協調者接收到參與者反饋的 ACK 消息以後，執行事務的中斷。

三階段提交的問題：

網絡分區可能會帶來問題。須要四階段解決：四階段直接調用遠程服務的數據狀態，肯定當前數據一致性的狀況。

Zookeeper 宕機如何處理？

Zookeeper 自己也是集羣，推薦配置很多於 3 個服務器。Zookeeper 自身也要保證當一個節點宕機時，其餘節點會繼續提供服務。若是是一個 Follower 宕機，還有 2 臺服務器提供訪問，由於 Zookeeper 上的數據是有多個副本的，數據並不會丟失；若是是一個 Leader 宕機，Zookeeper 會選舉出新的 Leader。

Zookeeper 集羣的機制是隻要超過半數的節點正常，集羣就能正常提供服務。只有在 Zookeeper 節點掛得太多，只剩一半或不到一半節點能工做，集羣才失效。因此：

3 個節點的 cluster 能夠掛掉 1 個節點(leader 能夠獲得 2 票 > 1.5)

2 個節點的 cluster 就不能掛掉任何1個節點了(leader 能夠獲得 1 票 <= 1)

11. 說下四種類型的數據節點 Znode？

1. PERSISTENT：持久節點，除非手動刪除，不然節點一直存在於 Zookeeper 上。

2. EPHEMERAL：臨時節點，臨時節點的生命週期與客戶端會話綁定，一旦客戶端會話失效（客戶端與 Zookeeper鏈接斷開不必定會話失效），那麼這個客戶端建立的全部臨時節點都會被移除。

3. PERSISTENT_SEQUENTIAL：持久順序節點，基本特性同持久節點，只是增長了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。

4. EPHEMERAL_SEQUENTIAL：臨時順序節點，基本特性同臨時節點，增長了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。

Zookeeper 和 Dubbo 的關係？

Dubbo 的將註冊中心進行抽象，是得它能夠外接不一樣的存儲媒介給註冊中心提供服務，有 ZooKeeper，Memcached，Redis 等。

引入了 ZooKeeper 做爲存儲媒介，也就把 ZooKeeper 的特性引進來。首先是負載均衡，單註冊中心的承載能力是有限的，在流量達到必定程度的時 候就須要分流，負載均衡就是爲了分流而存在的，一個 ZooKeeper 羣配合相應的 Web 應用就能夠很容易達到負載均衡；資源同步，單單有負載均衡還不 夠，節點之間的數據和資源須要同步，ZooKeeper 集羣就自然具有有這樣的功能；命名服務，將樹狀結構用於維護全局的服務地址列表，服務提供者在啓動 的時候，向 ZooKeeper 上的指定節點 /dubbo/${serviceName}/providers 目錄下寫入本身的 URL 地址，這個操做就完成了服務的發佈。 其餘特性還有 Mast 選舉，分佈式鎖等。

最後

歡迎你們一塊兒交流，喜歡文章記得關注我點個贊喲，感謝支持！