一、什么叫消息隊列

MQ(Message Quene) : 翻譯為 消息隊列,通過典型的 生產者和消費者模型,生產者不斷向消息隊列中生產消息，消費者不斷的從隊列中獲取消息。因為消息的生產和消費都是異步的，而且只關心消息的發送和接收，沒有業務邏輯的侵入,輕松的實現系統間解耦。別名為消息中間件，通過利用高效可靠的消息傳遞機制進行平臺無關的數據交流，并基于數據通信來進行分布式系統的集成。

二、為何用消息隊列

從上面的描述中可以看出消息隊列是一種應用間的異步協作機制，那什么時候需要使用 MQ 呢？
以常見的訂單系統為例，用戶點擊【下單】按鈕之后的業務邏輯可能包括：扣減庫存、生成相應單據、發紅包、發短信通知。在業務發展初期這些邏輯可能放在一起同步執行，隨著業務的發展訂單量增長，需要提升系統服務的性能，這時可以將一些不需要立即生效的操作拆分出來異步執行，比如發放紅包、發短信通知等。這種場景下就可以用 MQ ，在下單的主流程（比如扣減庫存、生成相應單據）完成之后發送一條消息到 MQ 讓主流程快速完結，而由另外的單獨線程拉取MQ的消息（或者由 MQ 推送消息），當發現 MQ 中有發紅包或發短信之類的消息時，執行相應的業務邏輯。
以上是用于業務解耦的情況，其它常見場景包括最終一致性、廣播、錯峰流控等等。

三、使用消息隊列的好處

通過異步處理提高系統性能（削峰、減少響應所需時間）

通過異步處理提高系統性能

如上圖，在不使用消息隊列服務器的時候，用戶的請求數據直接寫入數據庫，在高并發的情況下數據庫壓力劇增，使得響應速度變慢。但是在使用消息隊列之后，用戶的請求數據發送給消息隊列之后立即 返回，再由消息隊列的消費者進程從消息隊列中獲取數據，異步寫入數據庫。由于消息隊列服務器處理速度快于數據庫（消息隊列也比數據庫有更好的伸縮性），因此響應速度得到大幅改善。

通過以上分析我們可以得出消息隊列具有很好的削峰作用的功能——即通過異步處理，將短時間高并發產生的事務消息存儲在消息隊列中，從而削平高峰期的并發事務。 舉例：在電子商務一些秒殺、促銷活動中，合理使用消息隊列可以有效抵御促銷活動剛開始大量訂單涌入對系統的沖擊。如下圖所示：

合理使用消息隊列可以有效抵御促銷活動剛開始大量訂單涌入對系統的沖擊

因為用戶請求數據寫入消息隊列之后就立即返回給用戶了，但是請求數據在后續的業務校驗、寫數據庫等操作中可能失敗。因此使用消息隊列進行異步處理之后，需要適當修改業務流程進行配合，比如用戶在提交訂單之后，訂單數據寫入消息隊列，不能立即返回用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單之后，甚至出庫后，再通過電子郵件或短信通知用戶訂單成功，以免交易糾紛。這就類似我們平時手機訂火車票和電影票。

降低系統耦合性

我們知道如果模塊之間不存在直接調用，那么新增模塊或者修改模塊就對其他模塊影響較小，這樣系統的可擴展性無疑更好一些。

我們最常見的事件驅動架構類似生產者消費者模式，在大型網站中通常用利用消息隊列實現事件驅動結構。如下圖所示：

利用消息隊列實現事件驅動結構

消息隊列使利用發布-訂閱模式工作，消息發送者（生產者）發布消息，一個或多個消息接受者（消費者）訂閱消息。 從上圖可以看到消息發送者（生產者）和消息接受者（消費者）之間沒有直接耦合，消息發送者將消息發送至分布式消息隊列即結束對消息的處理，消息接受者從分布式消息隊列獲取該消息后進行后續處理，并不需要知道該消息從何而來。對新增業務，只要對該類消息感興趣，即可訂閱該消息，對原有系統和業務沒有任何影響，從而實現網站業務的可擴展性設計。

消息接受者對消息進行過濾、處理、包裝后，構造成一個新的消息類型，將消息繼續發送出去，等待其他消息接受者訂閱該消息。因此基于事件（消息對象）驅動的業務架構可以是一系列流程。

另外為了避免消息隊列服務器宕機造成消息丟失，會將成功發送到消息隊列的消息存儲在消息生產者服務器上，等消息真正被消費者服務器處理后才刪除消息。在消息隊列服務器宕機后，生產者服務器會選擇分布式消息隊列服務器集群中的其他服務器發布消息。

備注： 不要認為消息隊列只能利用發布-訂閱模式工作，只不過在解耦這個特定業務環境下是使用發布-訂閱模式的。除了發布-訂閱模式，還有點對點訂閱模式（一個消息只有一個消費者），我們比較常用的是發布-訂閱模式。 另外，這兩種消息模型是 JMS 提供的，AMQP 協議還提供了 5 種消息模型。

四、消息隊列的缺點

• 系統可用性降低： 系統可用性在某種程度上降低，為什么這樣說呢？在加入MQ之前，你不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之后你就需要去考慮了！
• 系統復雜性提高： 加入MQ之后，你需要保證消息沒有被重復消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！
• 一致性問題： 我上面講了消息隊列可以實現異步，消息隊列帶來的異步確實可以提高系統響應速度。但是，萬一消息的真正消費者并沒有正確消費消息怎么辦？這樣就會導致數據不一致的情況了!

五、不同MQ特點

ActiveMQ
ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。它是一個完全支持JMS規范的的消息中間件。豐富的API,多種集群架構模式讓ActiveMQ在業界成為老牌的消息中間件,在中小型企業頗受歡迎!

Kafka
Kafka是LinkedIn開源的分布式發布-訂閱消息系統，目前歸屬于Apache頂級項目。Kafka主要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸。0.8版本開始支持復制，不支持事務，對消息的重復、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。（新版本已經支持一致性了）

RocketMQ
RocketMQ是阿里開源的消息中間件，它是純Java開發，具有高吞吐量、高可用性、適合大規模分布式系統應用的特點。RocketMQ思路起源于Kafka，但并不是Kafka的一個Copy，它對消息的可靠傳輸及事務性做了優化，目前在阿里集團被廣泛應用于交易、充值、流計算、消息推送、日志流式處理、binglog分發等場景。

RabbitMQ
RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基于AMQP協議來實現。AMQP的主要特征是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。AMQP協議更多用在企業系統內對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在。

六、MQ的應用

• 異步處理
  如用戶注冊后，需要發送注冊郵件和注冊短信。使用MQ后，接口的響應效率將大大提高。
• 應用解耦
  如用戶下單后，訂單系統需要通知庫存系統 。使用MQ后，訂單系統寫入消息隊列就不再關心其他的后續操作了。實現訂單系統與庫存系統的應用解耦
• 流量削峰
  一般發生在短時間內的大量請求，如秒殺、團搶活動等。使用MQ后，可以控制活動的人數 ，緩解短時間內高流量壓垮應用 。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面。 秒殺業務根據消息隊列中的請求信息，再做后續處理 。
• 消息通訊
  可以實現點對點消息隊列，或者聊天室等
• 日志處理
  如Kafka的應用，可解決大量日志傳輸的問題

總結

以上是生活随笔為你收集整理的何为消息队列，为何使用消息队列，有什么消息队列插件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。