前言

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

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

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

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

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

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

應(yīng)用解耦

流量削峰

異步處理

消息通訊

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

2.1 應(yīng)用解耦

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

如果庫(kù)存系統(tǒng)無(wú)法訪問(wèn)，下單就會(huì)失敗，訂單和庫(kù)存系統(tǒng)存在耦合關(guān)系

如果業(yè)務(wù)又接入一個(gè)營(yíng)銷(xiāo)積分服務(wù)，那訂單下游系統(tǒng)要擴(kuò)充，如果未來(lái)接入越來(lái)越多的下游系統(tǒng)，那訂單系統(tǒng)代碼需要經(jīng)常修改

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

訂單系統(tǒng)：用戶下單后，消息寫(xiě)入到消息隊(duì)列，返回下單成功

庫(kù)存系統(tǒng)：訂閱下單消息，獲取下單信息，進(jìn)行庫(kù)存扣減操作。

2.2 流量削峰

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

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

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

首先秒殺活動(dòng)不會(huì)每時(shí)每刻都那么多請(qǐng)求過(guò)來(lái)，高峰期過(guò)去后，積壓的請(qǐng)求可以慢慢處理；

其次，如果消息隊(duì)列長(zhǎng)度超過(guò)最大數(shù)量，可以直接拋棄用戶請(qǐng)求或跳轉(zhuǎn)到錯(cuò)誤頁(yè)面；

2.3 異步處理

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

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

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

2.4 消息通訊

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

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

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

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

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

因此如何保證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ī)制就是為了保證零丟失來(lái)設(shè)計(jì)的

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

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

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

生產(chǎn)者消息發(fā)過(guò)來(lái)時(shí)，只有持久化到磁盤(pán)，RocketMQ的存儲(chǔ)端Broker才返回一個(gè)成功的ACK響應(yīng)，這就是同步刷盤(pán)。它保證消息不丟失，但是影響了性能。

異步刷盤(pán)的話，只要消息寫(xiě)入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)都寫(xiě)入成功，才反饋成功的ack給生產(chǎn)者。這就是同步復(fù)制，它保證了消息不丟失，但是降低了系統(tǒng)的吞吐量。與之對(duì)應(yīng)的就是異步復(fù)制，只要消息寫(xiě)入主節(jié)點(diǎn)成功，就返回成功的ack，它速度快，但是會(huì)有性能問(wèn)題。

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

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

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

消息的有序性，就是指可以按照消息的發(fā)送順序來(lái)消費(fèi)。有些業(yè)務(wù)對(duì)消息的順序是有要求的，比如先下單再付款，最后再完成訂單，這樣等。假設(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ì)有問(wèn)題，因?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只能對(duì)應(yīng)1個(gè)Partition，一個(gè) Consumer，內(nèi)部單線程消費(fèi)。

但是這樣吞吐量太低，一般保證消息局部有序即可。在發(fā)消息的時(shí)候指定Partition Key，Kafka對(duì)其進(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ù)消息呢？

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

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

6. 如何處理消息隊(duì)列的消息積壓?jiǎn)栴}

消息積壓是因?yàn)樯a(chǎn)者的生產(chǎn)速度，大于消費(fèi)者的消費(fèi)速度。遇到消息積壓?jiǎn)栴}時(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)致幾百萬(wàn)消息持續(xù)積壓幾小時(shí)。有如何處理呢？需要解決bug，臨時(shí)緊急擴(kuò)容，大概思路如下：

先修復(fù)consumer消費(fèi)者的問(wèn)題，以確保其恢復(fù)消費(fèi)速度，然后將現(xiàn)有consumer 都停掉。

新建一個(gè) topic，partition 是原來(lái)的 10 倍，臨時(shí)建立好原先10倍的queue 數(shù)量。

然后寫(xiě)一個(gè)臨時(shí)的分發(fā)數(shù)據(jù)的 consumer 程序，這個(gè)程序部署上去消費(fèi)積壓的數(shù)據(jù)，消費(fèi)之后不做耗時(shí)的處理，直接均勻輪詢寫(xiě)入臨時(shí)建立好的 10 倍數(shù)量的 queue。

接著臨時(shí)征用 10 倍的機(jī)器來(lái)部署 consumer，每一批 consumer 消費(fèi)一個(gè)臨時(shí) queue 的數(shù)據(jù)。這種做法相當(dāng)于是臨時(shí)將 queue 資源和 consumer 資源擴(kuò)大 10 倍，以正常的 10 倍速度來(lái)消費(fèi)數(shù)據(jù)。

等快速消費(fèi)完積壓數(shù)據(jù)之后，得恢復(fù)原先部署的架構(gòu)，重新用原先的 consumer 機(jī)器來(lái)消費(fèi)消息。

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

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

RabbitMQ是開(kāi)源的，比較穩(wěn)定的支持，活躍度也高，但是不是Java語(yǔ)言開(kāi)發(fā)的。

很多公司用RocketMQ，比較成熟，是阿里出品的。

如果是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算、日志采集等場(chǎng)景，用 Kafka 是業(yè)內(nèi)標(biāo)準(zhǔn)的。

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

消息中間件如何保證高可用呢？單機(jī)是沒(méi)有高可用可言的，高可用都是對(duì)集群來(lái)說(shuō)的，一起看下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 上。也就是說(shuō)，一個(gè) topic 的數(shù)據(jù)，是分散放在多個(gè)機(jī)器上的，每個(gè)機(jī)器就放一部分?jǐn)?shù)據(jù)。

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

Kafka 0.8 之后，提供了復(fù)制品副本機(jī)制來(lái)保證高可用，即每個(gè) partition 的數(shù)據(jù)都會(huì)同步到其它機(jī)器上，形成多個(gè)副本。然后所有的副本會(huì)選舉一個(gè) leader 出來(lái)，讓leader去跟生產(chǎn)和消費(fèi)者打交道，其他副本都是follower。寫(xiě)數(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出來(lái)。

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

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

生產(chǎn)者產(chǎn)生消息，發(fā)送帶MQ服務(wù)器

MQ收到消息后，將消息持久化到存儲(chǔ)系統(tǒng)。

MQ服務(wù)器返回ACk到生產(chǎn)者。

MQ服務(wù)器把消息push給消費(fèi)者

消費(fèi)者消費(fèi)完消息，響應(yīng)ACK

MQ服務(wù)器收到ACK，認(rèn)為消息消費(fèi)成功，即在存儲(chǔ)中刪除消息。

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

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

生產(chǎn)者產(chǎn)生消息，發(fā)送一條半事務(wù)消息到MQ服務(wù)器

MQ收到消息后，將消息持久化到存儲(chǔ)系統(tǒng)，這條消息的狀態(tài)是待發(fā)送狀態(tài)。

MQ服務(wù)器返回ACK確認(rèn)到生產(chǎn)者，此時(shí)MQ不會(huì)觸發(fā)消息推送事件

生產(chǎn)者執(zhí)行本地事務(wù)

如果本地事務(wù)執(zhí)行成功，即commit執(zhí)行結(jié)果到MQ服務(wù)器；如果執(zhí)行失敗，發(fā)送rollback。

如果是正常的commit，MQ服務(wù)器更新消息狀態(tài)為可發(fā)送；如果是rollback，即刪除消息。

如果消息狀態(tài)更新為可發(fā)送，則MQ服務(wù)器會(huì)push消息給消費(fèi)者。消費(fèi)者消費(fèi)完就回ACK。

如果MQ服務(wù)器長(zhǎng)時(shí)間沒(méi)有收到生產(chǎn)者的commit或者rollback，它會(huì)反查生產(chǎn)者，然后根據(jù)查詢到的結(jié)果執(zhí)行最終狀態(tài)。

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

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

你有沒(méi)有對(duì)消息隊(duì)列的架構(gòu)原理比較了解

考察你的個(gè)人設(shè)計(jì)能力

考察編程思想，如什么高可用、可擴(kuò)展性、冪等等等。

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

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

首先是消息隊(duì)列的整體流程，producer發(fā)送消息給broker，broker存儲(chǔ)好，broker再發(fā)送給consumer消費(fèi)，consumer回復(fù)消費(fèi)確認(rèn)等。

producer發(fā)送消息給broker，broker發(fā)消息給consumer消費(fèi)，那就需要兩次RPC了，RPC如何設(shè)計(jì)呢？可以參考開(kāi)源框架Dubbo，你可以說(shuō)說(shuō)服務(wù)發(fā)現(xiàn)、序列化協(xié)議等等

broker考慮如何持久化呢，是放文件系統(tǒng)還是數(shù)據(jù)庫(kù)呢，會(huì)不會(huì)消息堆積呢，消息堆積如何處理呢。

消費(fèi)關(guān)系如何保存呢？點(diǎn)對(duì)點(diǎn)還是廣播方式呢？廣播關(guān)系又是如何維護(hù)呢？zk還是config server

消息可靠性如何保證呢？如果消息重復(fù)了，如何冪等處理呢？

消息隊(duì)列的高可用如何設(shè)計(jì)呢？可以參考Kafka的高可用保障機(jī)制。多副本 -> leader & follower -> broker 掛了重新選舉 leader 即可對(duì)外服務(wù)。

消息事務(wù)特性，與本地業(yè)務(wù)同個(gè)事務(wù)，本地消息落庫(kù);消息投遞到服務(wù)端，本地才刪除；定時(shí)任務(wù)掃描本地消息庫(kù)，補(bǔ)償發(fā)送。

MQ得伸縮性和可擴(kuò)展性，如果消息積壓或者資源不夠時(shí)，如何支持快速擴(kuò)容，提高吞吐？可以參照一下 Kafka 的設(shè)計(jì)理念，broker -> topic -> partition，每個(gè) partition 放一個(gè)機(jī)器，就存一部分?jǐn)?shù)據(jù)。如果現(xiàn)在資源不夠了，簡(jiǎn)單啊，給 topic 增加 partition，然后做數(shù)據(jù)遷移，增加機(jī)器，不就可以存放更多數(shù)據(jù)，提供更高的吞吐量了？

審核編輯 ：李倩