文章目錄

• • • • • 1. 消息隊列是什么
        • 2. 消息隊列作用
        • 3. 消息隊列優(yōu)點以及缺點
        • • 3.1 優(yōu)點
          • 3.2 缺點
        • 4. 消息隊列應用場景
        • • 4.1 異步處理
          • 4.2 應用解耦
          • 4.3 流量削鋒
          • 4.4 消息通訊
        • 5. 消息隊列的兩種模式
        • • 5.1 點對點模式
          • 5.2 發(fā)布/訂閱模式
        • 6.消息隊列中間件有哪些，有什么區(qū)別？

1. 消息隊列是什么

消息隊列是一個存放消息的容器，當我們需要時可以取出使用。

消息隊列可以完成異步處理，提高系統(tǒng)性能。

消息隊列可以削峰平谷，消息隊列可以緩解短時間內(nèi)高流量壓垮應用

2. 消息隊列作用

通過異步處理提高系統(tǒng)性能（削峰、減少響應所需時間），即通過異步處理，將短時間高并發(fā)產(chǎn)生的事務消息存儲在消息隊列中，從而削平高峰期的并發(fā)事務。例如：電子商務中的秒殺，促銷活動

降低系統(tǒng)耦合性

消息隊列使利用發(fā)布-訂閱模式工作，消息發(fā)送者（生產(chǎn)者）發(fā)布消息，一個或多個消息接受者（消費者）訂閱消息. 消息發(fā)送者（生產(chǎn)者）和消息接受者（消費者）之間沒有直接耦合，消息發(fā)送者將消息發(fā)送至分布式消息隊列即結(jié)束對消息的處理，消息接受者從分布式消息隊列獲取該消息后進行后續(xù)處理，并不需要知道該消息從何而來。對新增業(yè)務，只要對該類消息感興趣，即可訂閱該消息，對原有系統(tǒng)和業(yè)務沒有任何影響，從而實現(xiàn)網(wǎng)站業(yè)務的可擴展性設計。

3. 消息隊列優(yōu)點以及缺點

3.1 優(yōu)點

應用耦合：多應用間通過消息隊列對同一消息進行處理，避免調(diào)用接口失敗導致整個過程失敗；

異步處理：多應用對消息隊列中同一消息進行處理，應用間并發(fā)處理消息，相比串行處理，減少處理時間；

限流削峰：廣泛應用于秒殺或搶購活動中，避免流量過大導致應用系統(tǒng)掛掉的情況；那個

消息驅(qū)動的系統(tǒng)：系統(tǒng)分為消息隊列、消息生產(chǎn)者、消息消費者，生產(chǎn)者負責產(chǎn)生消息，消費者(可能有多個)負責對消息進行處理；

3.2 缺點

系統(tǒng)可用性降低： 系統(tǒng)可用性在某種程度上降低，在加入MQ之前，你不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之后你就需要去考慮了！

系統(tǒng)復雜性提高： 加入MQ之后，你需要保證消息沒有被重復消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！

一致性問題：消息隊列可以實現(xiàn)異步，消息隊列帶來的異步確實可以提高系統(tǒng)響應速度。但是，萬一消息的真正消費者并沒有正確消費消息，這樣就會導致數(shù)據(jù)不一致的情況了!

4. 消息隊列應用場景

4.1 異步處理

例如：用戶注冊
場景說明：用戶注冊后，需要發(fā)注冊郵件和注冊短信。傳統(tǒng)的做法有兩種 1.串行的方式；2.并行方式
4.1.1 傳統(tǒng)方式

串行的方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件，再發(fā)送注冊短信。以上三個任務全部完成后，返回給客戶端

并行方式：將注冊信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊郵件的同時，發(fā)送注冊短信。以上三個任務完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時間

4.1.2 引入消息隊列:將不是必須的業(yè)務邏輯，異步處理。

4.2 應用解耦

例如：用戶下單
場景說明：用戶下單后，訂單系統(tǒng)需要通知庫存系統(tǒng)。傳統(tǒng)的做法是，訂單系統(tǒng)調(diào)用庫存系統(tǒng)的接口，如下圖

4.2.1 傳統(tǒng)模式缺點

• 假如庫存系統(tǒng)無法訪問，則訂單減庫存將失敗，從而導致訂單失敗

• 訂單系統(tǒng)與庫存系統(tǒng)耦合
  4.2.2 引入隊列
  

• 訂單系統(tǒng)：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊列，返回用戶下單成功

• 庫存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統(tǒng)根據(jù)下單信息，進行庫存操作

• 假如：在下單時庫存系統(tǒng)不能正常使用。也不影響正常下單，因為下單后，訂單系統(tǒng)寫入消息隊列就不再關心其他的后續(xù)操作了。實現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應用解耦

4.3 流量削鋒

例如：秒殺活動
應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。

• 可以控制活動的人數(shù)

• 可以緩解短時間內(nèi)高流量壓垮應用
  

• 用戶的請求，服務器接收后，首先寫入消息隊列。假如消息隊列長度超過最大數(shù)量，則直接拋棄用戶請求或跳轉(zhuǎn)到錯誤頁面

• 秒殺業(yè)務根據(jù)消息隊列中的請求信息，再做后續(xù)處理

4.4 消息通訊

消息通訊是指，消息隊列一般都內(nèi)置了高效的通信機制，因此也可以用在純的消息通訊。比如實現(xiàn)點對點消息隊列，或者聊天室等

• 點對點通訊
  
• 聊天室通訊
  

5. 消息隊列的兩種模式

消息隊列包括兩種模式，點對點模式（point to point， queue）和發(fā)布/訂閱模式（publish/subscribe，topic）

5.1 點對點模式

• 點對點模式三個角色
• 消息隊列
• 發(fā)送者 (生產(chǎn)者)
• 接收者（消費者）
  

5.1.1 點對點模式特點：

• 每個消息只有一個接收者（Consumer）(即一旦被消費，消息就不再在消息隊列中)；
• 發(fā)送者和接收者間沒有依賴性，發(fā)送者發(fā)送消息之后，不管有沒有接收者在運行，都不會影響到發(fā)送者下次發(fā)送消息；
• 接收者在成功接收消息之后需向隊列應答成功，以便消息隊列刪除當前接收的消息；

5.2 發(fā)布/訂閱模式

• 發(fā)布/訂閱模式下包括三個角色
• 角色主題（Topic）
• 發(fā)布者(Publisher)
• 訂閱者(Subscriber)
  

5.2.1發(fā)布/訂閱模式特點：

• 每個消息可以有多個訂閱者；
• 發(fā)布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創(chuàng)建一個訂閱者之后，才能消費發(fā)布者的消息。
• 為了消費消息，訂閱者需要提前訂閱該角色主題，并保持在線運行；

6.消息隊列中間件有哪些，有什么區(qū)別？

綜上，各種對比之后，有如下建議：

一般的業(yè)務系統(tǒng)要引入 MQ，最早大家都用 ActiveMQ，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；

后來大家開始用 RabbitMQ，但是確實 erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言，幾乎處于不可控的狀態(tài)，但是確實人家是開源的，比較穩(wěn)定的支持，活躍度也高；

不過現(xiàn)在確實越來越多的公司會去用 RocketMQ，確實很不錯，畢竟是阿里出品，但社區(qū)可能有突然黃掉的風險（目前 RocketMQ 已捐給 Apache，但 GitHub 上的活躍度其實不算高）對自己公司技術實力有絕對自信的，推薦用 RocketMQ，否則回去老老實實用 RabbitMQ 吧，人家有活躍的開源社區(qū)，絕對不會黃。

所以中小型公司，技術實力較為一般，技術挑戰(zhàn)不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發(fā)實力較強，用 RocketMQ 是很好的選擇。

如果是大數(shù)據(jù)領域的實時計算、日志采集等場景，用 Kafka 是業(yè)內(nèi)標準的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規(guī)范。

參考博客
https://www.cnblogs.com/midoujava/p/11488925.html.
https://www.zhihu.com/people/yi-ke-bai-cai-cai-87/posts.

總結(jié)

以上是生活随笔為你收集整理的消息队列MQ快速入门的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。