大家平時也有用到一些消息中間件(MQ)，但是對其理解可能僅停留在會使用 API 能實(shí)現(xiàn)生產(chǎn)消息、消費(fèi)消息就完事了。

[[270323]]

圖片來自pexels

對 MQ 更加深入的問題，可能很多人沒怎么思考過。比如，你跳槽面試時，如果面試官看到你簡歷上寫了熟練掌握消息中間件。

那么很可能給你發(fā)起如下 4 個面試連環(huán)炮：

• 為什么要使用 MQ?
• 使用了 MQ 之后有什么優(yōu)缺點(diǎn)?
• 怎么保證 MQ 消息不丟失?
• 怎么保證 MQ 的高可用性?

本文將通過一些場景，配合著通俗易懂的語言和多張手繪彩圖，討論一下這些問題。

為什么要使用 MQ?

相信大家也聽過這樣的一句話：好的架構(gòu)不是設(shè)計出來的，是演進(jìn)出來的。

這句話在引入 MQ 的場景同樣適用，使用 MQ 必定有其道理，是用來解決實(shí)際問題的。而不是看見別人用了，我也用著玩兒一下。

其實(shí)使用 MQ 的場景挺多的，但是比較核心的有 3 個：

• 異步
• 解耦
• 削峰填谷

異步

我們通過實(shí)際案例說明：假設(shè) A 系統(tǒng)接收一個請求，需要在自己本地寫庫執(zhí)行 SQL，然后需要調(diào)用 BCD 三個系統(tǒng)的接口。

假設(shè)自己本地寫庫要 3ms，調(diào)用 BCD 三個系統(tǒng)分別要 300ms、450ms、200ms。

那么最終請求總延時是 3+300+450+200=953ms，接近 1s，可能用戶會感覺太慢了。

此時整個系統(tǒng)大概是這樣的：

但是一旦使用了 MQ 之后，系統(tǒng) A 只需要發(fā)送 3 條消息到 MQ 中的 3 個消息隊列，然后就返回給用戶了。

假設(shè)發(fā)送消息到 MQ 中耗時 20ms，那么用戶感知到這個接口的耗時僅僅是 20+3=23ms，用戶幾乎無感知，倍兒爽!

此時整個系統(tǒng)結(jié)構(gòu)大概是這樣的：

可以看到，通過 MQ 的異步功能，可以大大提高接口的性能。

解耦

假設(shè) A 系統(tǒng)在用戶發(fā)生某個操作的時候，需要把用戶提交的數(shù)據(jù)同時推送到 B、C 兩個系統(tǒng)的時候。

這個時候負(fù)責(zé) A 系統(tǒng)的哥們想：沒事啊，B、C 兩個系統(tǒng)給我提供一個 HTTP 接口或者 RPC 接口，我把數(shù)據(jù)推送過去不就完事了嘛。負(fù)責(zé) A 系統(tǒng)的哥們美滋滋。

如下圖所示：

一切看起來很美好，但是隨著業(yè)務(wù)快速迭代，這個時候系統(tǒng) D 也想要這個數(shù)據(jù)。那既然這樣，A 系統(tǒng)的開發(fā)同學(xué)就改咯，在發(fā)送數(shù)據(jù)給 BC 的同時加上一個 D。

但是，越到后面越發(fā)現(xiàn)，麻煩來了。整個系統(tǒng)好像不止這個數(shù)據(jù)要發(fā)送給 BCD、還有第二、第三個數(shù)據(jù)要發(fā)送給 BCD。甚至有時候又加入了 E、F 等系統(tǒng)，他們也要這個數(shù)據(jù)。

并且有時候可能 B 系統(tǒng)突然又不要這個數(shù)據(jù)了，A 系統(tǒng)改來改去，A 系統(tǒng)的開發(fā)哥們頭皮發(fā)麻。

更復(fù)雜的場景是，數(shù)據(jù)通過接口傳給其他系統(tǒng)有時候還要考慮重試、超時等一些異常情況，真是頭發(fā)都白了呀。

來看下圖，體會一下這無助的現(xiàn)場：

這個時候，就該我們的 MQ 粉墨登場了!這種情況下使用 MQ 來解耦是再合適不過了，因為負(fù)責(zé) A 系統(tǒng)的哥們只需要把消息扔到 MQ 就行了，其他系統(tǒng)按需來訂閱消息就好了。

就算某個系統(tǒng)不需要這個數(shù)據(jù)了，也不會需要 A 系統(tǒng)改動代碼?？纯醇尤?MQ 解耦的下圖，是不是清爽了很多：

削峰填谷

舉個例子，比如我們的訂單系統(tǒng)，在下單的時候就會往數(shù)據(jù)庫寫數(shù)據(jù)。但是數(shù)據(jù)庫只能支撐每秒 1000 左右的并發(fā)寫入，并發(fā)量再高就容易宕機(jī)。

低峰期的時候并發(fā)也就 100 多個，但是在高峰期時候，并發(fā)量會突然激增到 5000 以上，這個時候數(shù)據(jù)庫肯定死了。

如下圖，來感受一下數(shù)據(jù)庫被打死的絕望：

但是使用了 MQ 之后，情況就變了!消息被 MQ 保存起來了，然后系統(tǒng)就可以按照自己的消費(fèi)能力來消費(fèi)，比如每秒 1000 個數(shù)據(jù)，這樣慢慢寫入數(shù)據(jù)庫，這樣就不會打死數(shù)據(jù)庫了。

整個過程，如下圖所示：

至于為什么叫做削峰填谷呢?來看看這個圖：

如果沒有用 MQ 的情況下，并發(fā)量高峰期的時候是有一個“頂峰”的，然后高峰期過后又是一個低并發(fā)的“谷”。

但是使用了 MQ 之后，限制消費(fèi)消息的速度為 1000QPS，但是這樣一來，高峰期產(chǎn)生的數(shù)據(jù)勢必會被積壓在 MQ 中，高峰就被“削”掉了。

但是因為消息積壓，在高峰期過后的一段時間內(nèi)，消費(fèi)消息的速度還是會維持在 1000QPS，直到消費(fèi)完積壓的消息，這就叫做“填谷”。

通過上面的分析，大家就可以知道為什么要使用 MQ，以及使用了 MQ 有什么好處。知其所以然，明白了自己的系統(tǒng)為什么要使用 MQ。

這樣以后別人問你為啥要用 MQ，就不會出現(xiàn) “我們組長要用 MQ 我們就用了” 這樣尷尬的回答了。

使用了 MQ 之后有什么優(yōu)缺點(diǎn)?

看到這個問題蒙圈了，用了就用了嘛!優(yōu)點(diǎn)上面已經(jīng)說了，但是這個缺點(diǎn)是啥啊。好像沒啥缺點(diǎn)啊。

如果你這樣想，就大錯特錯了，在設(shè)計系統(tǒng)的過程中，除了要清楚的知道為什么要用這個東西，還要思考一下用了之后有什么壞處。這樣才能心里有底，防范于未然。

接下來我們就討論一下，用 MQ 會有什么缺點(diǎn)吧?

系統(tǒng)可用性降低

大家想象一下，上面的說解耦的場景，本來 A 系統(tǒng)的哥們要把系統(tǒng)關(guān)鍵數(shù)據(jù)發(fā)送給 BC 系統(tǒng)的，現(xiàn)在突然加入了一個 MQ 了，現(xiàn)在 BC 系統(tǒng)接收數(shù)據(jù)要通過 MQ 來接收。

但是大家有沒有考慮過一個問題，萬一 MQ 掛了怎么辦?這就引出一個問題，加入了 MQ 之后，系統(tǒng)的可用性是不是就降低了?

因為多了一個風(fēng)險因素：MQ 可能會掛掉。只要 MQ 掛了，數(shù)據(jù)沒了，系統(tǒng)運(yùn)行就不對了。

系統(tǒng)復(fù)雜度提高

本來我的系統(tǒng)通過接口調(diào)用一下就能完事的，但是加入一個 MQ 之后，需要考慮消息重復(fù)消費(fèi)、消息丟失、甚至消息順序性的問題。

為了解決這些問題，又需要引入很多復(fù)雜的機(jī)制，這樣一來是不是系統(tǒng)的復(fù)雜度提高了。

數(shù)據(jù)一致性問題

本來好好的，A 系統(tǒng)調(diào)用 BC 系統(tǒng)接口，如果 BC 系統(tǒng)出錯了，會拋出異常，返回給 A 系統(tǒng)讓 A 系統(tǒng)知道，這樣的話就可以做回滾操作了。

但是使用了 MQ 之后，A 系統(tǒng)發(fā)送完消息就完事了，認(rèn)為成功了。而剛好 C 系統(tǒng)寫數(shù)據(jù)庫的時候失敗了，但是 A 認(rèn)為 C 已經(jīng)成功了?這樣一來數(shù)據(jù)就不一致了。

通過分析引入 MQ 的優(yōu)缺點(diǎn)之后，就明白了使用 MQ 有很多優(yōu)點(diǎn)，但是會發(fā)現(xiàn)它帶來的缺點(diǎn)又會需要你做各種額外的系統(tǒng)設(shè)計來彌補(bǔ)。

***你可能會發(fā)現(xiàn)整個系統(tǒng)復(fù)雜了好幾倍，所以設(shè)計系統(tǒng)的時候要基于這些考慮做出取舍，很多時候你會發(fā)現(xiàn)該用的還是要用的。

怎么保證 MQ 消息不丟失?

使用了 MQ 之后，還要關(guān)心消息丟失的問題。這里我們挑 RabbitMQ 來說明一下吧。

生產(chǎn)者弄丟了數(shù)據(jù)

RabbitMQ 生產(chǎn)者將數(shù)據(jù)發(fā)送到 RabbitMQ 的時候，可能數(shù)據(jù)在網(wǎng)絡(luò)傳輸中搞丟了，這個時候 RabbitMQ 收不到消息，消息就丟了。

RabbitMQ 提供了兩種方式來解決這個問題：

事務(wù)方式：在生產(chǎn)者發(fā)送消息之前，通過`channel.txSelect`開啟一個事務(wù)，接著發(fā)送消息。

如果消息沒有成功被 RabbitMQ 接收到，生產(chǎn)者會收到異常，此時就可以進(jìn)行事務(wù)回滾`channel.txRollback`，然后重新發(fā)送。假如 RabbitMQ 收到了這個消息，就可以提交事務(wù)`channel.txCommit`。

但是這樣一來，生產(chǎn)者的吞吐量和性能都會降低很多，現(xiàn)在一般不這么干。

另外一種方式就是通過 Confirm 機(jī)制：這個 Confirm 模式是在生產(chǎn)者那里設(shè)置的，就是每次寫消息的時候會分配一個唯一的 ID，然后 RabbitMQ 收到之后會回傳一個 ACK，告訴生產(chǎn)者這個消息 OK 了。

如果 RabbitMQ 沒有處理到這個消息，那么就回調(diào)一個 Nack 的接口，這個時候生產(chǎn)者就可以重發(fā)。

事務(wù)機(jī)制和 Confirm 機(jī)制***的不同在于事務(wù)機(jī)制是同步的，提交一個事務(wù)之后會阻塞在那兒。

但是 Confirm 機(jī)制是異步的，發(fā)送一個消息之后就可以發(fā)送下一個消息，然后那個消息 RabbitMQ 接收了之后會異步回調(diào)你一個接口通知你這個消息接收到了。

所以一般在生產(chǎn)者這塊避免數(shù)據(jù)丟失，都是用 Confirm 機(jī)制的。

RabbitMQ 弄丟了數(shù)據(jù)

RabbitMQ 集群也會弄丟消息，這個問題在官方文檔的教程中也提到過，就是說在消息發(fā)送到 RabbitMQ 之后，默認(rèn)是沒有落地磁盤的，萬一 RabbitMQ 宕機(jī)了，這個時候消息就丟失了。

所以為了解決這個問題，RabbitMQ 提供了一個持久化的機(jī)制，消息寫入之后會持久化到磁盤。

這樣哪怕是宕機(jī)了，恢復(fù)之后也會自動恢復(fù)之前存儲的數(shù)據(jù)，這樣的機(jī)制可以確保消息不會丟失。

設(shè)置持久化有兩個步驟：

• ***個是創(chuàng)建 Queue 的時候?qū)⑵湓O(shè)置為持久化的，這樣就可以保證 RabbitMQ 持久化 Queue 的元數(shù)據(jù)，但是不會持久化 Queue 里的數(shù)據(jù)。
• 第二個是發(fā)送消息的時候?qū)⑾⒌?deliveryMode 設(shè)置為 2，就是將消息設(shè)置為持久化的，此時 RabbitMQ 就會將消息持久化到磁盤上去。

但是這樣一來可能會有人說：萬一消息發(fā)送到 RabbitMQ 之后，還沒來得及持久化到磁盤就掛掉了，數(shù)據(jù)也丟失了，怎么辦?

對于這個問題，其實(shí)是配合上面的 Confirm 機(jī)制一起來保證的，就是在消息持久化到磁盤之后才會給生產(chǎn)者發(fā)送 ACK 消息。

萬一真的遇到了那種極端的情況，生產(chǎn)者是可以感知到的，此時生產(chǎn)者可以通過重試發(fā)送消息給別的 RabbitMQ 節(jié)點(diǎn)。

消費(fèi)端弄丟了數(shù)據(jù)

RabbitMQ 消費(fèi)端弄丟了數(shù)據(jù)的情況是這樣的：在消費(fèi)消息的時候，剛拿到消息，結(jié)果進(jìn)程掛了，這個時候 RabbitMQ 就會認(rèn)為你已經(jīng)消費(fèi)成功了，這條數(shù)據(jù)就丟了。

對于這個問題，要先說明一下 RabbitMQ 消費(fèi)消息的機(jī)制：在消費(fèi)者收到消息的時候，會發(fā)送一個 ACK 給 RabbitMQ，告訴 RabbitMQ 這條消息被消費(fèi)到了，這樣 RabbitMQ 就會把消息刪除。

但是默認(rèn)情況下這個發(fā)送 ACK 的操作是自動提交的，也就是說消費(fèi)者一收到這個消息就會自動返回 ACK 給 RabbitMQ，所以會出現(xiàn)丟消息的問題。

所以針對這個問題的解決方案就是：關(guān)閉 RabbitMQ 消費(fèi)者的自動提交 ACK，在消費(fèi)者處理完這條消息之后再手動提交 ACK。

這樣即使遇到了上面的情況，RabbitMQ 也不會把這條消息刪除，會在你程序重啟之后，重新下發(fā)這條消息過來。

怎么保證 MQ 的高可用性?

使用了 MQ 之后，我們肯定是希望 MQ 有高可用特性，因為不可能接受機(jī)器宕機(jī)了，就無法收發(fā)消息的情況。

這一塊我們也是基于 RabbitMQ 這種經(jīng)典的 MQ 來說明一下：RabbitMQ 是比較有代表性的，因為是基于主從做高可用性的，我們就以他為例子講解***種 MQ 的高可用性怎么實(shí)現(xiàn)。

RabbitMQ 有三種模式：

• 單機(jī)模式
• 普通集群模式
• 鏡像集群模式

單機(jī)模式

單機(jī)模式就是 Demo 級別的，就是說只有一臺機(jī)器部署了一個 RabbitMQ 程序。

這個會存在單點(diǎn)問題，宕機(jī)就玩完了，沒什么高可用性可言。一般就是你本地啟動了玩玩兒的，沒人生產(chǎn)用單機(jī)模式。

普通集群模式

這個模式的意思就是在多臺機(jī)器上啟動多個 RabbitMQ 實(shí)例。類似的 Master-Slave 模式一樣。

但是創(chuàng)建的 Queue，只會放在一個 Master RabbtiMQ 實(shí)例上，其他實(shí)例都同步那個接收消息的 RabbitMQ 元數(shù)據(jù)。

在消費(fèi)消息的時候，如果你連接到的 RabbitMQ 實(shí)例不是存放 Queue 數(shù)據(jù)的實(shí)例，這個時候 RabbitMQ 就會從存放 Queue 數(shù)據(jù)的實(shí)例上拉取數(shù)據(jù)，然后返回給客戶端。

總的來說，這種方式有點(diǎn)麻煩，沒有做到真正的分布式，每次消費(fèi)者連接一個實(shí)例后拉取數(shù)據(jù)。

如果連接到不是存放 Queue 數(shù)據(jù)的實(shí)例，這個時候會造成額外的性能開銷。如果從放 Queue 的實(shí)例拉取，會導(dǎo)致單實(shí)例性能瓶頸。

如果放 Queue 的實(shí)例宕機(jī)了，會導(dǎo)致其他實(shí)例無法拉取數(shù)據(jù)，這個集群都無法消費(fèi)消息了，沒有做到真正的高可用。

所以這個事兒就比較尷尬了，這就沒有什么所謂的高可用性可言了，這方案主要是提高吞吐量的，就是說讓集群中多個節(jié)點(diǎn)來服務(wù)某個 Queue 的讀寫操作。

鏡像集群模式

鏡像集群模式才是真正的 RabbitMQ 的高可用模式，跟普通集群模式不一樣的是：創(chuàng)建的 Queue 無論元數(shù)據(jù)還是 Queue 里的消息都會存在于多個實(shí)例上。

每次寫消息到 Queue 的時候，都會自動把消息到多個實(shí)例的 Queue 里進(jìn)行消息同步。

這樣的話任何一個機(jī)器宕機(jī)了，別的實(shí)例都可以用來提供服務(wù)，這樣就做到了真正的高可用了。

但是也存在著不好之處：

• 性能開銷過高，消息需要同步所有機(jī)器，會導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重。
• 擴(kuò)展性低：無法解決某個 Queue 數(shù)據(jù)量特別大的情況，導(dǎo)致 Queue 無法線性拓展。就算加了機(jī)器，那個機(jī)器也會包含 Queue 的所有數(shù)據(jù)，Queue 的數(shù)據(jù)沒有做到分布式存儲。

對于 RabbitMQ 的高可用一般的做法都是開啟鏡像集群模式，這樣起碼來說做到了高可用，一個節(jié)點(diǎn)宕機(jī)了，其他節(jié)點(diǎn)可以繼續(xù)提供服務(wù)。

總結(jié)

通過本篇文章，分析了對于 MQ 的一些常規(guī)問題：

• 為什么使用 MQ?
• 使用 MQ 有什么優(yōu)缺點(diǎn)?
• 如何保證消息不丟失?
• 如何保證 MQ 高可用性?

但是，這些問題僅僅是使用 MQ 的其中一部分需要考慮的問題，事實(shí)上，還有其他更加復(fù)雜的問題需要我們?nèi)ソ鉀Q。

比如：如何保證消息的順序性?消息隊列如何選型?消息積壓問題如何解決?

本文僅僅是針對 RabbitMQ 的場景舉例子。還有其他比較的消息隊列，比如 RocketMQ、Kafka。

不同的 MQ 在面臨上述問題的時候，要根據(jù)他們的原理機(jī)制來做對應(yīng)的處理，這些都是本文沒有顧及的內(nèi)容，將在后面的文章中討論。