如今的系統(tǒng)數(shù)據(jù)越來越多，越來越復(fù)雜，系統(tǒng)之間的交互也變得格外重要，而消息中間件在其中起到了中間橋梁的作用，因此，大家在面試Java相關(guān)崗位的時候，消息中間件的相關(guān)問題問的格外的多。今天小編整理的這套面試題，希望能夠幫助到大家，早做準(zhǔn)備，不至于在面試時被面試官打的措手不及：

1. ZooKeeper 是什么?

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

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

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

(1)順序一致性

(2)原子性

(3)單一視圖

(4)可靠性

(5)實時性(最終一致性)

客戶端的讀請求可以被集群中的任意一臺機器處理，如果讀請求在節(jié)點上注冊了監(jiān)聽器，這個監(jiān)聽器也 是由所連接的 zookeeper 機器來處理。對于寫請求，這些請求會同時發(fā)給其他 zookeeper 機器并且達成一致后，請求才會返回成功。因此，隨著 zookeeper 的集群機器增多，讀請求的吞吐會提高但是寫 請求的吞吐會下降。

有序性是 zookeeper 中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為 zxid(Zookeeper Transaction Id)。而讀請求只會相對于更新有序，也就是 讀請求的返回結(jié)果中會帶有這個zookeeper 最新的 zxid。

2. ZooKeeper 提供了什么?

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

(2)通知機制

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

Zookeeper 提供一個多層級的節(jié)點命名空間(節(jié)點稱為 znode)。與文件系統(tǒng)不同的是，這些節(jié)點都可以設(shè)置關(guān)聯(lián)的數(shù)據(jù)，而文件系統(tǒng)中只有文件節(jié)點可以存放數(shù)據(jù)而目錄節(jié)點不行。 Zookeeper 為了保證高吞吐和低延遲，在內(nèi)存中維護了這個樹狀的目錄結(jié)構(gòu)，這種特性使得Zookeeper 不能用于存放大量的數(shù)據(jù)，每個節(jié)點的存放數(shù)據(jù)上限為1M。

4. ZAB 協(xié)議?

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

5. 四種類型的數(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ù)字。

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

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

工作機制：

(1)客戶端注冊 watcher

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

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

Watcher 特性總結(jié)：

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

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

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

(3)輕量

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

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

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

(5)注冊 watcher getData、exists、getChildren

(6)觸發(fā) watcher create、delete、setData

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

以上就是“資深大廠總結(jié)出的Java中間件相關(guān)面試題”，你能回答上來嗎?如果想要了解更多的Java面試題相關(guān)內(nèi)容，可以關(guān)注動力節(jié)點Java官網(wǎng)。