消息隊列經(jīng)典十連問

前言

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

1. 什么是消息隊列

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

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

2. 消息隊列有哪些使用場景。

有時候面試官會換個角度問你，為什么使用消息隊列。你可以回答以下這幾點：

應(yīng)用解耦

流量削峰

異步處理

消息通訊

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

2.1 應(yīng)用解耦

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

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

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

如何解決這個問題呢？可以引入消息隊列

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

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

2.2 流量削峰

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

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

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

首先秒殺活動不會每時每刻都那么多請求過來，高峰期過去后，積壓的請求可以慢慢處理；

其次，如果消息隊列長度超過最大數(shù)量，可以直接拋棄用戶請求或跳轉(zhuǎn)到錯誤頁面；

2.3 異步處理

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

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

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

2.4 消息通訊

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

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

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

3. 消息隊列如何解決消息丟失問題？

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

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

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

存儲端不丟消息

消費者不丟消息

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

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

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

同步發(fā)送

異步發(fā)送

單向發(fā)送

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

采用同步方式發(fā)送，send消息方法返回成功狀態(tài)，就表示消息正常到達(dá)了存儲端Broker。

如果send消息異常或者返回非成功狀態(tài)，可以重試。

可以使用事務(wù)消息，RocketMQ的事務(wù)消息機制就是為了保證零丟失來設(shè)計的

3.2 存儲端不丟消息

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

刷盤機制分同步刷盤和異步刷盤：

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

異步刷盤的話，只要消息寫入PageCache緩存，就返回一個成功的ACK響應(yīng)。這樣提高了MQ的性能，但是如果這時候機器斷電了，就會丟失消息。

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

3.3 消費階段不丟消息

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

4. 消息隊列如何保證消息的順序性。

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

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

這樣還是可能會有問題，因為從MQ服務(wù)器到消費端，可能存在網(wǎng)絡(luò)延遲，雖然M1先發(fā)送，但是它比M2晚到。

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

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

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

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

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

生產(chǎn)端為了保證消息的可靠性，它可能往MQ服務(wù)器重復(fù)發(fā)送消息，直到拿到成功的ACK。

再然后就是消費端，消費端消費消息一般是這個流程：拉取消息、業(yè)務(wù)邏輯處理、提交消費位移。假設(shè)業(yè)務(wù)邏輯處理完，事務(wù)提交了，但是需要更新消費位移時，消費者卻掛了，這時候另一個消費者就會拉到重復(fù)消息了。

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

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

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

6. 如何處理消息隊列的消息積壓問題

消息積壓是因為生產(chǎn)者的生產(chǎn)速度，大于消費者的消費速度。遇到消息積壓問題時，我們需要先排查，是不是有bug產(chǎn)生了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MQ服務(wù)器返回ACK確認(rèn)到生產(chǎn)者，此時MQ不會觸發(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ù)器會push消息給消費者。消費者消費完就回ACK。

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

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

這個問題面試官主要考察三個方面的知識點：

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯 ：李倩