來自：網(wǎng)絡(luò)

ZooKeeper 是一個開源的分布式協(xié)調(diào)服務(wù)讶泰，屬于面試的熱門考點。發(fā)現(xiàn)一篇很不錯的文章码泞，給大家參考狼犯。
苦于找不到出處，特此感謝此文的作者宋舷。如有老鐵知道出處瓢姻，請留言告知汹来。
前言
ZooKeeper 是一個開源的分布式協(xié)調(diào)服務(wù)，可以基于 ZooKeeper 實現(xiàn)諸如：數(shù)據(jù)發(fā)布/訂閱坟岔、負載均衡摔桦、命名服務(wù)邻耕、分布式協(xié)調(diào)/通知、集群管理啼辣、Master 選舉御滩、配置維護削解，名字服務(wù)、分布式同步腕柜、分布式鎖和分布式隊列等功能。

談下你對 Zookeeper 的認識砰蠢？
ZooKeeper 是一個分布式的蛾找，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)打毛。它是一個為分布式應(yīng)用提供一致性服務(wù)的軟件俩功，提供的功能包括：配置維護、域名服務(wù)熬甫、分布式同步椿肩、組服務(wù)等豺谈。ZooKeeper 的目標就是封裝好復(fù)雜易出錯的關(guān)鍵服務(wù)，將簡單易用的接口和性能高效厂榛、功能穩(wěn)定的系統(tǒng)提供給用戶击奶。

Zookeeper 都有哪些功能责掏？
1. 集群管理：監(jiān)控節(jié)點存活狀態(tài)换衬、運行請求等；
2. 主節(jié)點選舉：主節(jié)點掛掉了之后可以從備用的節(jié)點開始新一輪選主萄唇，主節(jié)點選舉說的就是這個選舉的過程术幔，使用 Zookeeper 可以協(xié)助完成這個過程；
3. 分布式鎖：Zookeeper 提供兩種鎖：獨占鎖四敞、共享鎖忿危。獨占鎖即一次只能有一個線程使用資源，共享鎖是讀鎖共享缎玫，讀寫互斥解滓，即可以有多線線程同時讀同一個資源洼裤，如果要使用寫鎖也只能有一個線程使用。Zookeeper 可以對分布式鎖進行控制值骇。
4. 命名服務(wù)：在分布式系統(tǒng)中吱瘩，通過使用命名服務(wù)桥狡，客戶端應(yīng)用能夠根據(jù)指定名字來獲取資源或服務(wù)的地址部逮，提供者等信息嫂易。

談下你對 ZAB 協(xié)議的了解？
ZAB 協(xié)議是為分布式協(xié)調(diào)服務(wù) Zookeeper 專門設(shè)計的一種支持崩潰恢復(fù)的原子廣播協(xié)議颅和。ZAB 協(xié)議包括兩種基本的模式：崩潰恢復(fù)和消息廣播峡扩。
當整個 Zookeeper 集群剛剛啟動或者Leader服務(wù)器宕機障本、重啟或者網(wǎng)絡(luò)故障導(dǎo)致不存在過半的服務(wù)器與 Leader 服務(wù)器保持正常通信時，所有服務(wù)器進入崩潰恢復(fù)模式案训，首先選舉產(chǎn)生新的 Leader 服務(wù)器强霎，然后集群中 Follower 服務(wù)器開始與新的 Leader 服務(wù)器進行數(shù)據(jù)同步城舞。
當集群中超過半數(shù)機器與該 Leader 服務(wù)器完成數(shù)據(jù)同步之后，退出恢復(fù)模式進入消息廣播模式怕膛，Leader 服務(wù)器開始接收客戶端的事務(wù)請求生成事物提案來進行事務(wù)請求處理秦踪。

Zookeeper 怎么保證主從節(jié)點的狀態(tài)同步椅邓？
Zookeeper 的核心是原子廣播機制昧狮，這個機制保證了各個 server 之間的同步逗鸣。實現(xiàn)這個機制的協(xié)議叫做 Zab 協(xié)議。Zab 協(xié)議有兩種模式透葛，它們分別是恢復(fù)模式和廣播模式僚害。
1. 恢復(fù)模式
當服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后繁调，Zab就進入了恢復(fù)模式蹄胰，當領(lǐng)導(dǎo)者被選舉出來，且大多數(shù) server 完成了和 leader 的狀態(tài)同步以后浩蓉，恢復(fù)模式就結(jié)束了妻往。狀態(tài)同步保證了 leader 和 server 具有相同的系統(tǒng)狀態(tài)。
2. 廣播模式
一旦 leader 已經(jīng)和多數(shù)的 follower 進行了狀態(tài)同步后纫普，它就可以開始廣播消息了好渠，即進入廣播狀態(tài)拳锚。這時候當一個 server 加入 ZooKeeper 服務(wù)中，它會在恢復(fù)模式下啟動匾荆，發(fā)現(xiàn) leader杆烁，并和 leader 進行狀態(tài)同步兔魂。待到同步結(jié)束析校，它也參與消息廣播。ZooKeeper 服務(wù)一直維持在 Broadcast 狀態(tài)遂唧，直到 leader 崩潰了或者 leader 失去了大部分的 followers 支持尚困。

Zookeeper 有幾種部署模式？

Zookeeper 有三種部署模式：1. 單機部署：一臺集群上運行事甜；2. 集群部署：多臺集群運行谬泌；3. 偽集群部署：一臺集群啟動多個 Zookeeper 實例運行。

說一下 Zookeeper 的通知機制逻谦？

client 端會對某個 znode 建立一個 watcher 事件掌实，當該 znode 發(fā)生變化時，這些 client 會收到 zk 的通知邦马，然后 client 可以根據(jù) znode 變化來做出業(yè)務(wù)上的改變等贱鼻。

集群中為什么要有主節(jié)點宴卖？

在分布式環(huán)境中，有些業(yè)務(wù)邏輯只需要集群中的某一臺機器進行執(zhí)行症昏，其他的機器可以共享這個結(jié)果，這樣可以大大減少重復(fù)計算父丰，提高性能肝谭，于是就需要進行 leader 選舉。

集群中有 3 臺服務(wù)器蛾扇，其中一個節(jié)點宕機攘烛，這個時候 Zookeeper 還可以使用嗎？

可以繼續(xù)使用镀首，單數(shù)服務(wù)器只要沒超過一半的服務(wù)器宕機就可以繼續(xù)使用坟漱。集群規(guī)則為 2N+1 臺，N >0更哄，即最少需要 3 臺芋齿。

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

兩階段提交協(xié)議 2PC
1. 第一階段（投票階段）：（1）協(xié)調(diào)者節(jié)點向所有參與者節(jié)點詢問是否可以執(zhí)行提交操作(vote)沟突，并開始等待各參與者節(jié)點的響應(yīng)；（2）參與者節(jié)點執(zhí)行詢問發(fā)起為止的所有事務(wù)操作捕传，并將Undo信息和Redo信息寫入日志。（3）各參與者節(jié)點響應(yīng)協(xié)調(diào)者節(jié)點發(fā)起的詢問扩劝。如果參與者節(jié)點的事務(wù)操作實際執(zhí)行成功庸论，則它返回一個”同意”消息；如果參與者節(jié)點的事務(wù)操作實際執(zhí)行失敗棒呛，則它返回一個”中止”消息聂示。
2. 第二階段（提交執(zhí)行階段）：當協(xié)調(diào)者節(jié)點從所有參與者節(jié)點獲得的相應(yīng)消息都為”同意”時：（1）協(xié)調(diào)者節(jié)點向所有參與者節(jié)點發(fā)出”正式提交(commit)”的請求；（2）參與者節(jié)點正式完成操作簇秒，并釋放在整個事務(wù)期間內(nèi)占用的資源鱼喉；（3）參與者節(jié)點向協(xié)調(diào)者節(jié)點發(fā)送”完成”消息；（4）協(xié)調(diào)者節(jié)點受到所有參與者節(jié)點反饋的”完成”消息后趋观，完成事務(wù)扛禽。兩階段提交存在的問題：1. 執(zhí)行過程中，所有參與節(jié)點都是事務(wù)阻塞型的皱坛。當參與者占有公共資源時编曼，其他第三方節(jié)點訪問公共資源不得不處于阻塞狀態(tài)；2. 參與者發(fā)生故障：協(xié)調(diào)者需要給每個參與者額外指定超時機制剩辟，超時后整個事務(wù)失斊　往扔；3. 協(xié)調(diào)者發(fā)生故障：參與者會一直阻塞下去。需要額外的備機進行容錯熊户；4. 二階段無法解決的問題：協(xié)調(diào)者再發(fā)出 commit 消息之后宕機萍膛，而唯一接收到這條消息的參與者同時也宕機了。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者嚷堡，這條事務(wù)的狀態(tài)也是不確定的蝗罗，沒人知道事務(wù)是否被已經(jīng)提交。三階段提交協(xié)議 3PC與兩階段提交不同的是麦到，三階段提交有兩個改動點：1. 引入超時機制绿饵。同時在協(xié)調(diào)者和參與者中都引入超時機制；2. 在第一階段和第二階段中插入一個準備階段瓶颠。保證了在最后提交階段之前各參與節(jié)點的狀態(tài)是一致的拟赊。也就是說，除了引入超時機制之外粹淋，3PC 把 2PC 的準備階段再次一分為二吸祟，這樣三階段提交就有 CanCommit、PreCommit桃移、DoCommit 三個階段屋匕。
1. CanCommit 階段3PC 的 CanCommit 階段其實和 2PC 的準備階段很像。協(xié)調(diào)者向參與者發(fā)送 commit 請求借杰，參與者如果可以提交就返回 Yes 響應(yīng)过吻，否則返回 No 響應(yīng)。（1）事務(wù)詢問：協(xié)調(diào)者向參與者發(fā)送 CanCommit 請求蔗衡。詢問是否可以執(zhí)行事務(wù)提交操作纤虽。然后開始等待參與者的響應(yīng)。（2）響應(yīng)反饋：參與者接到 CanCommit 請求之后绞惦，正常情況下逼纸，如果其自身認為可以順利執(zhí)行事務(wù)，則返回 Yes 響應(yīng)济蝉，并進入預(yù)備狀態(tài)杰刽。否則反饋 No。2. PreCommit 階段協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以繼續(xù)事務(wù)的 PreCommit 操作王滤。根據(jù)響應(yīng)情況贺嫂，有以下兩種可能：假如協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)，那么就會執(zhí)行事務(wù)的預(yù)執(zhí)行淑仆。（1）發(fā)送預(yù)提交請求：協(xié)調(diào)者向參與者發(fā)送 PreCommit 請求涝婉，并進入 Prepared 階段。（2）事務(wù)預(yù)提交：參與者接收到 PreCommit 請求后蔗怠，會執(zhí)行事務(wù)操作墩弯，并將 undo 和 redo 信息記錄到事務(wù)日志中吩跋。（3）響應(yīng)反饋：如果參與者成功的執(zhí)行了事務(wù)操作，則返回 ACK 響應(yīng)渔工，同時開始等待最終指令锌钮。
假如有任何一個參與者向協(xié)調(diào)者發(fā)送了 No 響應(yīng)，或者等待超時之后引矩，協(xié)調(diào)者都沒有接到參與者的響應(yīng)梁丘，那么就執(zhí)行事務(wù)的中斷。（1）發(fā)送中斷請求：協(xié)調(diào)者向所有參與者發(fā)送 abort 請求旺韭。（2）中斷事務(wù)：參與者收到來自協(xié)調(diào)者的 abort 請求之后（或超時之后氛谜，仍未收到協(xié)調(diào)者的請求），執(zhí)行事務(wù)的中斷区端。
3. doCommit 階段該階段進行真正的事務(wù)提交值漫，也可以分為以下兩種情況。
3.1 執(zhí)行提交（1）發(fā)送提交請求：協(xié)調(diào)接收到參與者發(fā)送的 ACK 響應(yīng)织盼，那么他將從預(yù)提交狀態(tài)進入到提交狀態(tài)杨何。并向所有參與者發(fā)送 doCommit 請求。（2）事務(wù)提交：參與者接收到 doCommit 請求之后沥邻，執(zhí)行正式的事務(wù)提交危虱。并在完成事務(wù)提交之后釋放所有事務(wù)資源。
（3）響應(yīng)反饋：事務(wù)提交完之后唐全，向協(xié)調(diào)者發(fā)送 ACK 響應(yīng)埃跷。
（4）完成事務(wù)：協(xié)調(diào)者接收到所有參與者的 ACK 響應(yīng)之后，完成事務(wù)邮利。
3.2 中斷事務(wù)
協(xié)調(diào)者沒有接收到參與者發(fā)送的 ACK 響應(yīng)（可能是接受者發(fā)送的不是 ACK 響應(yīng)捌蚊，也可能響應(yīng)超時），那么就會執(zhí)行中斷事務(wù)近弟。
（1）發(fā)送中斷請求：協(xié)調(diào)者向所有參與者發(fā)送 abort 請求。
（2）事務(wù)回滾：參與者接收到 abort 請求之后挺智，利用其在階段二記錄的 undo 信息來執(zhí)行事務(wù)的回滾操作祷愉，并在完成回滾之后釋放所有的事務(wù)資源。
（3）反饋結(jié)果：參與者完成事務(wù)回滾之后赦颇，向協(xié)調(diào)者發(fā)送 ACK 消息二鳄。
（4）中斷事務(wù)：協(xié)調(diào)者接收到參與者反饋的 ACK 消息之后，執(zhí)行事務(wù)的中斷媒怯。
三階段提交的問題：
網(wǎng)絡(luò)分區(qū)可能會帶來問題订讼。需要四階段解決：四階段直接調(diào)用遠程服務(wù)的數(shù)據(jù)狀態(tài)，確定當前數(shù)據(jù)一致性的情況扇苞。

Zookeeper 宕機如何處理欺殿？

Zookeeper 本身也是集群寄纵，推薦配置不少于 3 個服務(wù)器。Zookeeper 自身也要保證當一個節(jié)點宕機時脖苏，其他節(jié)點會繼續(xù)提供服務(wù)程拭。如果是一個 Follower 宕機，還有 2 臺服務(wù)器提供訪問棍潘，因為 Zookeeper 上的數(shù)據(jù)是有多個副本的恃鞋，數(shù)據(jù)并不會丟失；如果是一個 Leader 宕機亦歉，Zookeeper 會選舉出新的 Leader恤浪。Zookeeper 集群的機制是只要超過半數(shù)的節(jié)點正常，集群就能正常提供服務(wù)肴楷。只有在 Zookeeper 節(jié)點掛得太多水由，只剩一半或不到一半節(jié)點能工作，集群才失效阶祭。所以：3 個節(jié)點的 cluster 可以掛掉 1 個節(jié)點(leader 可以得到 2 票 > 1.5)2 個節(jié)點的 cluster 就不能掛掉任何1個節(jié)點了(leader 可以得到 1 票 <= 1)11. 說下四種類型的數(shù)據(jù)節(jié)點 Znode绷杜？1. PERSISTENT：持久節(jié)點，除非手動刪除濒募，否則節(jié)點一直存在于 Zookeeper 上鞭盟。2. EPHEMERAL：臨時節(jié)點，臨時節(jié)點的生命周期與客戶端會話綁定瑰剃，一旦客戶端會話失效（客戶端與 Zookeeper連接斷開不一定會話失效）齿诉，那么這個客戶端創(chuàng)建的所有臨時節(jié)點都會被移除。3. PERSISTENT_SEQUENTIAL：持久順序節(jié)點晌姚，基本特性同持久節(jié)點粤剧，只是增加了順序?qū)傩裕?jié)點名后邊會追加一個由父節(jié)點維護的自增整型數(shù)字挥唠。4. EPHEMERAL_SEQUENTIAL：臨時順序節(jié)點抵恋，基本特性同臨時節(jié)點，增加了順序?qū)傩员δィ?jié)點名后邊會追加一個由父節(jié)點維護的自增整型數(shù)字弧关。

Zookeeper 和 Dubbo 的關(guān)系？

Dubbo 的將注冊中心進行抽象唤锉，是得它可以外接不同的存儲媒介給注冊中心提供服務(wù)世囊，有 ZooKeeper，Memcached窿祥，Redis 等株憾。
引入了 ZooKeeper 作為存儲媒介，也就把 ZooKeeper 的特性引進來晒衩。首先是負載均衡嗤瞎，單注冊中心的承載能力是有限的墙歪，在流量達到一定程度的時 候就需要分流，負載均衡就是為了分流而存在的猫胁，一個 ZooKeeper 群配合相應(yīng)的 Web 應(yīng)用就可以很容易達到負載均衡箱亿；資源同步，單單有負載均衡還不 夠弃秆，節(jié)點之間的數(shù)據(jù)和資源需要同步届惋，ZooKeeper 集群就天然具備有這樣的功能；命名服務(wù)菠赚，將樹狀結(jié)構(gòu)用于維護全局的服務(wù)地址列表脑豹，服務(wù)提供者在啟動 的時候，向 ZooKeeper 上的指定節(jié)點 /dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址衡查，這個操作就完成了服務(wù)的發(fā)布瘩欺。 其他特性還有 Mast 選舉，分布式鎖等拌牲。

image