【秋招必備】Java中間件面試題（2021最新版）

前言

現今時代，系統越來越復雜，數據來越多，系統間的交互也就變得越來越重要，同時也變得越來越困難。而消息中間件在其中起到了一個中間橋梁的重要作用。因此，面試中也經常會被問到消息中間件相關的問題。從其使用到其原理設計，都會是面試官感興趣的一個點。本場小編就以zookeeper / RocketMQ 為例，簡單介紹消息中間件並在其中穿插面試官常會提及的消息中間件相關的問題，小編這里還總結了一份中間件的思維導圖，分享給到大家。

小編分享的這份Java后端開發面試總結包含了JavaOOP、Java集合容器、Java異常、並發編程、Java反射、Java序列化、JVM、Redis、Spring MVC、MyBatis、MySQL數據庫、消息中間件MQ、Dubbo、Linux、ZooKeeper、 分布式&數據結構與算法等26個專題技術點，都是小編在各個大廠總結出來的面試真題，已經有很多粉絲靠這份PDF拿下眾多大廠的offer，今天在這里總結分享給到大家！【已完結】

完整版Java面試題地址：2021最新面試題合集集錦。

序號	專題	內容	鏈接
1	中間件	【秋招必備】Java中間件面試題（2021最新版）	待更新
2	微服務	【秋招必備】Java微服務面試題（2021最新版）	待更新
3	並發編程	【秋招必備】Java並發編程面試題（2021最新版）	待更新
4	Java基礎	【秋招必備】Java基礎知識面試題（2021最新版）	待更新
5	Spring Boot	【秋招必備】Spring Boot面試題（2021最新版）	待更新
6	Redis	【秋招必備】Redis面試題（2021最新版）	待更新
7	Spring MVC	【秋招必備】Spring MVC面試題（2021最新版）	待更新
8	Spring Cloud	【秋招必備】Spring Cloud面試題（2021最新版）	待更新
9	MySQL優化	【秋招必備】MySQL優化面試題（2021最新版）	待更新
10	JVM	【秋招必備】JVM性能調優面試題（2021最新版）	待更新
11	Linux	【秋招必備】Linux面試題（2021最新版）	待更新
12	Mybatis	【秋招必備】Mybatis面試題（2021最新版）	待更新
13	網絡編程	【秋招必備】TCP，UDP，Socket，Http網絡編程面試題（2021最新版）	待更新
14	設計模式	【秋招必備】設計模式面試題（2021最新版）	待更新
15	大數據	【秋招必備】大數據面試題100道（2021最新版）	待更新
16	Tomcat	【秋招必備】Tomcat面試題（2021最新版）	待更新
17	多線程	【秋招必備】多線程面試題（2021最新版）	待更新
18	Nginx	【秋招必備】Nginx_BIO_NIO_AIO面試題（2021最新版）	待更新
19	memcache	【秋招必備】memcache面試題（2021最新版）	待更新
20	java異常	【秋招必備】java異常面試題（2021最新版）	待更新
21	Java虛擬機	【秋招必備】Java虛擬機面試題（2021最新版）	待更新
22	Java集合	【秋招必備】Java集合面試題（2021最新版）	待更新
23	Git常用命令	【秋招必備】Git常用命令（2021最新版）	待更新
24	Elasticsearch	【秋招必備】Elasticsearch面試題（2021最新版）	待更新
25	Dubbo	【秋招必備】Dubbo面試題（2021最新版）	待更新

Zookeeper

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 事件可能會被丟失。

7. 客戶端注冊 Watcher 實現

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

（2）標記請求 request，封裝 Watcher 到 WatchRegistration

（3）封裝成 Packet 對象，發服務端發送 request

（4）收到服務端響應后，將 Watcher 注冊到 ZKWatcherManager 中進行管理

（5）請求返回，完成注冊。

8. 服務端處理 Watcher 實現

9. 客戶端回調 Watcher

• 客戶端 SendThread 線程接收事件通知，交由 EventThread 線程回調 Watcher。
• 客戶端的 Watcher 機制同樣是一次性的，一旦被觸發后，該 Watcher 就失效了。

10. ACL 權限控制機制

11. Chroot 特性

12. 會話管理

13. 服務器角色

14. Zookeeper 下 Server 工作狀態

服務器具有四種狀態，分別是 LOOKING、FOLLOWING、LEADING、OBSERVING。

（1）LOOKING：尋 找 Leader 狀態。當服務器處於該狀態時，它會認為當前集群中沒有 Leader，因此需要進入 Leader 選舉狀態。

（2）FOLLOWING：跟隨者狀態。表明當前服務器角色是 Follower。

（3）LEADING：領導者狀態。表明當前服務器角色是 Leader。

（4）OBSERVING：觀察者狀態。表明當前服務器角色是 Observer。

15. 數據同步

16. zookeeper 是如何保證事務的順序一致性的？

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

在分布式環境中，有些業務邏輯只需要集群中的某一台機器進行執行，其他的機器可以共享這個結果，這樣可以大大減少重復計算，提高性能，於是就需要進行leader 選舉。

18. zk 節點宕機如何處理？

19. zookeeper 負載均衡和 nginx 負載均衡區別

zk 的負載均衡是可以調控，nginx 只是能調權重，其他需要可控的都需要自己寫插件；但是 nginx 的吞吐量比 zk 大很多，應該說按業務選擇用哪種方式。

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

部署模式：單機模式、偽集群模式、集群模式

21. 集群最少要幾台機器，集群規則是怎樣的?

集群規則為 2N+1 台，N>0，即 3 台

22. 集群支持動態添加機器嗎？

23. Zookeeper 對節點的 watch 監聽通知是永久的嗎？為什么不是永久的?

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

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

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

chubby 是 google 的，完全實現 paxos 算法，不開源。zookeeper 是 chubby的開源實現，使用 zab協議，paxos 算法的變種。

26. 說幾個 zookeeper 常用的命令。

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

27. ZAB 和 Paxos 算法的聯系與區別？

28. Zookeeper 的典型應用場景

Zookeeper 是一個典型的發布/訂閱模式的分布式數據管理與協調框架，開發人員可以使用它來進行分布式數據的發布和訂閱。

通過對 Zookeeper 中豐富的數據節點進行交叉使用，配合 Watcher 事件通知機制，可以非常方便的構建一系列分布式應用中年都會涉及的核心功能，如：

• （1）數據發布/訂閱
• （2）負載均衡
• （3）命名服務
• （4）分布式協調/通知
• （5）集群管理（6）Master 選舉
• （7）分布式鎖
• （8）分布式隊列

數據發布/訂閱

介紹

數據發布/訂閱系統，即所謂的配置中心，顧名思義就是發布者發布數據供訂閱者進行數據訂閱。

目的

動態獲取數據（配置信息）

實現數據（配置信息）的集中式管理和數據的動態更新

設計模式

Push 模式

Pull 模式

數據（配置信息）特性

（1）數據量通常比較小

（2）數據內容在運行時會發生動態更新

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

如：機器列表信息、運行時開關配置、數據庫配置信息等

基於 Zookeeper 的實現方式

· 數據存儲：將數據（配置信息）存儲到 Zookeeper 上的一個數據節點

· 數據獲取：應用在啟動初始化節點從 Zookeeper 數據節點讀取數據，並在該節點上注冊一個數據變更

Watcher

· 數據變更：當變更數據時，更新 Zookeeper 對應節點數據，Zookeeper會將數據變更通知發到各客戶

端，客戶端接到通知后重新讀取變更后的數據即可。

負載均衡

zk 的命名服務

命名服務是指通過指定的名字來獲取資源或者服務的地址，利用 zk 創建一個全局的路徑，這個路徑就可以作為一個名字，指向集群中的集群，提供的服務的地址，或者一個遠程的對象等等。

分布式通知和協調

對於系統調度來說：操作人員發送通知實際是通過控制台改變某個節點的狀態，然后 zk 將這些變化發送給注冊了這個節點的 watcher 的所有客戶端。對於執行情況匯報：每個工作進程都在某個目錄下創建一個臨時節點。並攜帶工作的進度數據，這樣匯總的進程可以監控目錄子節點的變化獲得工作進度的實時的全局情況。

zk 的命名服務（文件系統）

命名服務是指通過指定的名字來獲取資源或者服務的地址，利用 zk 創建一個全局的路徑，即是唯一的路徑，這個路徑就可以作為一個名字，指向集群中的集群，提供的服務的地址，或者一個遠程的對象等等。

zk 的配置管理（文件系統、通知機制）程序分布式的部署在不同的機器上，將程序的配置信息放在 zk 的 znode 下，當有配置發生改變時，也

就是 znode 發生變化時，可以通過改變 zk 中某個目錄節點的內容，利用 watcher 通知給各個客戶端，從而更改配置。

Zookeeper 集群管理（文件系統、通知機制）

所謂集群管理無在乎兩點：是否有機器退出和加入、選舉 master。對於第一點，所有機器約定在父目錄下創建臨時目錄節點，然后監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper 的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知道：它上船了。新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount 又有了，對於第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作為 master 就好。

Zookeeper 分布式鎖（文件系統、通知機制）

有了 zookeeper 的一致性文件系統，鎖的問題變得容易。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。對於第一類，我們將 zookeeper 上的一個 znode 看作是一把鎖，通過 createznode的方式來實現。所

有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創建的 distribute_lock 節點就釋放出鎖。對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選master 一樣，編號最小的獲得鎖，用完刪除，依次方便。Zookeeper 隊列管理（文件系統、通知機制）

兩種類型的隊列：

（1）同步隊列，當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。

（2）隊列按照 FIFO 方式進行入隊和出隊操作。

第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。

第二類，和分布式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。在特定的目錄下

創建 PERSISTENT_SEQUENTIAL 節點，創建成功時Watcher 通知等待的隊列，隊列刪除序列號最小的節點用以消費。此場景下Zookeeper 的 znode 用於消息存儲，znode 存儲的數據就是消息隊列中的消息內容，SEQUENTIAL 序列號就是消息的編號，按序取出即可。由於創建的節點是持久化的，所以不必擔心隊列消息的丟失問題。

RabbitMQ

1. 什么是MQ

MQ就是消息隊列。是軟件和軟件進行通信的中間件產品

2. MQ的優點

• 異步處理 - 相比於傳統的串行、並行方式，提高了系統吞吐量。
• 應用解耦 - 系統間通過消息通信，不用關心其他系統的處理。
• 流量削鋒 - 可以通過消息隊列長度控制請求量；可以緩解短時間內的高並發請求。
• 日志處理 - 解決大量日志傳輸。
• 消息通訊 - 消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實
• 現點對點消息隊列，或者聊天室等。

3. 解耦、異步、削峰是什么？。

• 解耦：A 系統發送數據到 BCD 三個系統，通過接口調用發送。如果 E 系統也要這個數據呢？那如果 C 系統現在不需要了呢？A 系統負責人幾乎崩潰…A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統產生一條比較關鍵的數據，很多系統都需要 A 系統將這個數據發送過來。如果使用 MQ，A系統產生一條數據，發送到 MQ 里面去，哪個系統需要數據自己去 MQ 里面消費。如果新系統需 要數據，直接從 MQ 里消費即可；如果某個系統不需要這條數據了，就取消對 MQ 消息的消費即可。這樣下來，A 系統壓根兒不需要去考慮要給誰發送數據，不需要維護這個代碼，也不需要考慮 人家是否調用成功、失敗超時等情況。就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很復雜，維護起來很麻煩。但是其實這個調用是不需要直接同步調用接口的，如果用 MQ 給它異步化解耦。
• 異步：A 系統接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統寫庫，自己本地寫庫 要 3ms，BCD 三個系統分別寫庫要 300ms、450ms、200ms。最終請求總延時是 3 + 300 + 450 + 200 = 953ms，接近 1s，用戶感覺搞個什么東西，慢死了慢死了。用戶通過瀏覽器發起請求。 如果使用 MQ，那么 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個 請求到返回響應給用戶，總時長是 3 + 5 = 8ms。
• 削峰：減少高峰時期對服務器壓力

4. 消息隊列有什么缺點

5. 你們公司生產環境用的是什么消息中間件？

• 這個首先你可以說下你們公司選用的是什么消息中間件，比如用的是RabbitMQ，然后可以初步給一些你對不同MQ中間件技術的選型分析。
• 舉個例子：比如說ActiveMQ是老牌的消息中間件，國內很多公司過去運用的還是非常廣泛的，功能很強大。
• 但是問題在於沒法確認ActiveMQ可以支撐互聯網公司的高並發、高負載以及高吞吐的復雜場景，在國內互聯網公司落地較少。而且使用較多的是一些傳統企業，用ActiveMQ做異步調用和系統解耦。
• 然后你可以說說RabbitMQ，他的好處在於可以支撐高並發、高吞吐、性能很高，同時有非常完善便捷的后台管理界面可以使用。
• 另外，他還支持集群化、高可用部署架構、消息高可靠支持，功能較為完善。
• 而且經過調研，國內各大互聯網公司落地大規模RabbitMQ集群支撐自身業務的case較多，國內各種中小型互聯網公司使用RabbitMQ的實踐也比較多。
• 除此之外，RabbitMQ的開源社區很活躍，較高頻率的迭代版本，來修復發現的bug以及進行各種優化，因此綜合考慮過后，公司采取了RabbitMQ。
• 但是RabbitMQ也有一點缺陷，就是他自身是基於erlang語言開發的，所以導致較為難以分析里面的源碼，也較難進行深層次的源碼定制和改造，畢竟需要較為扎實的erlang語言功底才可以。
• 然后可以聊聊RocketMQ，是阿里開源的，經過阿里的生產環境的超高並發、高吞吐的考驗，性能卓越，同時還支持分布式事務等特殊場景。
• 而且RocketMQ是基於Java語言開發的，適合深入閱讀源碼，有需要可以站在源碼層面解決線上生產問題，包括源碼的二次開發和改造。
• 另外就是Kafka。Kafka提供的消息中間件的功能明顯較少一些，相對上述幾款MQ中間件要少很多。
• 但是Kafka的優勢在於專為超高吞吐量的實時日志采集、實時數據同步、實時數據計算等場景來設計。
• 因此Kafka在大數據領域中配合實時計算技術（比如Spark Streaming、Storm、Flink）使用的較多。但是在傳統的MQ中間件使用場景中較少采用。

6. Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么優缺點？

7. MQ 有哪些常見問題？如何解決這些問題？

8. 什么是RabbitMQ？

RabbitMQ是一款開源的，Erlang編寫的，消息中間件； 最大的特點就是消費並不需要確保提供方 存在,實現了服務之間的高度解耦 可以用它來：解耦、異步、削峰。

9. rabbitmq 的使用場景

（1）服務間異步通信

（2）順序消費

（3）定時任務

（4）請求削峰

10. RabbitMQ基本概念

11. RabbitMQ的工作模式

12. 如何保證RabbitMQ消息的順序性？

• 拆分多個 queue(消息隊列)，每個 queue(消息隊列) 一個 consumer(消費者)，就是多一些 queue(消息隊列)而已，確實是麻煩點；
• 或者就一個 queue (消息隊列)但是對應一個 consumer(消費者)，然后這個 consumer(消費者)內部用內存隊列做排隊，然后分發給底層不同的 worker 來處理。

13. 消息如何分發？

• 若該隊列至少有一個消費者訂閱，消息將以循環（round-robin）的方式發送給消費者。每條消息只會分發給一個訂閱的消費者（前提是消費者能夠正常處理消息並進行確認）。通過路由可實現多消費的功能

14. 消息怎么路由？

15. 消息基於什么傳輸？

16. 如何保證消息不被重復消費？或者說，如何保證消息消費時的冪等性？

17. 如何確保消息正確地發送至 RabbitMQ？ 如何確保消息接收方消費了消息？

18. 如何保證RabbitMQ消息的可靠傳輸？

19. 為什么不應該對所有的 message 都使用持久化機制？

20. 如何保證高可用的？RabbitMQ 的集群

21. 如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以后該怎么處理？有幾百萬消息持續積壓幾小時，怎么辦？

22. 設計MQ思路

23.RoctetMq的架構

• NameServer
• Broker
• Producer
• Producer的負載均衡
• 發送的三種策略
• Consumer
• 推拉消費模式
• 集群還是廣播
• Consumer的負載均衡

24. RocketMq消息模型（專業術語）

• Message
• Topic
• Tag
• Group
• Message Queue
• offset

25.核心問題

• 順序消息
• 消息過濾
• 消息去重
• 分布式事務消息
• 消息的可用性
• 刷盤實現
• 負載均衡

最后

小編分享的文章到這里就結束了，整理不易，歡迎大家一起交流！