MQ(消息隊(duì)列)在軟件架構(gòu)中是經(jīng)常被使用的，特別是在分布式系統(tǒng)中也是使用頻率很高的組件。

[[274734]]

以下從消息隊(duì)列的使用場景、概念、常見問題及解決方案來詳細(xì)講解。

一、消息隊(duì)列使用場景

1.1 常見的使用場景

系統(tǒng)解耦

在分布式環(huán)境下，系統(tǒng)間的相互依賴，最終會會導(dǎo)致整個(gè)依賴關(guān)系混亂，特別在微服務(wù)環(huán)境下，會出現(xiàn)相互依賴，甚至是循環(huán)依賴的情況，對后期系統(tǒng)的拆分和優(yōu)化都帶來極大負(fù)擔(dān)。那么我們就可以用MQ來進(jìn)行處理。上游系統(tǒng)將數(shù)據(jù)投遞到MQ，下游系統(tǒng)取MQ的數(shù)據(jù)進(jìn)行消費(fèi)，投遞和消費(fèi)可以用同步的方式處理，因?yàn)镸Q接收數(shù)據(jù)的性能是非常高的，不會影響上游系統(tǒng)的性能。

異步處理

如果采用同步的方式，系統(tǒng)的性能(并發(fā)量，吞吐量，響應(yīng)時(shí)間)會有瓶頸。如何解決這個(gè)問題呢?引入消息隊(duì)列，將不必要的業(yè)務(wù)邏輯異步處理。

異步處理也可以引來 并行處理的使用姿勢。在工作中，我們基于消息開發(fā)了一個(gè)簡單的分布式任務(wù)處理組件。該組件簡單分為三塊分別是 切分、加載、執(zhí)行三個(gè)階段

每個(gè)階段都是以作為消費(fèi)者，然后處理完畢后再作為生產(chǎn)者發(fā)送消息。消息消費(fèi)無狀態(tài)，可以按需無限拓容。

流量削峰

由于使用消息，我們的鏈路變成了生產(chǎn)者發(fā)送消息，消息中間件存儲消息，最后消費(fèi)者從消息中間件拉取消息的一個(gè)過程。而消息中間件的存儲能力能夠有效的幫助消費(fèi)者進(jìn)行緩沖。試想下，正常流量下消費(fèi)者能夠愉快的進(jìn)行消費(fèi)，瞬時(shí)高峰流量來的時(shí)候，消費(fèi)者消費(fèi)能力跟不上，剛好阻塞在消息中間件，等峰值過后，消費(fèi)者又能很快的將阻塞的消息進(jìn)行消費(fèi)。

流量削鋒也是消息隊(duì)列中的常用場景，一般在秒殺或團(tuán)搶活動(dòng)中使用廣泛!

數(shù)據(jù)分發(fā)

大部分開源的MQ中間件基本都支持一對多或者廣播的模式，而且都可以根據(jù)規(guī)則選擇分發(fā)的對象。這樣上游的一份數(shù)據(jù)，眾多下游系統(tǒng)中，可以根據(jù)規(guī)則選擇是否接收這些數(shù)據(jù)，這樣擴(kuò)展性就很強(qiáng)了。

1.2 消息使用的先決條件

以上四種是MQ中間件最常見的場景，但是我們細(xì)想，MQ中間件的引入會帶來什么問題呢?那就是實(shí)時(shí)性。所以MQ中間件使用的先決條件是：能容忍延遲，只要求最終一致性較為合適。

二、消息相關(guān)的概念

MQ特點(diǎn)

• 先進(jìn)先出
• 不能先進(jìn)先出，都不能說是隊(duì)列了。消息隊(duì)列的順序在入隊(duì)的時(shí)候就基本已經(jīng)確定了，一般是不需人工干預(yù)的。而且，最重要的是，數(shù)據(jù)是只有一條數(shù)據(jù)在使用中。 這也是MQ在諸多場景被使用的原因。
• 發(fā)布訂閱
• 發(fā)布訂閱是一種很高效的處理方式，如果不發(fā)生阻塞，基本可以當(dāng)做是同步操作。這種處理方式能非常有效的提升服務(wù)器利用率，這樣的應(yīng)用場景非常廣泛。
• 持久化
• 持久化確保MQ的使用不只是一個(gè)部分場景的輔助工具，而是讓MQ能像數(shù)據(jù)庫一樣存儲核心的數(shù)據(jù)。
• 分布式
• 在現(xiàn)在大流量、大數(shù)據(jù)的使用場景下，只支持單體應(yīng)用的服務(wù)器軟件基本是無法使用的，支持分布式的部署，才能被廣泛使用。而且，MQ的定位就是一個(gè)高性能的中間件。

在JMS標(biāo)準(zhǔn)中，有兩種消息模型P2P(Point toPoint)和Publish/Sub(Pub/Sub)。

P2P

點(diǎn)對點(diǎn)，一個(gè)發(fā)，一個(gè)消費(fèi)。涉及到的角色 發(fā)布者(Publisher)、消費(fèi)者(Consumer)、消息隊(duì)列(Queue)

特點(diǎn)

一個(gè)消息只能被一個(gè)消費(fèi)者消費(fèi)，消費(fèi)后會從隊(duì)列里移除

發(fā)布者和消費(fèi)者無關(guān)系，發(fā)布者發(fā)送消息的行為不會隨消費(fèi)者而改變

消費(fèi)者消費(fèi)完成消息，需要向隊(duì)列Ack，消息隊(duì)列發(fā)現(xiàn)消息消費(fèi)成功即做消息移除

Pub/Sub

發(fā)布訂閱模式，一個(gè)發(fā)布，多方訂閱。涉及到的角色有 發(fā)布者(Publisher)、主題(Topic)、訂閱者(Subscriber)。

特點(diǎn)

1. 每個(gè)消息可以有多個(gè)消費(fèi)者
2. 針對某個(gè)主題(Topic)的訂閱者，必須創(chuàng)建一個(gè)訂閱者之后，才能消費(fèi)發(fā)布者的消息
3. 為了消費(fèi)消息，訂閱者必須保持運(yùn)行的狀態(tài)

三、常見問題及解決方案

消息阻塞

1、消息阻塞一般都是流量激增，超過消費(fèi)者消費(fèi)能力;

2、或者消費(fèi)者出現(xiàn)邏輯問題，導(dǎo)致不斷的重試或長時(shí)間等待。

第一種可以通過擴(kuò)容解決

第二種只能緊急修復(fù)問題，發(fā)布上線，在阻塞的過程中會造成大量的消息積壓，這種情況也可以考慮臨時(shí)擴(kuò)容

重復(fù)消費(fèi)

重復(fù)消費(fèi)一般發(fā)生下消費(fèi)端，比如消費(fèi)者處理完畢，在準(zhǔn)備進(jìn)行ack的時(shí)候出現(xiàn)了問題，應(yīng)用重啟后，消息中間件以為該消息還未處理又推給了消費(fèi)者，或者消費(fèi)者拉取的時(shí)候重復(fù)。

一般的做法是消費(fèi)端做冪等。

消息丟失

消息丟失一般分為生產(chǎn)者發(fā)送失敗、消息中間件丟失、消費(fèi)丟失。

生產(chǎn)者丟失：可能以為網(wǎng)絡(luò)問題或者消息中間處理失敗導(dǎo)致，消息遺漏。

消息中間的丟失：一般中間件可以設(shè)置丟棄策略，大部分MQ中間件產(chǎn)品可以保證數(shù)據(jù)不丟失，這種情況基本不用考慮。

消費(fèi)丟失：有的消息中間件支持自動(dòng)ack，當(dāng)消費(fèi)者消費(fèi)到消息，消息中間件也不管是否消費(fèi)成功自動(dòng)ack。這時(shí)候一般選擇消費(fèi)者主動(dòng)ack比較合適。

消息順序性

消息順序性一般通過MQ中間件保證，大部分MQ中間件只能做到局部有序，比如Kafka，只能保證單個(gè)partition隊(duì)列有序。有些也會做到全局有序，但是成本比較高。筆者目前服務(wù)的公司現(xiàn)在是支持全局有序的。

MQ組件有activeMQ、rabbitMQ、rocketMQ、zeroMQ、Kafka;有興趣的同學(xué)可以深入去了解。