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

[[274734]]

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

一、消息隊列使用場景

1.1 常見的使用場景

系統(tǒng)解耦

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

異步處理

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

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

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

流量削峰

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

流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛!

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

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

1.2 消息使用的先決條件

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

二、消息相關的概念

MQ特點

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

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

P2P

點對點，一個發(fā)，一個消費。涉及到的角色 發(fā)布者(Publisher)、消費者(Consumer)、消息隊列(Queue)

特點

一個消息只能被一個消費者消費，消費后會從隊列里移除

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

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

Pub/Sub

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

特點

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

三、常見問題及解決方案

消息阻塞

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

2、或者消費者出現(xiàn)邏輯問題，導致不斷的重試或長時間等待。

第一種可以通過擴容解決

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

重復消費

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

一般的做法是消費端做冪等。

消息丟失

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

生產者丟失：可能以為網絡問題或者消息中間處理失敗導致，消息遺漏。

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

消費丟失：有的消息中間件支持自動ack，當消費者消費到消息，消息中間件也不管是否消費成功自動ack。這時候一般選擇消費者主動ack比較合適。

消息順序性

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

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