RocketMQ訊息中介軟體詳解(萬字圖文總結)

來源：mikechen的網際網路架構

訊息中介軟體在網際網路大廠的業務場景佔據了非常重要的位置，其國內典型RocketMQ需要重點掌握，下面我就全面來詳解RocketMQ 

RocketMQ

RocketMQ一個純java、分散式、佇列模型的開源訊息中介軟體，前身是MetaQ，是阿里研發的一個佇列模型的訊息中介軟體，後開源給apache基金會成為了apache的頂級開源專案，具有高效能、高可靠、高實時、分散式特點。

RocketMQ的演進

RocketMQ一共前後經歷了三代演進：

1.第一代，推模式

資料儲存採用關係型資料庫，典型代表包括Notify、Napoli。

2.第二代，拉模式

自研的專有訊息儲存，在日誌處理方面參考Kafka，典型代表MetaQ。

3.第三代，以拉模式為主，兼有推模式

低延遲訊息引擎RocketMQ，在二代功能特性的基礎上，為電商金融領域新增了可靠重試、基於檔案儲存的分散式事務等特性。使用在了阿里大量的應用上，典型如雙11場景，具有萬億級訊息流轉。

 

RocketMQ架構設計

1.RocketMQ的核心元件

RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分構成。

1）NameServer：主要負責對於源資料的管理，包括了對於Topic和路由資訊的管理。

NameServer是一個功能齊全的伺服器，其角色類似Dubbo中的Zookeeper，但NameServer與Zookeeper相比更輕量。主要是因為每個NameServer節點互相之間是獨立的，沒有任何資訊互動。

備註：下面的訊息型別有Topic的介紹。

2） Producer

訊息生產者，負責產生訊息，一般由業務系統負責產生訊息。

•  Producer由使用者進行分散式部署，訊息由Producer透過多種負載均衡模式傳送到Broker叢集，傳送低延時，支援快速失敗。

3 ）Broker

訊息中轉角色，負責儲存訊息，轉發訊息。

•  Broker是具體提供業務的伺服器，單個Broker節點與所有的NameServer節點保持長連線及心跳，並會定時將Topic資訊註冊到NameServer，順帶一提底層的通訊和連線都是基於Netty實現的。

•  Broker負責訊息儲存，以Topic為緯度支援輕量級的佇列，單機可以支撐上萬佇列規模，支援訊息推拉模型。

•  官網上有資料顯示：具有上億級訊息堆積能力，同時可嚴格保證訊息的有序性。

4）Consumer

訊息消費者，負責消費訊息，一般是後臺系統負責非同步消費。

•  Consumer也由使用者部署，支援PUSH和PULL兩種消費模式，支援叢集消費和廣播訊息，提供實時的訊息訂閱機制。

5）大致流程

Broker在啟動的時候會去向NameServer註冊並且定時傳送心跳，Producer在啟動的時候會到NameServer上去拉取Topic所屬的Broker具體地址，然後向具體的Broker傳送訊息。具體如下圖：

2.RocketMQ的訊息領域模型

主要分為Message、Topic、Queue、Offset以及Group這幾部分。

1）Topic

Topic表示訊息的第一級型別，比如一個電商系統的訊息可以分為：交易訊息、物流訊息等。一條訊息必須有一個Topic。

最細粒度的訂閱單位，一個Group可以訂閱多個Topic的訊息。

2）Tag

Tag表示訊息的第二級型別，比如交易訊息又可以分為：交易建立訊息，交易完成訊息等。RocketMQ提供2級訊息分類，方便靈活控制。

3)Group

組，一個組可以訂閱多個Topic。

4）Message Queue

訊息的物理管理單位。一個Topic下可以有多個Queue，Queue的引入使得訊息的儲存可以分散式叢集化，具有了水平擴充套件能力。

在
RocketMQ 中，所有訊息佇列都是持久化，長度無限的資料結構，所謂長度無限是指佇列中的每個儲存單元都是定長，訪問其中的儲存單元使用
Offset 來訪問，offset 為 java long 型別，64 位，理論上在 100年內不會溢位，所以認為是長度無限。

也可以認為 Message Queue 是一個長度無限的陣列，Offset 就是下標。

 

RocketMQ的關鍵特性

1.訊息的順序

訊息的順序指的是訊息消費時，能按照傳送的順序來消費。例如：一個訂單產生了 3 條訊息，分別是訂單建立、訂單付款、訂單完成。消費時，要按照這個順序消費才有意義。但同時訂單之間又是可以並行消費的。

RocketMQ是透過將“相同ID的訊息傳送到同一個佇列，而一個佇列的訊息只由一個消費者處理“來實現順序訊息。如下圖：

這樣對於同一個訂單的建立、付款和完成訊息，確保按照這一順序被髮送和消費。

2.訊息重複

1）訊息重複的原因

訊息領域有一個對訊息投遞的QoS定義，分為：

•  最多一次（At most once）

•  至少一次（At least once）

•  僅一次（ Exactly once）

QoS：Quality of Service，服務質量

幾乎所有的MQ產品都聲稱自己做到了At
least
once。既然是至少一次，那避免不了訊息重複，尤其是在分散式網路環境下。比如：網路原因閃斷，ACK返回失敗等等故障，確認資訊沒有傳送到訊息佇列，導致訊息佇列不知道自己已經消費過該訊息了，再次將該訊息分發給其他的消費者。

不同的訊息佇列傳送的確認資訊形式不同,例如RabbitMQ是傳送一個ACK確認訊息，RocketMQ是返回一個CONSUME_SUCCESS成功標誌，kafka實際上有個offset的概念。

RocketMQ沒有內建訊息去重的解決方案，最新版本是否支援還需確認。

2）訊息去重

1）去重原則：使用業務端邏輯保持冪等性

冪等性：就是使用者對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點選而產生了副作用，資料庫的結果都是唯一的，不可變的。

只要保持冪等性，不管來多少條重複訊息，最後處理的結果都一樣，需要業務端來實現。

2）去重策略：保證每條訊息都有唯一編號(比如唯一流水號)，且保證訊息處理成功與去重表的日誌同時出現。

建立一個訊息表，拿到這個訊息做資料庫的insert操作。給這個訊息做一個唯一主鍵（primary key）或者唯一約束，那麼就算出現重複消費的情況，就會導致主鍵衝突，那麼就不再處理這條訊息。

 

RocketMQ應用場景

1.削峰填谷

比如如秒殺等大型活動時會帶來較高的流量脈衝，如果沒做相應的保護，將導致系統超負荷甚至崩潰。如果因限制太過導致請求大量失敗而影響使用者體驗，可以利用MQ 超高效能的訊息處理能力來解決。

2.非同步解耦

透過上、下游業務系統的松耦合設計，比如：交易系統的下游子系統（如積分等）出現不可用甚至當機，都不會影響到核心交易系統的正常運轉。

3.順序訊息

與FIFO原理類似，MQ提供的順序訊息即保證訊息的先進先出，可以應用於交易系統中的訂單建立、支付、退款等流程。

4.分散式事務訊息

比如阿里的交易系統、支付紅包等場景需要確保資料的最終一致性，需要引入 MQ 的分散式事務，既實現了系統之間的解耦，又可以保證最終的資料一致性。

將大事務拆分成小事務，減少系統間的互動，既高效又可靠。再利用MQ 的可靠傳輸與多副本技術確保訊息不丟，At-Least-Once 特性來最終確保資料的最終一致性。