【金三銀四】Java中間件面試題（2021最新版）

小編分享的這份金三銀四Java後端開發面試總結包含了JavaOOP、Java集合容器、Java異常、併發編程、Java反射、Java序列化、JVM、Redis、Spring MVC、MyBatis、MySQL數據庫、消息中間件MQ、Dubbo、Linux、ZooKeeper、 分佈式&數據結構與算法等26個專題技術點，都是小編在各個大廠總結出來的面試真題，已經有不少粉絲靠這份PDF拿下衆多大廠的offer，今天在這裏總結分享給到你們！【持續更新中！】

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

前言

現今時代，系統愈來愈複雜，數據來越多，系統間的交互也就變得愈來愈重要，同時也變得愈來愈困難。而消息中間件在其中起到了一箇中間橋樑的重要做用。所以，面試中也常常會被問到消息中間件相關的問題。從其使用到其原理設計，都會是面試官感興趣的一個點。本場小編就以zookeeper / RocketMQ 爲例，簡單介紹消息中間件並在其中穿插面試官常會說起的消息中間件相關的問題，小編這裏還總結了一份中間件的思惟導圖，分享給到你們。

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.一、Watcher 通知很是簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。

3.二、客戶端向服務端註冊 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.核心問題

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

該面試題答案解析完整文檔獲取方式：【Java中間件面試題【附答案解析】】

最後

篇幅有限，其餘內容就不在這裏一一展現了，整理不易，歡迎你們一塊兒交流，喜歡小編分享的文章記得關注我點贊喲，感謝支持！重要的事情說三遍，轉發+轉發+轉發，必定要記得轉發哦！！！