消息中間件在高并發的業務場景占據了非常重要的位置，其中國內的典型代表Java實現的RocketMQ需要重點掌握。

本文重點詳解如下5點：

1.RocketMQ的介紹

2.RocketMQ的技術演進

3.RocketMQ的架構設計

4.RocketMQ的核心特性

5.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)消息去重

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

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

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

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

建立一個消息表，拿到這個消息做數據庫的insert操作。給這個消息做一個唯一主鍵(primary key)或者唯一約束，那么就算出現重復消費的情況，就會導致主鍵沖突，那么就不再處理這條消息。

RocketMQ的應用場景

1.削峰填谷

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

2.異步解耦

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

3.順序消息

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

4.分布式事務消息

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

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