一文讀懂MQ消息隊列
MQ(消息隊列)在軟件架構中是經常被使用的，特別是在分布式系統(tǒng)中也是使用頻率很高的組件。
以下從消息隊列的使用場景、概念、常見問題及解決方案來詳細講解。
一、消息隊列使用場景
1.1 常見的使用場景
系統(tǒng)解耦
在分布式環(huán)境下，系統(tǒng)間的相互依賴，最終會會導致整個依賴關系混亂，特別在微服務環(huán)境下，會出現相互依賴，甚至是循環(huán)依賴的情況，對后期系統(tǒng)的拆分和優(yōu)化都帶來極大負擔。那么我們就可以用MQ來進行處理。上游系統(tǒng)將數據投遞到MQ，下游系統(tǒng)取MQ的數據進行消費，投遞和消費可以用同步的方式處理，因為MQ接收數據的性能是非常高的，不會影響上游系統(tǒng)的性能。
異步處理
如果采用同步的方式，系統(tǒng)的性能(并發(fā)量，吞吐量，響應時間)會有瓶頸。如何解決這個問題呢?引入消息隊列，將不必要的業(yè)務邏輯異步處理。
異步處理也可以引來 并行處理的使用姿勢。在工作中，我們基于消息開發(fā)了一個簡單的分布式任務處理組件。該組件簡單分為三塊分別是 切分、加載、執(zhí)行三個階段
每個階段都是以作為消費者，然后處理完畢后再作為生產者發(fā)送消息。消息消費無狀態(tài)，可以按需無限拓容。
流量削峰
由于使用消息，我們的鏈路變成了生產者發(fā)送消息，消息中間件存儲消息，最后消費者從消息中間件拉取消息的一個過程。而消息中間件的存儲能力能夠有效的幫助消費者進行緩沖。試想下，正常流量下消費者能夠愉快的進行消費，瞬時高峰流量來的時候，消費者消費能力跟不上，剛好阻塞在消息中間件，等峰值過后，消費者又能很快的將阻塞的消息進行消費。
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛!
數據分發(fā)
大部分開源的MQ中間件基本都支持一對多或者廣播的模式，而且都可以根據規(guī)則選擇分發(fā)的對象。這樣上游的一份數據，眾多下游系統(tǒng)中，可以根據規(guī)則選擇是否接收這些數據，這樣擴展性就很強了。
1.2 消息使用的先決條件
以上四種是MQ中間件最常見的場景，但是我們細想，MQ中間件的引入會帶來什么問題呢?那就是實時性。所以MQ中間件使用的先決條件是：能容忍延遲，只要求最終一致性較為合適。
二、消息相關的概念
MQ特點
- 先進先出
- 不能先進先出，都不能說是隊列了。消息隊列的順序在入隊的時候就基本已經確定了，一般是不需人工干預的。而且，最重要的是，數據是只有一條數據在使用中。 這也是MQ在諸多場景被使用的原因。
- 發(fā)布訂閱
- 發(fā)布訂閱是一種很高效的處理方式，如果不發(fā)生阻塞，基本可以當做是同步操作。這種處理方式能非常有效的提升服務器利用率，這樣的應用場景非常廣泛。
- 持久化
- 持久化確保MQ的使用不只是一個部分場景的輔助工具，而是讓MQ能像數據庫一樣存儲核心的數據。
- 分布式
- 在現在大流量、大數據的使用場景下，只支持單體應用的服務器軟件基本是無法使用的，支持分布式的部署，才能被廣泛使用。而且，MQ的定位就是一個高性能的中間件。
在JMS標準中，有兩種消息模型P2P(Point toPoint)和Publish/Sub(Pub/Sub)。
P2P
點對點，一個發(fā)，一個消費。涉及到的角色 發(fā)布者(Publisher)、消費者(Consumer)、消息隊列(Queue)
特點
一個消息只能被一個消費者消費，消費后會從隊列里移除
發(fā)布者和消費者無關系，發(fā)布者發(fā)送消息的行為不會隨消費者而改變
消費者消費完成消息，需要向隊列Ack，消息隊列發(fā)現消息消費成功即做消息移除
Pub/Sub
發(fā)布訂閱模式，一個發(fā)布，多方訂閱。涉及到的角色有 發(fā)布者(Publisher)、主題(Topic)、訂閱者(Subscriber)。
特點
- 每個消息可以有多個消費者
- 針對某個主題(Topic)的訂閱者，必須創(chuàng)建一個訂閱者之后，才能消費發(fā)布者的消息
- 為了消費消息，訂閱者必須保持運行的狀態(tài)
三、常見問題及解決方案
消息阻塞
1、消息阻塞一般都是流量激增，超過消費者消費能力;
2、或者消費者出現邏輯問題，導致不斷的重試或長時間等待。
第一種可以通過擴容解決
第二種只能緊急修復問題，發(fā)布上線，在阻塞的過程中會造成大量的消息積壓，這種情況也可以考慮臨時擴容
重復消費
重復消費一般發(fā)生下消費端，比如消費者處理完畢，在準備進行ack的時候出現了問題，應用重啟后，消息中間件以為該消息還未處理又推給了消費者，或者消費者拉取的時候重復。
一般的做法是消費端做冪等。
消息丟失
消息丟失一般分為生產者發(fā)送失敗、消息中間件丟失、消費丟失。
生產者丟失：可能以為網絡問題或者消息中間處理失敗導致，消息遺漏。
消息中間的丟失：一般中間件可以設置丟棄策略，大部分MQ中間件產品可以保證數據不丟失，這種情況基本不用考慮。
消費丟失：有的消息中間件支持自動ack，當消費者消費到消息，消息中間件也不管是否消費成功自動ack。這時候一般選擇消費者主動ack比較合適。
消息順序性
消息順序性一般通過MQ中間件保證，大部分MQ中間件只能做到局部有序，比如Kafka，只能保證單個partition隊列有序。有些也會做到全局有序，但是成本比較高。筆者目前服務的公司現在是支持全局有序的。
MQ組件有activeMQ、rabbitMQ、rocketMQ、zeroMQ、Kafka;有興趣的同學可以深入去了解。
