消息隊列已經逐漸成為分布式應用場景、內部通信、以及秒殺等高并發業務場景的核心手段，它具有低耦合、可靠投遞、廣播、流量控制、最終一致性 等一系列功能。

無論是 RabbitMQ、RocketMQ、ActiveMQ、Kafka還是其它等，都有的一些基本原理、術語、機制等，總結分享出來，希望大家在使用消息隊列技術的時候能夠快速理解。

1. 消息生產者、消息者、隊列

• 消息生產者Producer：發送消息到消息隊列。
• 消息消費者Consumer：從消息隊列接收消息。
• Broker：概念來自與Apache ActiveMQ，指MQ的服務端，幫你把消息從發送端傳送到接收端。
• 消息隊列Queue：一個先進先出的消息存儲區域。消息按照順序發送接收，一旦消息被消費處理，該消息將從隊列中刪除。

2.設計Broker主要考慮

1）消息的轉儲：在更合適的時間點投遞，或者通過一系列手段輔助消息最終能送達消費機。

2）規范一種范式和通用的模式，以滿足解耦、最終一致性、錯峰等需求。

3）其實簡單理解就是一個消息轉發器，把一次RPC做成兩次RPC。發送者把消息投遞到broker，broker再將消息轉發一手到接收端。

總結起來就是兩次RPC加一次轉儲，如果要做消費確認，則是三次RPC。

3. 點對點消息隊列模型

點對點模型 用于 消息生產者 和 消息消費者 之間 點到點 的通信。

點對點模式包含三個角色：

• 消息隊列（Queue）
• 發送者（Sender）
• 接收者（Receiver）

每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，可以放在 內存 中也可以 持久化，直到他們被消費或超時。

特點

• 每個消息只有一個消費者（Consumer）（即一旦被消費，消息就不再在消息隊列中）
• 發送者和接收者之間在時間上沒有依賴性
• 接收者在成功接收消息之后需向隊列應答成功

4. 發布訂閱消息模型Topic

發布訂閱模型包含三個角色：

• 主題（Topic）
• 發布者（Publisher）
• 訂閱者（Subscriber）

多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

特點

• 每個消息可以有多個消費者：和點對點方式不同，發布消息可以被所有訂閱者消費
• 發布者和訂閱者之間有時間上的依賴性。
• 針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之后，才能消費發布者的消息。
• 為了消費消息，訂閱者必須保持運行的狀態。

5.點對點和發布訂閱的區別

生產者發送一條消息到隊列queue，只有一個消費者能收到。

發布者發送到topic的消息，只有訂閱了topic的訂閱者才會收到消息。

6. 消息的順序性保證

基于Queue消息模型，利用FIFO先進先出的特性，可以保證消息的順序性。

7. 消息的ACK機制

即消息的Ackownledge確認機制，

為了保證消息不丟失，消息隊列提供了消息Acknowledge機制，即ACK機制，當Consumer確認消息已經被消費處理，發送一個ACK給消息隊列，此時消息隊列便可以刪除這個消

息了。如果Consumer宕機/關閉，沒有發送ACK，消息隊列將認為這個消息沒有被處理，會將這個消息重新發送給其他的Consumer重新消費處理。

8.最終一致性的設計思路

主要是用“記錄”和“補償”的方式。

本地事務維護業務變化和通知消息，一起落地，然后RPC到達broker，在broker成功落地后，RPC返回成功，本地消息可以刪除。否則本地消息一直靠定時任務輪詢不斷重發，這樣就保證了消息可靠落地broker。

broker往consumer發送消息的過程類似，一直發送消息，直到consumer發送消費成功確認。

我們先不理會重復消息的問題，通過兩次消息落地加補償，下游是一定可以收到消息的。然后依賴狀態機版本號等方式做判重，更新自己的業務，就實現了最終一致性。

如果出現消費方處理過慢消費不過來，要允許消費方主動ack error，并可以與broker約定下次投遞的時間。

對于broker投遞到consumer的消息，由于不確定丟失是在業務處理過程中還是消息發送丟失的情況下，有必要記錄下投遞的IP地址。決定重發之前詢問這個IP，消息處理成功了嗎？如果詢問無果，再重發。

事務：本地事務，本地落地，補償發送。本地事務做的，是業務落地和消息落地的事務，而不是業務落地和RPC成功的事務。消息只要成功落地，很大程度上就沒有丟失的風險。

9. 消息的事務支持

消息的收發處理支持事務，例如：在任務中心場景中，一次處理可能涉及多個消息的接收、處理，這應該處于同一個事務范圍內，如果一個消息處理失敗，事務回滾，消息重新回到隊列中。

10. 消息的持久化

消息的持久化，對于一些關鍵的核心業務來說是非常重要的，啟用消息持久化后，消息隊列宕機重啟后，消息可以從持久化存儲恢復，消息不丟失，可以繼續消費處理。

11. 消息隊列的高可用性

在實際生產環境中，使用單個實例的消息隊列服務，如果遇到宕機、重啟等系統問題，消息隊列就無法提供服務了，因此很多場景下，我們希望消息隊列有高可用性支持，例如

RabbitMQ的鏡像集群模式的高可用性方案，ActiveMQ也有基于LevelDB+ZooKeeper的高可用性方案，以及Kafka的Replication機制等。

12.消息隊列的選型和應用場景

具體請參考：高并發架構系列：分布式之消息隊列的特點、選型、及應用場景詳解

你可能也喜歡:

消息中間件系列(二)：Kafka的原理、基礎架構、以及使用場景

消息中間件系列（八）：Kafka、RocketMQ、RabbitMQ等的優劣勢比較

消息中間件系列(九)：詳解RocketMQ的架構設計、關鍵特性、與應用場景

消息中間件系列（三）：主流的消息隊列中間件有哪些？

消息中間件系列(七)：如何從0到1設計一個消息隊列中間件

消息中間件系列（四）：消息隊列MQ的特點、選型、及應用場景詳解

---

總結

以上是生活随笔為你收集整理的消息中间件系列(五)：MQ消息队列的12点核心原理总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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