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

1. ZooKeeper 是什么?

ZooKeeper 是一個開放源碼的分布式協調服務，它是集群的管理者，監視著集群中各個節點的狀態根 據節點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

分布式應用程序可以基于 Zookeeper 實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。

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

(1)順序一致性

(2)原子性

(3)單一視圖

(4)可靠性

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

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

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

2. ZooKeeper 提供了什么?

(1)文件系統

(2)通知機制

3.Zookeeper 文件系統

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

4. ZAB 協議?

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

5. 四種類型的數據節點 Znode

(1)PERSISTENT-持久節點

除非手動刪除，否則節點一直存在于 Zookeeper 上

(2)EPHEMERAL-臨時節點

臨時節點的生命周期與客戶端會話綁定，一旦客戶端會話失效(客戶端與zookeeper 連接斷開不一定會話失效)，那么這個客戶端創建的所有臨時節點都會被移除。

(3)PERSISTENT_SEQUENTIAL-持久順序節點

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

(4)EPHEMERAL_SEQUENTIAL-臨時順序節點

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

6. Zookeeper Watcher 機制 -- 數據變更通知

Zookeeper 允許客戶端向服務端的某個 Znode 注冊一個 Watcher 監聽，當服務端的一些指定事件觸發了這個 Watcher，服務端會向指定客戶端發送一個事件通知來實現分布式的通知功能，然后客戶端根據Watcher 通知狀態和事件類型做出業務上的改變。

工作機制：

(1)客戶端注冊 watcher

(2)服務端處理 watcher

(3)客戶端回調 watcher

Watcher 特性總結：

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

(2)客戶端串行執行

客戶端 Watcher 回調的過程是一個串行同步的過程。

(3)輕量

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

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

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

(5)注冊 watcher getData、exists、getChildren

(6)觸發 watcher create、delete、setData

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

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