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

無論是 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.訊息佇列的選型和應用場景

具體請參考：高併發架構系列：詳解分散式之訊息佇列的特點、選型、及應用場景