前言

大家好呀，金三銀四即將來臨，整理了十道十分經(jīng)典的消息隊(duì)列面試題，看完肯定對面試有幫助的，大家一起加油哈~

1. 什么是消息隊(duì)列
2. 消息隊(duì)列的應(yīng)用場景
3. 消息隊(duì)列如何解決消息丟失問題
4. 消息隊(duì)列如何保證消息的順序性。
5. 消息有可能發(fā)生重復(fù)消費(fèi)嗎？如何冪等處理？
6. 如何處理消息隊(duì)列的消息積壓問題
7. 消息隊(duì)列技術(shù)選型，Kafka還是RocketMQ，還是RabbitMQ
8. 消息中間件如何做到高可用？
9. 如何保證數(shù)據(jù)一致性，事務(wù)消息如何實(shí)現(xiàn)
10. 如果讓你寫一個(gè)消息隊(duì)列，該如何進(jìn)行架構(gòu)設(shè)計(jì)？

1. 什么是消息隊(duì)列

你可以把消息隊(duì)列理解為一個(gè)使用隊(duì)列來通信的組件。它的本質(zhì)，就是個(gè)轉(zhuǎn)發(fā)器，包含發(fā)消息、存消息、消費(fèi)消息的過程。最簡單的消息隊(duì)列模型如下：

我們通常說的消息隊(duì)列，簡稱MQ（Message Queue），它其實(shí)就指消息中間件，當(dāng)前業(yè)界比較流行的開源消息中間件包括：RabbitMQ、RocketMQ、Kafka。

2. 消息隊(duì)列有哪些使用場景。

有時(shí)候面試官會(huì)換個(gè)角度問你，為什么使用消息隊(duì)列。你可以回答以下這幾點(diǎn)：

1. 應(yīng)用解耦
2. 流量削峰
3. 異步處理
4. 消息通訊
5. 遠(yuǎn)程調(diào)用

2.1 應(yīng)用解耦

舉個(gè)常見業(yè)務(wù)場景：下單扣庫存，用戶下單后，訂單系統(tǒng)去通知庫存系統(tǒng)扣減。傳統(tǒng)的做法就是訂單系統(tǒng)直接調(diào)用庫存系統(tǒng)：

• 如果庫存系統(tǒng)無法訪問，下單就會(huì)失敗，訂單和庫存系統(tǒng)存在耦合關(guān)系
• 如果業(yè)務(wù)又接入一個(gè)營銷積分服務(wù)，那訂單下游系統(tǒng)要擴(kuò)充，如果未來接入越來越多的下游系統(tǒng)，那訂單系統(tǒng)代碼需要經(jīng)常修改

如何解決這個(gè)問題呢？可以引入消息隊(duì)列

1. 訂單系統(tǒng)：用戶下單后，消息寫入到消息隊(duì)列，返回下單成功
2. 庫存系統(tǒng)：訂閱下單消息，獲取下單信息，進(jìn)行庫存扣減操作。

2.2 流量削峰

流量削峰也是消息隊(duì)列的常用場景。我們做秒殺實(shí)現(xiàn)的時(shí)候，需要避免流量暴漲，打垮應(yīng)用系統(tǒng)的風(fēng)險(xiǎn)?？梢栽趹?yīng)用前面加入消息隊(duì)列。

假設(shè)秒殺系統(tǒng)每秒最多可以處理2k個(gè)請求，每秒?yún)s有5k的請求過來，可以引入消息隊(duì)列，秒殺系統(tǒng)每秒從消息隊(duì)列拉2k請求處理得了。

有些伙伴擔(dān)心這樣會(huì)出現(xiàn)消息積壓的問題，

• 首先秒殺活動(dòng)不會(huì)每時(shí)每刻都那么多請求過來，高峰期過去后，積壓的請求可以慢慢處理；
• 其次，如果消息隊(duì)列長度超過最大數(shù)量，可以直接拋棄用戶請求或跳轉(zhuǎn)到錯(cuò)誤頁面；

2.3 異步處理

我們經(jīng)常會(huì)遇到這樣的業(yè)務(wù)場景：用戶注冊成功后，給它發(fā)個(gè)短信和發(fā)個(gè)郵件。

如果注冊信息入庫是30ms，發(fā)短信、郵件也是30ms，三個(gè)動(dòng)作串行執(zhí)行的話，會(huì)比較耗時(shí)，響應(yīng)90ms：

如果采用并行執(zhí)行的方式，可以減少響應(yīng)時(shí)間。注冊信息入庫后，同時(shí)異步發(fā)短信和郵件。如何實(shí)現(xiàn)異步呢，用消息隊(duì)列即可，就是說，注冊信息入庫成功后，寫入到消息隊(duì)列（這個(gè)一般比較快，如只需要3ms），然后異步讀取發(fā)郵件和短信。

2.4 消息通訊

消息隊(duì)列內(nèi)置了高效的通信機(jī)制，可用于消息通訊。如實(shí)現(xiàn)點(diǎn)對點(diǎn)消息隊(duì)列、聊天室等。

2.5 遠(yuǎn)程調(diào)用

我們公司基于MQ，自研了遠(yuǎn)程調(diào)用框架。

3. 消息隊(duì)列如何解決消息丟失問題？

一個(gè)消息從生產(chǎn)者產(chǎn)生，到被消費(fèi)者消費(fèi)，主要經(jīng)過這3個(gè)過程：

因此如何保證MQ不丟失消息，可以從這三個(gè)階段闡述：

• 生產(chǎn)者保證不丟消息
• 存儲(chǔ)端不丟消息
• 消費(fèi)者不丟消息

3.1 生產(chǎn)者保證不丟消息

生產(chǎn)端如何保證不丟消息呢？確保生產(chǎn)的消息能到達(dá)存儲(chǔ)端。

如果是RocketMQ消息中間件，Producer生產(chǎn)者提供了三種發(fā)送消息的方式，分別是：

• 同步發(fā)送
• 異步發(fā)送
• 單向發(fā)送

生產(chǎn)者要想發(fā)消息時(shí)保證消息不丟失，可以：

• 采用同步方式發(fā)送，send消息方法返回成功狀態(tài)，就表示消息正常到達(dá)了存儲(chǔ)端Broker。
• 如果send消息異常或者返回非成功狀態(tài)，可以重試。
• 可以使用事務(wù)消息，RocketMQ的事務(wù)消息機(jī)制就是為了保證零丟失來設(shè)計(jì)的

3.2 存儲(chǔ)端不丟消息

如何保證存儲(chǔ)端的消息不丟失呢？確保消息持久化到磁盤。大家很容易想到就是刷盤機(jī)制。

刷盤機(jī)制分同步刷盤和異步刷盤：

• 生產(chǎn)者消息發(fā)過來時(shí)，只有持久化到磁盤，RocketMQ的存儲(chǔ)端Broker才返回一個(gè)成功的ACK響應(yīng)，這就是同步刷盤。它保證消息不丟失，但是影響了性能。
• 異步刷盤的話，只要消息寫入PageCache緩存，就返回一個(gè)成功的ACK響應(yīng)。這樣提高了MQ的性能，但是如果這時(shí)候機(jī)器斷電了，就會(huì)丟失消息。

Broker一般是集群部署的，有master主節(jié)點(diǎn)和slave從節(jié)點(diǎn)。消息到Broker存儲(chǔ)端，只有主節(jié)點(diǎn)和從節(jié)點(diǎn)都寫入成功，才反饋成功的ack給生產(chǎn)者。這就是同步復(fù)制，它保證了消息不丟失，但是降低了系統(tǒng)的吞吐量。與之對應(yīng)的就是異步復(fù)制，只要消息寫入主節(jié)點(diǎn)成功，就返回成功的ack，它速度快，但是會(huì)有性能問題。

3.3 消費(fèi)階段不丟消息

消費(fèi)者執(zhí)行完業(yè)務(wù)邏輯，再反饋會(huì)Broker說消費(fèi)成功，這樣才可以保證消費(fèi)階段不丟消息。

4. 消息隊(duì)列如何保證消息的順序性。

消息的有序性，就是指可以按照消息的發(fā)送順序來消費(fèi)。有些業(yè)務(wù)對消息的順序是有要求的，比如先下單再付款，最后再完成訂單，這樣等。假設(shè)生產(chǎn)者先后產(chǎn)生了兩條消息，分別是下單消息（M1），付款消息（M2），M1比M2先產(chǎn)生，如何保證M1比M2先被消費(fèi)呢。

為了保證消息的順序性，可以將M1、M2發(fā)送到同一個(gè)Server上，當(dāng)M1發(fā)送完收到ack后，M2再發(fā)送。如圖：

這樣還是可能會(huì)有問題，因?yàn)閺腗Q服務(wù)器到消費(fèi)端，可能存在網(wǎng)絡(luò)延遲，雖然M1先發(fā)送，但是它比M2晚到。

那還能怎么辦才能保證消息的順序性呢？將M1和M2發(fā)往同一個(gè)消費(fèi)者，且發(fā)送M1后，等到消費(fèi)端ACK成功后，才發(fā)送M2就得了。

消息隊(duì)列保證順序性整體思路就是這樣啦。比如Kafka的全局有序消息，就是這種思想的體現(xiàn): 就是生產(chǎn)者發(fā)消息時(shí)，1個(gè)Topic只能對應(yīng)1個(gè)Partition，一個(gè) Consumer，內(nèi)部單線程消費(fèi)。

但是這樣吞吐量太低，一般保證消息局部有序即可。在發(fā)消息的時(shí)候指定Partition Key，Kafka對其進(jìn)行Hash計(jì)算，根據(jù)計(jì)算結(jié)果決定放入哪個(gè)Partition。這樣Partition Key相同的消息會(huì)放在同一個(gè)Partition。然后多消費(fèi)者單線程消費(fèi)指定的Partition。

5.消息隊(duì)列有可能發(fā)生重復(fù)消費(fèi)，如何避免，如何做到冪等？

消息隊(duì)列是可能發(fā)生重復(fù)消費(fèi)的。

• 生產(chǎn)端為了保證消息的可靠性，它可能往MQ服務(wù)器重復(fù)發(fā)送消息，直到拿到成功的ACK。
• 再然后就是消費(fèi)端，消費(fèi)端消費(fèi)消息一般是這個(gè)流程：拉取消息、業(yè)務(wù)邏輯處理、提交消費(fèi)位移。假設(shè)業(yè)務(wù)邏輯處理完，事務(wù)提交了，但是需要更新消費(fèi)位移時(shí)，消費(fèi)者卻掛了，這時(shí)候另一個(gè)消費(fèi)者就會(huì)拉到重復(fù)消息了。

如何冪等處理重復(fù)消息呢？

我之前寫過一篇冪等設(shè)計(jì)的文章，大家有興趣可以看下哈：聊聊冪等設(shè)計(jì)

冪等處理重復(fù)消息，簡單來說，就是搞個(gè)本地表，帶唯一業(yè)務(wù)標(biāo)記的，利用主鍵或者唯一性索引，每次處理業(yè)務(wù)，先校驗(yàn)一下就好啦。又或者用redis緩存下業(yè)務(wù)標(biāo)記，每次看下是否處理過了。

6. 如何處理消息隊(duì)列的消息積壓問題

消息積壓是因?yàn)樯a(chǎn)者的生產(chǎn)速度，大于消費(fèi)者的消費(fèi)速度。遇到消息積壓問題時(shí)，我們需要先排查，是不是有bug產(chǎn)生了。

如果不是bug，我們可以優(yōu)化一下消費(fèi)的邏輯，比如之前是一條一條消息消費(fèi)處理的話，我們可以確認(rèn)是不是可以優(yōu)為批量處理消息。如果還是慢，我們可以考慮水平擴(kuò)容，增加Topic的隊(duì)列數(shù)，和消費(fèi)組機(jī)器的數(shù)量，提升整體消費(fèi)能力。

如果是bug導(dǎo)致幾百萬消息持續(xù)積壓幾小時(shí)。有如何處理呢？需要解決bug，臨時(shí)緊急擴(kuò)容，大概思路如下：

1. 先修復(fù)consumer消費(fèi)者的問題，以確保其恢復(fù)消費(fèi)速度，然后將現(xiàn)有consumer 都停掉。
2. 新建一個(gè) topic，partition 是原來的 10 倍，臨時(shí)建立好原先10倍的queue 數(shù)量。
3. 然后寫一個(gè)臨時(shí)的分發(fā)數(shù)據(jù)的 consumer 程序，這個(gè)程序部署上去消費(fèi)積壓的數(shù)據(jù)，消費(fèi)之后不做耗時(shí)的處理，直接均勻輪詢寫入臨時(shí)建立好的 10 倍數(shù)量的 queue。
4. 接著臨時(shí)征用 10 倍的機(jī)器來部署 consumer，每一批 consumer 消費(fèi)一個(gè)臨時(shí) queue 的數(shù)據(jù)。這種做法相當(dāng)于是臨時(shí)將 queue 資源和 consumer 資源擴(kuò)大 10 倍，以正常的 10 倍速度來消費(fèi)數(shù)據(jù)。
5. 等快速消費(fèi)完積壓數(shù)據(jù)之后，得恢復(fù)原先部署的架構(gòu)，重新用原先的 consumer 機(jī)器來消費(fèi)消息。

7. 消息隊(duì)列技術(shù)選型，Kafka還是RocketMQ，還是RabbitMQ

先可以對比下它們優(yōu)缺點(diǎn)：

• RabbitMQ是開源的，比較穩(wěn)定的支持，活躍度也高，但是不是Java語言開發(fā)的。
• 很多公司用RocketMQ，比較成熟，是阿里出品的。
• 如果是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算、日志采集等場景，用 Kafka 是業(yè)內(nèi)標(biāo)準(zhǔn)的。

8. 消息中間件如何做到高可用

消息中間件如何保證高可用呢？單機(jī)是沒有高可用可言的，高可用都是對集群來說的，一起看下kafka的高可用吧。

Kafka 的基礎(chǔ)集群架構(gòu)，由多個(gè)broker組成，每個(gè)broker都是一個(gè)節(jié)點(diǎn)。當(dāng)你創(chuàng)建一個(gè)topic時(shí)，它可以劃分為多個(gè)partition，而每個(gè)partition放一部分?jǐn)?shù)據(jù)，分別存在于不同的 broker 上。也就是說，一個(gè) topic 的數(shù)據(jù)，是分散放在多個(gè)機(jī)器上的，每個(gè)機(jī)器就放一部分?jǐn)?shù)據(jù)。

有些伙伴可能有疑問，每個(gè)partition放一部分?jǐn)?shù)據(jù)，如果對應(yīng)的broker掛了，那這部分?jǐn)?shù)據(jù)是不是就丟失了？那還談什么高可用呢？

Kafka 0.8 之后，提供了復(fù)制品副本機(jī)制來保證高可用，即每個(gè) partition 的數(shù)據(jù)都會(huì)同步到其它機(jī)器上，形成多個(gè)副本。然后所有的副本會(huì)選舉一個(gè) leader 出來，讓leader去跟生產(chǎn)和消費(fèi)者打交道，其他副本都是follower。寫數(shù)據(jù)時(shí)，leader 負(fù)責(zé)把數(shù)據(jù)同步給所有的follower，讀消息時(shí)， 直接讀 leader 上的數(shù)據(jù)即可。如何保證高可用的？就是假設(shè)某個(gè) broker 宕機(jī)，這個(gè)broker上的partition 在其他機(jī)器上都有副本的。如果掛的是leader的broker呢？其他follower會(huì)重新選一個(gè)leader出來。

9. 如何保證數(shù)據(jù)一致性，事務(wù)消息如何實(shí)現(xiàn)

一條普通的MQ消息，從產(chǎn)生到被消費(fèi)，大概流程如下：

1. 生產(chǎn)者產(chǎn)生消息，發(fā)送帶MQ服務(wù)器
2. MQ收到消息后，將消息持久化到存儲(chǔ)系統(tǒng)。
3. MQ服務(wù)器返回ACk到生產(chǎn)者。
4. MQ服務(wù)器把消息push給消費(fèi)者
5. 消費(fèi)者消費(fèi)完消息，響應(yīng)ACK
6. MQ服務(wù)器收到ACK，認(rèn)為消息消費(fèi)成功，即在存儲(chǔ)中刪除消息。

我們舉個(gè)下訂單的例子吧。訂單系統(tǒng)創(chuàng)建完訂單后，再發(fā)送消息給下游系統(tǒng)。如果訂單創(chuàng)建成功，然后消息沒有成功發(fā)送出去，下游系統(tǒng)就無法感知這個(gè)事情，出導(dǎo)致數(shù)據(jù)不一致。

如何保證數(shù)據(jù)一致性呢？可以使用事務(wù)消息。一起來看下事務(wù)消息是如何實(shí)現(xiàn)的吧。

1. 生產(chǎn)者產(chǎn)生消息，發(fā)送一條半事務(wù)消息到MQ服務(wù)器
2. MQ收到消息后，將消息持久化到存儲(chǔ)系統(tǒng)，這條消息的狀態(tài)是待發(fā)送狀態(tài)。
3. MQ服務(wù)器返回ACK確認(rèn)到生產(chǎn)者，此時(shí)MQ不會(huì)觸發(fā)消息推送事件
4. 生產(chǎn)者執(zhí)行本地事務(wù)
5. 如果本地事務(wù)執(zhí)行成功，即commit執(zhí)行結(jié)果到MQ服務(wù)器；如果執(zhí)行失敗，發(fā)送rollback。
6. 如果是正常的commit，MQ服務(wù)器更新消息狀態(tài)為可發(fā)送；如果是rollback，即刪除消息。
7. 如果消息狀態(tài)更新為可發(fā)送，則MQ服務(wù)器會(huì)push消息給消費(fèi)者。消費(fèi)者消費(fèi)完就回ACK。
8. 如果MQ服務(wù)器長時(shí)間沒有收到生產(chǎn)者的commit或者rollback，它會(huì)反查生產(chǎn)者，然后根據(jù)查詢到的結(jié)果執(zhí)行最終狀態(tài)。

10. 讓你寫一個(gè)消息隊(duì)列，該如何進(jìn)行架構(gòu)設(shè)計(jì)？

這個(gè)問題面試官主要考察三個(gè)方面的知識(shí)點(diǎn)：

• 你有沒有對消息隊(duì)列的架構(gòu)原理比較了解
• 考察你的個(gè)人設(shè)計(jì)能力
• 考察編程思想，如什么高可用、可擴(kuò)展性、冪等等等。

遇到這種設(shè)計(jì)題，大部分人會(huì)很蒙圈，因?yàn)槠綍r(shí)沒有思考過類似的問題。大多數(shù)人平時(shí)埋頭增刪改啥，不去思考框架背后的一些原理。有很多類似的問題，比如讓你來設(shè)計(jì)一個(gè) Dubbo 框架，或者讓你來設(shè)計(jì)一個(gè)MyBatis 框架，你會(huì)怎么思考呢？

回答這類問題，并不要求你研究過那技術(shù)的源碼，你知道那個(gè)技術(shù)框架的基本結(jié)構(gòu)、工作原理即可。設(shè)計(jì)一個(gè)消息隊(duì)列，我們可以從這幾個(gè)角度去思考：

1. 首先是消息隊(duì)列的整體流程，producer發(fā)送消息給broker，broker存儲(chǔ)好，broker再發(fā)送給consumer消費(fèi)，consumer回復(fù)消費(fèi)確認(rèn)等。
2. producer發(fā)送消息給broker，broker發(fā)消息給consumer消費(fèi)，那就需要兩次RPC了，RPC如何設(shè)計(jì)呢？可以參考開源框架Dubbo，你可以說說服務(wù)發(fā)現(xiàn)、序列化協(xié)議等等
3. broker考慮如何持久化呢，是放文件系統(tǒng)還是數(shù)據(jù)庫呢，會(huì)不會(huì)消息堆積呢，消息堆積如何處理呢。
4. 消費(fèi)關(guān)系如何保存呢？點(diǎn)對點(diǎn)還是廣播方式呢？廣播關(guān)系又是如何維護(hù)呢？zk還是config server
5. 消息可靠性如何保證呢？如果消息重復(fù)了，如何冪等處理呢？
6. 消息隊(duì)列的高可用如何設(shè)計(jì)呢？可以參考Kafka的高可用保障機(jī)制。多副本 -> leader & follower -> broker 掛了重新選舉 leader 即可對外服務(wù)。
7. 消息事務(wù)特性，與本地業(yè)務(wù)同個(gè)事務(wù)，本地消息落庫;消息投遞到服務(wù)端，本地才刪除；定時(shí)任務(wù)掃描本地消息庫，補(bǔ)償發(fā)送。
8. MQ得伸縮性和可擴(kuò)展性，如果消息積壓或者資源不夠時(shí)，如何支持快速擴(kuò)容，提高吞吐？可以參照一下 Kafka 的設(shè)計(jì)理念，broker -> topic -> partition，每個(gè) partition 放一個(gè)機(jī)器，就存一部分?jǐn)?shù)據(jù)。如果現(xiàn)在資源不夠了，簡單啊，給 topic 增加 partition，然后做數(shù)據(jù)遷移，增加機(jī)器，不就可以存放更多數(shù)據(jù)，提供更高的吞吐量了？

參考與感謝

微信8.0將好友放開到了一萬，小伙伴可以加我大號(hào)了，先到先得，再滿就真沒了