分佈式消息系列：詳解RocketMQ的簡介與演進、架構設計、關鍵特性與應用場景

終身學習是程序員的必備能力，一羣人在一塊兒走得更遠，一塊兒學習，共抗惰性。今天，咱們來重點了解RocketMQ的簡介與演進、架構設計、關鍵特性及應用場景等內容。

 

本文內容大綱：

1. RocketMQ的簡介與演進

2. RocketMQ的架構設計

3. RocketMQ的關鍵特性

4. RocketMQ的應用場景

 

01   RocketMQ的簡介

 

RocketMQ是一個純java、分佈式、隊列模型的開源消息中間件，前身是MetaQ，是阿里研發的一個隊列模型的消息中間件，後開源給apache基金會成爲了apache的頂級開源項目，具備高性能、高可靠、高實時、分佈式特色。

 

02  RocketMQ的演進

 

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

 

1.第一代，推模式

 

數據存儲採用關係型數據庫，典型表明包括Notify、Napoli。

 

2.第二代，拉模式

 

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

 

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

 

低延遲消息引擎RocketMQ，在二代功能特性的基礎上，爲電商金融領域添加了可靠重試、基於文件存儲的分佈式事務等特性。使用在阿里大量的應用上，典型如雙11場景，具備萬億級消息流轉。

 

03  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 就是下標。

 

04   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）消息去重

 

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

冪等性：就是用戶對於同一操做發起的一次請求或者屢次請求的結果是一致的，不會由於屢次點擊而產生了反作用，數據庫的結果都是惟一的，不可變的。

只要保持冪等性，無論來多少條重複消息，最後處理的結果都同樣，須要業務端來實現。

 

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

創建一個消息表，拿到這個消息作數據庫的insert操做。給這個消息作一個惟一主鍵（primary key）或者惟一約束，那麼就算出現重複消費的狀況，就會致使主鍵衝突，那麼就再也不處理這條消息。

 

05   RocketMQ的應用場景

 

1.削峯填谷

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

 

2.異步解耦

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

 

3.順序消息

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

 

4.分佈式事務消息

好比阿里的交易系統、支付紅包等場景須要確保數據的最終一致性，須要考慮引入 MQ 的分佈式事務。主要是將大事務拆分紅小事務，減小系統間的交互，既高效又可靠。再利用MQ 的可靠傳輸與多副本技術確保消息不丟，At-Least-Once 特性來最終確保數據的最終一致性。

 

以爲不錯請點贊支持，歡迎留言或進個人我的羣179961551領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。

 

 

 

-end-