ZooKeeper 是一個(gè)分布式的无切，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)。它是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的軟件啡省，提供的功能包括：配置維護(hù)娜睛、域名服務(wù)髓霞、分布式同步、組服務(wù)等畦戒。ZooKeeper 的目標(biāo)就是封裝好復(fù)雜易出錯(cuò)的關(guān)鍵服務(wù)方库，將簡單易用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶障斋。
ZooKeeper 面試題1. ZooKeeper 面試題纵潦？2. ZooKeeper 提供了什么？3. Zookeeper 文件系統(tǒng)4. ZAB 協(xié)議垃环？5. 四種類型的數(shù)據(jù)節(jié)點(diǎn) Znode6. Zookeeper Watcher 機(jī)制 -- 數(shù)據(jù)變更通知7. 客戶端注冊 Watcher 實(shí)現(xiàn)8. 服務(wù)端處理 Watcher 實(shí)現(xiàn)9. 客戶端回調(diào) Watcher10. ACL 權(quán)限控制機(jī)制11. Chroot 特性12. 會話管理13. 服務(wù)器角色14. Zookeeper 下 Server 工作狀態(tài)15. 數(shù)據(jù)同步16. zookeeper 是如何保證事務(wù)的順序一致性的邀层？17. 分布式集群中為什么會有 Master？18. zk 節(jié)點(diǎn)宕機(jī)如何處理遂庄？19. zookeeper 負(fù)載均衡和 nginx 負(fù)載均衡區(qū)別20. Zookeeper 有哪幾種幾種部署模式寥院？21. 集群最少要幾臺機(jī)器，集群規(guī)則是怎樣的?22. 集群支持動(dòng)態(tài)添加機(jī)器嗎涛目？23. Zookeeper 對節(jié)點(diǎn)的 watch 監(jiān)聽通知是永久的嗎秸谢？為什么不是永久的?24. Zookeeper 的 java 客戶端都有哪些？25. chubby 是什么霹肝，和 zookeeper 比你怎么看估蹄？26. 說幾個(gè) zookeeper 常用的命令。27. ZAB 和 Paxos 算法的聯(lián)系與區(qū)別沫换？28. Zookeeper 的典型應(yīng)用場景

ZooKeeper面試題答案解析

1. ZooKeeper 是什么臭蚁？

ZooKeeper 是一個(gè)開放源碼的分布式協(xié)調(diào)服務(wù)，它是集群的管理者苗沧，監(jiān)視著集群中各個(gè)節(jié)點(diǎn)的狀態(tài)根據(jù)節(jié)點(diǎn)提交的反饋進(jìn)行下一步合理操作刊棕。最終，將簡單易用的接口和性能高效待逞、功能穩(wěn)定的系統(tǒng)提供給用戶甥角。

分布式應(yīng)用程序可以基于 Zookeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱恬叹、負(fù)載均衡晚岭、命名服務(wù)、分布式協(xié)調(diào)/通知对雪、集群管理怜庸、Master 選舉当犯、分布式鎖和分布式隊(duì)列等功能。

Zookeeper 保證了如下分布式一致性特性：

（1）順序一致性

（2）原子性

（3）單一視圖

（4）可靠性

（5）實(shí)時(shí)性（最終一致性）

客戶端的讀請求可以被集群中的任意一臺機(jī)器處理割疾，如果讀請求在節(jié)點(diǎn)上注冊了監(jiān)聽器嚎卫，這個(gè)監(jiān)聽器也是由所連接的 zookeeper 機(jī)器來處理。對于寫請求宏榕，這些請求會同時(shí)發(fā)給其他 zookeeper 機(jī)器并且達(dá)成一致后拓诸，請求才會返回成功侵佃。因此，隨著 zookeeper 的集群機(jī)器增多奠支，讀請求的吞吐會提高但是寫請求的吞吐會下降馋辈。

有序性是 zookeeper 中非常重要的一個(gè)特性，所有的更新都是全局有序的倍谜，每個(gè)更新都有一個(gè)唯一的時(shí)間戳迈螟，這個(gè)時(shí)間戳稱為 zxid（Zookeeper Transaction Id）。而讀請求只會相對于更新有序尔崔，也就是讀請求的返回結(jié)果中會帶有這個(gè)zookeeper 最新的 zxid答毫。

2. ZooKeeper 提供了什么？

（1）文件系統(tǒng)

（2）通知機(jī)制

3.Zookeeper 文件系統(tǒng)

Zookeeper 提供一個(gè)多層級的節(jié)點(diǎn)命名空間（節(jié)點(diǎn)稱為 znode）您旁。與文件系統(tǒng)不同的是烙常，這些節(jié)點(diǎn)都可以設(shè)置關(guān)聯(lián)的數(shù)據(jù)，而文件系統(tǒng)中只有文件節(jié)點(diǎn)可以存放數(shù)據(jù)而目錄節(jié)點(diǎn)不行鹤盒。

Zookeeper 為了保證高吞吐和低延遲蚕脏，在內(nèi)存中維護(hù)了這個(gè)樹狀的目錄結(jié)構(gòu)，這種特性使得 Zookeeper 不能用于存放大量的數(shù)據(jù)侦锯，每個(gè)節(jié)點(diǎn)的存放數(shù)據(jù)上限為1M驼鞭。

4. ZAB 協(xié)議？

ZAB 協(xié)議是為分布式協(xié)調(diào)服務(wù) Zookeeper 專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議尺碰。

ZAB 協(xié)議包括兩種基本的模式：崩潰恢復(fù)和消息廣播挣棕。

當(dāng)整個(gè) zookeeper 集群剛剛啟動(dòng)或者 Leader 服務(wù)器宕機(jī)、重啟或者網(wǎng)絡(luò)故障導(dǎo)致不存在過半的服務(wù)器與 Leader 服務(wù)器保持正常通信時(shí)亲桥，所有進(jìn)程（服務(wù)器）進(jìn)入崩潰恢復(fù)模式洛心，首先選舉產(chǎn)生新的 Leader 服務(wù)器，然后集群中 Follower 服務(wù)器開始與新的 Leader 服務(wù)器進(jìn)行數(shù)據(jù)同步题篷，當(dāng)集群中超過半數(shù)機(jī)器與該 Leader服務(wù)器完成數(shù)據(jù)同步之后词身，退出恢復(fù)模式進(jìn)入消息廣播模式，Leader 服務(wù)器開始接收客戶端的事務(wù)請求生成事物提案來進(jìn)行事務(wù)請求處理番枚。

5. 四種類型的數(shù)據(jù)節(jié)點(diǎn) Znode

（1）PERSISTENT-持久節(jié)點(diǎn)

除非手動(dòng)刪除法严，否則節(jié)點(diǎn)一直存在于 Zookeeper 上

（2）EPHEMERAL-臨時(shí)節(jié)點(diǎn)

臨時(shí)節(jié)點(diǎn)的生命周期與客戶端會話綁定，一旦客戶端會話失效（客戶端與zookeeper 連接斷開不一定會話失效）葫笼，那么這個(gè)客戶端創(chuàng)建的所有臨時(shí)節(jié)點(diǎn)都會被移除深啤。

（3）PERSISTENT_SEQUENTIAL-持久順序節(jié)點(diǎn)

基本特性同持久節(jié)點(diǎn)，只是增加了順序?qū)傩月沸牵?jié)點(diǎn)名后邊會追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字溯街。

（4）EPHEMERAL_SEQUENTIAL-臨時(shí)順序節(jié)點(diǎn)

基本特性同臨時(shí)節(jié)點(diǎn)，增加了順序?qū)傩裕?jié)點(diǎn)名后邊會追加一個(gè)由父節(jié)點(diǎn)維護(hù)的自增整型數(shù)字苫幢。

6. Zookeeper Watcher 機(jī)制 -- 數(shù)據(jù)變更通知

Zookeeper 允許客戶端向服務(wù)端的某個(gè) Znode 注冊一個(gè) Watcher 監(jiān)聽访诱，當(dāng)服務(wù)端的一些指定事件觸發(fā)了這個(gè) Watcher，服務(wù)端會向指定客戶端發(fā)送一個(gè)事件通知來實(shí)現(xiàn)分布式的通知功能韩肝，然后客戶端根據(jù) Watcher 通知狀態(tài)和事件類型做出業(yè)務(wù)上的改變。

工作機(jī)制：

（1）客戶端注冊 watcher

（2）服務(wù)端處理 watcher

（3）客戶端回調(diào) watcher

Watcher 特性總結(jié)：

（1）一次性

無論是服務(wù)端還是客戶端九榔，一旦一個(gè) Watcher 被 觸 發(fā) 哀峻，Zookeeper 都會將其從相應(yīng)的存儲中移除。這樣的設(shè)計(jì)有效的減輕了服務(wù)端的壓力哲泊，不然對于更新非常頻繁的節(jié)點(diǎn)剩蟀，服務(wù)端會不斷的向客戶端發(fā)送事件通知，無論對于網(wǎng)絡(luò)還是服務(wù)端的壓力都非常大切威。

（2）客戶端串行執(zhí)行

客戶端 Watcher 回調(diào)的過程是一個(gè)串行同步的過程育特。

（3）輕量

3.1、Watcher 通知非常簡單先朦，只會告訴客戶端發(fā)生了事件缰冤，而不會說明事件的具體內(nèi)容。

3.2喳魏、客戶端向服務(wù)端注冊 Watcher 的時(shí)候棉浸，并不會把客戶端真實(shí)的 Watcher 對象實(shí)體傳遞到服務(wù)端，僅僅是在客戶端請求中使用 boolean 類型屬性進(jìn)行了標(biāo)記刺彩。

（4）watcher event 異步發(fā)送 watcher 的通知事件從 server 發(fā)送到 client 是異步的迷郑，這就存在一個(gè)問題，不同的客戶端和服務(wù)器之間通過 socket 進(jìn)行通信创倔，由于網(wǎng)絡(luò)延遲或其他因素導(dǎo)致客戶端在不通的時(shí)刻監(jiān)聽到事件嗡害，由于 Zookeeper 本身提供了 ordering guarantee，即客戶端監(jiān)聽事件后畦攘，才會感知它所監(jiān)視 znode發(fā)生了變化霸妹。所以我們使用 Zookeeper 不能期望能夠監(jiān)控到節(jié)點(diǎn)每次的變化。Zookeeper 只能保證最終的一致性念搬，而無法保證強(qiáng)一致性抑堡。

（5）注冊 watcher getData、exists朗徊、getChildren

（6）觸發(fā) watcher create首妖、delete、setData

（7）當(dāng)一個(gè)客戶端連接到一個(gè)新的服務(wù)器上時(shí)爷恳，watch 將會被以任意會話事件觸發(fā)有缆。當(dāng)與一個(gè)服務(wù)器失去連接的時(shí)候，是無法接收到 watch 的。而當(dāng) client 重新連接時(shí)棚壁，如果需要的話杯矩，所有先前注冊過的 watch，都會被重新注冊袖外。通常這是完全透明的史隆。只有在一個(gè)特殊情況下，watch 可能會丟失：對于一個(gè)未創(chuàng)建的 znode的 exist watch曼验，如果在客戶端斷開連接期間被創(chuàng)建了泌射，并且隨后在客戶端連接上之前又刪除了，這種情況下鬓照，這個(gè) watch 事件可能會被丟失熔酷。

7. 客戶端注冊 Watcher 實(shí)現(xiàn)

（1）調(diào)用 getData()/getChildren()/exist()三個(gè) API，傳入 Watcher 對象

（2）標(biāo)記請求 request豺裆，封裝 Watcher 到 WatchRegistration

（3）封裝成 Packet 對象拒秘，發(fā)服務(wù)端發(fā)送 request

（4）收到服務(wù)端響應(yīng)后，將 Watcher 注冊到 ZKWatcherManager 中進(jìn)行管理

（5）請求返回臭猜，完成注冊躺酒。

8. 服務(wù)端處理 Watcher 實(shí)現(xiàn)

（1）服務(wù)端接收 Watcher 并存儲

接收到客戶端請求，處理請求判斷是否需要注冊 Watcher获讳，需要的話將數(shù)據(jù)節(jié)點(diǎn)的節(jié)點(diǎn)路徑和 ServerCnxn（ServerCnxn 代表一個(gè)客戶端和服務(wù)端的連接阴颖，實(shí)現(xiàn)了 Watcher 的 process 接口，此時(shí)可以看成一個(gè) Watcher 對象）存儲在WatcherManager 的 WatchTable 和 watch2Paths 中去丐膝。

（2）Watcher 觸發(fā)

以服務(wù)端接收到 setData() 事務(wù)請求觸發(fā) NodeDataChanged 事件為例：

2.1 封裝 WatchedEvent

將通知狀態(tài)（SyncConnected）量愧、事件類型（NodeDataChanged）以及節(jié)點(diǎn)路徑封裝成一個(gè) WatchedEvent 對象

2.2 查詢 Watcher

從 WatchTable 中根據(jù)節(jié)點(diǎn)路徑查找 Watcher

2.3 沒找到；說明沒有客戶端在該數(shù)據(jù)節(jié)點(diǎn)上注冊過 Watcher

2.4 找到帅矗；提取并從 WatchTable 和 Watch2Paths 中刪除對應(yīng) Watcher（從這里可以看出 Watcher 在服務(wù)端是一次性的偎肃，觸發(fā)一次就失效了）

（3）調(diào)用 process 方法來觸發(fā) Watcher

這里 process 主要就是通過 ServerCnxn 對應(yīng)的 TCP 連接發(fā)送 Watcher 事件通知。

9. 客戶端回調(diào) Watcher

客戶端 SendThread 線程接收事件通知浑此，交由 EventThread 線程回調(diào) Watcher累颂。

客戶端的 Watcher 機(jī)制同樣是一次性的，一旦被觸發(fā)后凛俱，該 Watcher 就失效了紊馏。

10. ACL 權(quán)限控制機(jī)制

UGO（User/Group/Others）

目前在 Linux/Unix 文件系統(tǒng)中使用，也是使用最廣泛的權(quán)限控制方式蒲犬。是一種粗粒度的文件系統(tǒng)權(quán)限控制模式朱监。

ACL（Access Control List）訪問控制列表

包括三個(gè)方面：

權(quán)限模式（Scheme）

（1）IP：從 IP 地址粒度進(jìn)行權(quán)限控制

（2）Digest：最常用，用類似于 username:password 的權(quán)限標(biāo)識來進(jìn)行權(quán)限配置原叮，便于區(qū)分不同應(yīng)用來進(jìn)行權(quán)限控制

（3）World：最開放的權(quán)限控制方式赫编，是一種特殊的 digest 模式巡蘸，只有一個(gè)權(quán)限標(biāo)識“world:anyone”

（4）Super：超級用戶

授權(quán)對象

授權(quán)對象指的是權(quán)限賦予的用戶或一個(gè)指定實(shí)體，例如 IP 地址或是機(jī)器燈擂送。

權(quán)限 Permission

（1）CREATE：數(shù)據(jù)節(jié)點(diǎn)創(chuàng)建權(quán)限悦荒，允許授權(quán)對象在該 Znode 下創(chuàng)建子節(jié)點(diǎn)

（2）DELETE：子節(jié)點(diǎn)刪除權(quán)限，允許授權(quán)對象刪除該數(shù)據(jù)節(jié)點(diǎn)的子節(jié)點(diǎn)

（3）READ：數(shù)據(jù)節(jié)點(diǎn)的讀取權(quán)限嘹吨，允許授權(quán)對象訪問該數(shù)據(jù)節(jié)點(diǎn)并讀取其數(shù)據(jù)內(nèi)容或子節(jié)點(diǎn)列表等

（4）WRITE：數(shù)據(jù)節(jié)點(diǎn)更新權(quán)限搬味，允許授權(quán)對象對該數(shù)據(jù)節(jié)點(diǎn)進(jìn)行更新操作

（5）ADMIN：數(shù)據(jù)節(jié)點(diǎn)管理權(quán)限，允許授權(quán)對象對該數(shù)據(jù)節(jié)點(diǎn)進(jìn)行 ACL 相關(guān)設(shè)置操作

11. Chroot 特性

3.2.0 版本后躺苦，添加了 Chroot 特性身腻，該特性允許每個(gè)客戶端為自己設(shè)置一個(gè)命名空間。如果一個(gè)客戶端設(shè)置了 Chroot匹厘，那么該客戶端對服務(wù)器的任何操作，都將會被限制在其自己的命名空間下脐区。

通過設(shè)置 Chroot愈诚，能夠?qū)⒁粋€(gè)客戶端應(yīng)用于 Zookeeper 服務(wù)端的一顆子樹相對應(yīng)，在那些多個(gè)應(yīng)用公用一個(gè) Zookeeper 進(jìn)群的場景下牛隅，對實(shí)現(xiàn)不同應(yīng)用間的相互隔離非常有幫助炕柔。

12. 會話管理

分桶策略：將類似的會話放在同一區(qū)塊中進(jìn)行管理，以便于 Zookeeper 對會話進(jìn)行不同區(qū)塊的隔離處理以及同一區(qū)塊的統(tǒng)一處理媒佣。

分配原則：每個(gè)會話的“下次超時(shí)時(shí)間點(diǎn)”（ExpirationTime）

計(jì)算公式：

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

ExpirationInterval , ExpirationInterval 是指 Zookeeper 會話超時(shí)檢查時(shí)間間隔匕累，默認(rèn) tickTime

13. 服務(wù)器角色

Leader

（1）事務(wù)請求的唯一調(diào)度和處理者，保證集群事務(wù)處理的順序性

（2）集群內(nèi)部各服務(wù)的調(diào)度者

Follower

（1）處理客戶端的非事務(wù)請求默伍，轉(zhuǎn)發(fā)事務(wù)請求給 Leader 服務(wù)器

（2）參與事務(wù)請求 Proposal 的投票

（3）參與 Leader 選舉投票

Observer

（1）3.0 版本以后引入的一個(gè)服務(wù)器角色欢嘿，在不影響集群事務(wù)處理能力的基礎(chǔ)上提升集群的非事務(wù)處理能力

（2）處理客戶端的非事務(wù)請求，轉(zhuǎn)發(fā)事務(wù)請求給 Leader 服務(wù)器

（3）不參與任何形式的投票

14. Zookeeper 下 Server 工作狀態(tài)

服務(wù)器具有四種狀態(tài)也糊，分別是 LOOKING炼蹦、FOLLOWING、LEADING狸剃、OBSERVING掐隐。

（1）LOOKING：尋 找 Leader 狀態(tài)。當(dāng)服務(wù)器處于該狀態(tài)時(shí)钞馁，它會認(rèn)為當(dāng)前集群中沒有 Leader虑省，因此需要進(jìn)入 Leader 選舉狀態(tài)。

（2）FOLLOWING：跟隨者狀態(tài)僧凰。表明當(dāng)前服務(wù)器角色是 Follower探颈。

（3）LEADING：領(lǐng)導(dǎo)者狀態(tài)。表明當(dāng)前服務(wù)器角色是 Leader允悦。

（4）OBSERVING：觀察者狀態(tài)膝擂。表明當(dāng)前服務(wù)器角色是 Observer虑啤。

15. 數(shù)據(jù)同步

整個(gè)集群完成 Leader 選舉之后，Learner（Follower 和 Observer 的統(tǒng)稱）回向Leader 服務(wù)器進(jìn)行注冊架馋。當(dāng) Learner 服務(wù)器想 Leader 服務(wù)器完成注冊后狞山，進(jìn)入數(shù)據(jù)同步環(huán)節(jié)。

數(shù)據(jù)同步流程：（均以消息傳遞的方式進(jìn)行）

Learner 向 Learder 注冊

數(shù)據(jù)同步

同步確認(rèn)

Zookeeper 的數(shù)據(jù)同步通常分為四類：

（1）直接差異化同步（DIFF 同步）

（2）先回滾再差異化同步（TRUNC+DIFF 同步）

（3）僅回滾同步（TRUNC 同步）

（4）全量同步（SNAP 同步）

在進(jìn)行數(shù)據(jù)同步前叉寂，Leader 服務(wù)器會完成數(shù)據(jù)同步初始化：

peerLastZxid：

· 從 learner 服務(wù)器注冊時(shí)發(fā)送的 ACKEPOCH 消息中提取 lastZxid（該Learner 服務(wù)器最后處理的 ZXID）

minCommittedLog：

· Leader 服務(wù)器 Proposal 緩存隊(duì)列 committedLog 中最小 ZXIDmaxCommittedLog：

· Leader 服務(wù)器 Proposal 緩存隊(duì)列 committedLog 中最大 ZXID直接差異化同步（DIFF 同步）

· 場景：peerLastZxid 介于 minCommittedLog 和 maxCommittedLog之間先回滾再差異化同步（TRUNC+DIFF 同步）

· 場景：當(dāng)新的 Leader 服務(wù)器發(fā)現(xiàn)某個(gè) Learner 服務(wù)器包含了一條自己沒有的事務(wù)記錄萍启，那么就需要讓該 Learner 服務(wù)器進(jìn)行事務(wù)回滾--回滾到 Leader服務(wù)器上存在的，同時(shí)也是最接近于 peerLastZxid 的 ZXID僅回滾同步（TRUNC 同步）

· 場景：peerLastZxid 大于 maxCommittedLog

全量同步（SNAP 同步）

· 場景一：peerLastZxid 小于 minCommittedLog

· 場景二：Leader 服務(wù)器上沒有 Proposal 緩存隊(duì)列且 peerLastZxid 不等于 lastProcessZxid

16. zookeeper 是如何保證事務(wù)的順序一致性的屏鳍？

zookeeper 采用了全局遞增的事務(wù) Id 來標(biāo)識勘纯，所有的 proposal（提議）都在被提出的時(shí)候加上了 zxid，zxid 實(shí)際上是一個(gè) 64 位的數(shù)字钓瞭，高 32 位是 epoch（ 時(shí)期; 紀(jì)元; 世; 新時(shí)代）用來標(biāo)識 leader 周期驳遵，如果有新的 leader 產(chǎn)生出來，epoch會自增山涡，低 32 位用來遞增計(jì)數(shù)堤结。當(dāng)新產(chǎn)生 proposal 的時(shí)候，會依據(jù)數(shù)據(jù)庫的兩階段過程鸭丛，首先會向其他的 server 發(fā)出事務(wù)執(zhí)行請求竞穷，如果超過半數(shù)的機(jī)器都能執(zhí)行并且能夠成功，那么就會開始執(zhí)行鳞溉。

17. 分布式集群中為什么會有 Master瘾带？

在分布式環(huán)境中，有些業(yè)務(wù)邏輯只需要集群中的某一臺機(jī)器進(jìn)行執(zhí)行熟菲，其他的機(jī)器可以共享這個(gè)結(jié)果看政，這樣可以大大減少重復(fù)計(jì)算，提高性能科盛，于是就需要進(jìn)行l(wèi)eader 選舉帽衙。

18. zk 節(jié)點(diǎn)宕機(jī)如何處理？

Zookeeper 本身也是集群贞绵，推薦配置不少于 3 個(gè)服務(wù)器厉萝。Zookeeper 自身也要保證當(dāng)一個(gè)節(jié)點(diǎn)宕機(jī)時(shí)，其他節(jié)點(diǎn)會繼續(xù)提供服務(wù)榨崩。

如果是一個(gè) Follower 宕機(jī)谴垫，還有 2 臺服務(wù)器提供訪問，因?yàn)?Zookeeper 上的數(shù)據(jù)是有多個(gè)副本的母蛛，數(shù)據(jù)并不會丟失翩剪；

如果是一個(gè) Leader 宕機(jī)，Zookeeper 會選舉出新的 Leader彩郊。

ZK 集群的機(jī)制是只要超過半數(shù)的節(jié)點(diǎn)正常前弯，集群就能正常提供服務(wù)蚪缀。只有在 ZK節(jié)點(diǎn)掛得太多，只剩一半或不到一半節(jié)點(diǎn)能工作恕出，集群才失效询枚。

所以

3 個(gè)節(jié)點(diǎn)的 cluster 可以掛掉 1 個(gè)節(jié)點(diǎn)(leader 可以得到 2 票>1.5)

2 個(gè)節(jié)點(diǎn)的 cluster 就不能掛掉任何 1 個(gè)節(jié)點(diǎn)了(leader 可以得到 1 票<=1)

19. zookeeper 負(fù)載均衡和 nginx 負(fù)載均衡區(qū)別

zk 的負(fù)載均衡是可以調(diào)控，nginx 只是能調(diào)權(quán)重浙巫，其他需要可控的都需要自己寫插件金蜀；但是 nginx 的吞吐量比 zk 大很多，應(yīng)該說按業(yè)務(wù)選擇用哪種方式的畴。

20. Zookeeper 有哪幾種幾種部署模式渊抄？

部署模式：單機(jī)模式、偽集群模式丧裁、集群模式护桦。

21. 集群最少要幾臺機(jī)器，集群規(guī)則是怎樣的?

集群規(guī)則為 2N+1 臺煎娇，N>0嘶炭，即 3 臺。

22. 集群支持動(dòng)態(tài)添加機(jī)器嗎逊桦？

其實(shí)就是水平擴(kuò)容了，Zookeeper 在這方面不太好抑进。兩種方式：

全部重啟：關(guān)閉所有 Zookeeper 服務(wù)强经，修改配置之后啟動(dòng)。不影響之前客戶端的會話寺渗。

逐個(gè)重啟：在過半存活即可用的原則下匿情，一臺機(jī)器重啟不影響整個(gè)集群對外提供服務(wù)。這是比較常用的方式信殊。

3.5 版本開始支持動(dòng)態(tài)擴(kuò)容炬称。

23. Zookeeper 對節(jié)點(diǎn)的 watch 監(jiān)聽通知是永久的嗎？為什么不是永久的?

不是涡拘。官方聲明：一個(gè) Watch 事件是一個(gè)一次性的觸發(fā)器玲躯，當(dāng)被設(shè)置了 Watch的數(shù)據(jù)發(fā)生了改變的時(shí)候，則服務(wù)器將這個(gè)改變發(fā)送給設(shè)置了 Watch 的客戶端鳄乏，以便通知它們跷车。

為什么不是永久的，舉個(gè)例子橱野，如果服務(wù)端變動(dòng)頻繁朽缴，而監(jiān)聽的客戶端很多情況下，每次變動(dòng)都要通知到所有的客戶端水援，給網(wǎng)絡(luò)和服務(wù)器造成很大壓力密强。

一般是客戶端執(zhí)行 getData(“/節(jié)點(diǎn) A”,true)茅郎，如果節(jié)點(diǎn) A 發(fā)生了變更或刪除，客戶端會得到它的 watch 事件或渤，但是在之后節(jié)點(diǎn) A 又發(fā)生了變更系冗，而客戶端又沒有設(shè)置 watch 事件，就不再給客戶端發(fā)送劳坑。

在實(shí)際應(yīng)用中毕谴，很多情況下，我們的客戶端不需要知道服務(wù)端的每一次變動(dòng)距芬，我只要最新的數(shù)據(jù)即可涝开。

24. Zookeeper 的 java 客戶端都有哪些？

java 客戶端：zk 自帶的 zkclient 及 Apache 開源的 Curator框仔。

25. chubby 是什么舀武，和 zookeeper 比你怎么看？

chubby 是 google 的离斩，完全實(shí)現(xiàn) paxos 算法银舱，不開源。zookeeper 是 chubby的開源實(shí)現(xiàn)跛梗，使用 zab 協(xié)議寻馏，paxos 算法的變種。

26. 說幾個(gè) zookeeper 常用的命令核偿。

常用命令：ls get set create delete 等诚欠。

27. ZAB 和 Paxos 算法的聯(lián)系與區(qū)別？

相同點(diǎn)：

（1）兩者都存在一個(gè)類似于 Leader 進(jìn)程的角色漾岳，由其負(fù)責(zé)協(xié)調(diào)多個(gè) Follower 進(jìn)程的運(yùn)行

（2）Leader 進(jìn)程都會等待超過半數(shù)的 Follower 做出正確的反饋后轰绵，才會將一個(gè)提案進(jìn)行提交

（3）ZAB 協(xié)議中，每個(gè) Proposal 中都包含一個(gè) epoch 值來代表當(dāng)前的 Leader周期尼荆，Paxos 中名字為 Ballot

不同點(diǎn)：

ZAB 用來構(gòu)建高可用的分布式數(shù)據(jù)主備系統(tǒng)（Zookeeper）左腔，Paxos 是用來構(gòu)建分布式一致性狀態(tài)機(jī)系統(tǒng)。

28. Zookeeper 的典型應(yīng)用場景

Zookeeper 是一個(gè)典型的發(fā)布/訂閱模式的分布式數(shù)據(jù)管理與協(xié)調(diào)框架捅儒，開發(fā)人員可以使用它來進(jìn)行分布式數(shù)據(jù)的發(fā)布和訂閱液样。

通過對 Zookeeper 中豐富的數(shù)據(jù)節(jié)點(diǎn)進(jìn)行交叉使用，配合 Watcher 事件通知機(jī)制野芒，可以非常方便的構(gòu)建一系列分布式應(yīng)用中年都會涉及的核心功能蓄愁，如：

（1）數(shù)據(jù)發(fā)布/訂閱

（2）負(fù)載均衡

（3）命名服務(wù)

（4）分布式協(xié)調(diào)/通知

（5）集群管理

（6）Master 選舉

（7）分布式鎖

（8）分布式隊(duì)列

數(shù)據(jù)發(fā)布/訂閱

介紹

數(shù)據(jù)發(fā)布/訂閱系統(tǒng)，即所謂的配置中心狞悲，顧名思義就是發(fā)布者發(fā)布數(shù)據(jù)供訂閱者進(jìn)行數(shù)據(jù)訂閱撮抓。

目的

動(dòng)態(tài)獲取數(shù)據(jù)（配置信息）

實(shí)現(xiàn)數(shù)據(jù)（配置信息）的集中式管理和數(shù)據(jù)的動(dòng)態(tài)更新

設(shè)計(jì)模式

Push 模式

Pull 模式

數(shù)據(jù)（配置信息）特性

（1）數(shù)據(jù)量通常比較小

（2）數(shù)據(jù)內(nèi)容在運(yùn)行時(shí)會發(fā)生動(dòng)態(tài)更新

（3）集群中各機(jī)器共享，配置一致

如：機(jī)器列表信息摇锋、運(yùn)行時(shí)開關(guān)配置丹拯、數(shù)據(jù)庫配置信息等

基于 Zookeeper 的實(shí)現(xiàn)方式

· 數(shù)據(jù)存儲：將數(shù)據(jù)（配置信息）存儲到 Zookeeper 上的一個(gè)數(shù)據(jù)節(jié)點(diǎn)

· 數(shù)據(jù)獲日境：應(yīng)用在啟動(dòng)初始化節(jié)點(diǎn)從 Zookeeper 數(shù)據(jù)節(jié)點(diǎn)讀取數(shù)據(jù)，并在該節(jié)點(diǎn)上注冊一個(gè)數(shù)據(jù)變更 Watcher

· 數(shù)據(jù)變更：當(dāng)變更數(shù)據(jù)時(shí)乖酬，更新 Zookeeper 對應(yīng)節(jié)點(diǎn)數(shù)據(jù)死相，Zookeeper會將數(shù)據(jù)變更通知發(fā)到各客戶端，客戶端接到通知后重新讀取變更后的數(shù)據(jù)即可咬像。

負(fù)載均衡

zk 的命名服務(wù)

命名服務(wù)是指通過指定的名字來獲取資源或者服務(wù)的地址算撮，利用 zk 創(chuàng)建一個(gè)全局的路徑，這個(gè)路徑就可以作為一個(gè)名字县昂，指向集群中的集群肮柜，提供的服務(wù)的地址，或者一個(gè)遠(yuǎn)程的對象等等倒彰。

分布式通知和協(xié)調(diào)

對于系統(tǒng)調(diào)度來說：操作人員發(fā)送通知實(shí)際是通過控制臺改變某個(gè)節(jié)點(diǎn)的狀態(tài)审洞，然后 zk 將這些變化發(fā)送給注冊了這個(gè)節(jié)點(diǎn)的 watcher 的所有客戶端。

對于執(zhí)行情況匯報(bào)：每個(gè)工作進(jìn)程都在某個(gè)目錄下創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)待讳。并攜帶工作的進(jìn)度數(shù)據(jù)芒澜，這樣匯總的進(jìn)程可以監(jiān)控目錄子節(jié)點(diǎn)的變化獲得工作進(jìn)度的實(shí)時(shí)的全局情況。

zk 的命名服務(wù)（文件系統(tǒng)）

命名服務(wù)是指通過指定的名字來獲取資源或者服務(wù)的地址创淡，利用 zk 創(chuàng)建一個(gè)全局的路徑痴晦，即是唯一的路徑，這個(gè)路徑就可以作為一個(gè)名字琳彩，指向集群中的集群阅酪，提供的服務(wù)的地址，或者一個(gè)遠(yuǎn)程的對象等等汁针。

zk 的配置管理（文件系統(tǒng)、通知機(jī)制）

程序分布式的部署在不同的機(jī)器上砚尽，將程序的配置信息放在 zk 的 znode 下施无，當(dāng)有配置發(fā)生改變時(shí)，也就是 znode 發(fā)生變化時(shí)必孤，可以通過改變 zk 中某個(gè)目錄節(jié)點(diǎn)的內(nèi)容猾骡，利用 watcher 通知給各個(gè)客戶端，從而更改配置敷搪。

Zookeeper 集群管理（文件系統(tǒng)兴想、通知機(jī)制）

所謂集群管理無在乎兩點(diǎn)：是否有機(jī)器退出和加入、選舉 master赡勘。

對于第一點(diǎn)嫂便，所有機(jī)器約定在父目錄下創(chuàng)建臨時(shí)目錄節(jié)點(diǎn)，然后監(jiān)聽父目錄節(jié)點(diǎn)

的子節(jié)點(diǎn)變化消息闸与。一旦有機(jī)器掛掉毙替，該機(jī)器與 zookeeper 的連接斷開岸售，其所創(chuàng)建的臨時(shí)目錄節(jié)點(diǎn)被刪除，所有其他機(jī)器都收到通知：某個(gè)兄弟目錄被刪除厂画，于是凸丸，所有人都知道：它上船了。

新機(jī)器加入也是類似袱院，所有機(jī)器收到通知：新兄弟目錄加入屎慢，highcount 又有了，對于第二點(diǎn)忽洛，我們稍微改變一下腻惠，所有機(jī)器創(chuàng)建臨時(shí)順序編號目錄節(jié)點(diǎn)，每次選取編號最小的機(jī)器作為 master 就好脐瑰。

Zookeeper 分布式鎖（文件系統(tǒng)妖枚、通知機(jī)制）

有了 zookeeper 的一致性文件系統(tǒng)，鎖的問題變得容易苍在。鎖服務(wù)可以分為兩類绝页，一個(gè)是保持獨(dú)占，另一個(gè)是控制時(shí)序寂恬。

對于第一類续誉，我們將 zookeeper 上的一個(gè) znode 看作是一把鎖，通過 createznode的方式來實(shí)現(xiàn)初肉。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點(diǎn)酷鸦，最終成功創(chuàng)建的那個(gè)客戶端也即擁有了這把鎖。用完刪除掉自己創(chuàng)建的 distribute_lock 節(jié)點(diǎn)就釋放出鎖牙咏。

對于第二類臼隔， /distribute_lock 已經(jīng)預(yù)先存在，所有客戶端在它下面創(chuàng)建臨時(shí)順序編號目錄節(jié)點(diǎn)妄壶，和選 master 一樣摔握，編號最小的獲得鎖，用完刪除丁寄，依次方便氨淌。

Zookeeper 隊(duì)列管理（文件系統(tǒng)、通知機(jī)制）

兩種類型的隊(duì)列：

（1）同步隊(duì)列伊磺，當(dāng)一個(gè)隊(duì)列的成員都聚齊時(shí)盛正，這個(gè)隊(duì)列才可用，否則一直等待所有成員到達(dá)屑埋。

（2）隊(duì)列按照 FIFO 方式進(jìn)行入隊(duì)和出隊(duì)操作豪筝。

第一類，在約定目錄下創(chuàng)建臨時(shí)目錄節(jié)點(diǎn)，監(jiān)聽節(jié)點(diǎn)數(shù)目是否是我們要求的數(shù)目壤蚜。

第二類即寡，和分布式鎖服務(wù)中的控制時(shí)序場景基本原理一致，入列有編號袜刷，出列按編號聪富。在特定的目錄下創(chuàng)建 PERSISTENT_SEQUENTIAL 節(jié)點(diǎn)，創(chuàng)建成功時(shí)Watcher 通知等待的隊(duì)列著蟹，隊(duì)列刪除序列號最小的節(jié)點(diǎn)用以消費(fèi)墩蔓。此場景下Zookeeper 的 znode 用于消息存儲，znode 存儲的數(shù)據(jù)就是消息隊(duì)列中的消息內(nèi)容萧豆，SEQUENTIAL 序列號就是消息的編號奸披，按序取出即可。由于創(chuàng)建的節(jié)點(diǎn)是持久化的涮雷，所以不必?fù)?dān)心隊(duì)列消息的丟失問題阵面。