01

消息場景

Cloud Native

RocketMQ 5.0 是消息事件流一體的實時數據處理平臺，是業務消息領域的事實標準，很多互聯網公司在業務消息場景會使用 RocketMQ。

我們反復提到的“消息、業務消息”，指的是分布式應用解耦，是 RocketMQ 的業務基本盤。通過本文，我們將深入了解 RocketMQ 5.0 在業務消息場景的優勢能力，了解為什么 RocketMQ 能夠成為業務消息領域的事實標準。

RocketMQ 在業務消息領域的經典場景是應用解耦，這也是 RocketMQ 誕生初期解決阿里電商分布式互聯網架構的核心場景，主要承擔分布式應用（微服務）的異步集成，達到應用解耦的效果。解耦是所有的軟件架構最重要的追求。

分布式應用（微服務）采用同步 RPC 與異步消息的對比。比如在業務系統中，有三個上游應用與 4 個下游應用，采用同步 RPC 的方式，會有 3*4 的依賴復雜度；而采用異步消息的方式則可以化繁為簡，簡化為 3+4 的依賴復雜度，從乘法簡化為加法。

通過引入消息隊列實現應用的異步集成可以獲得四大解耦優勢。

代碼解耦 極大提升業務敏捷度。如果用同步調用的方式，每次擴展業務邏輯都需要上游應用顯式調用下游應用接口，代碼直接耦合，上游應用要做變更發布，業務迭代互相掣肘。而通過使用消息隊列擴展新的業務邏輯，只需要增加下游應用訂閱某個 Topic，上下游應用互相透明，業務可以保持靈活獨立快速迭代。

延遲解耦 如果使用同步調用的方式，隨著業務邏輯的增加，用戶操作的遠程調用次數會越來越多，業務響應越來越慢，性能衰減，業務發展不可持續。而使用消息隊列，無論增加多少業務，上游應用只需調用一次消息隊列的發送接口即可響應線上用戶，延遲為常量，基本在 5ms 以內。

可用性解耦 如果使用同步調用的方式，任何下游業務不可用都會導致整個鏈路失敗。該種結構下類似于串聯電路，甚至在部分調用失敗的情況下，還會出現狀態不一致。而采用 RocketMQ 進行異步集成，只要 RocketMQ 服務可用，用戶的業務操作便可用。RocketMQ 服務通過多對主備組成的 broker 集群提供，只要有一對主備可用，則整體服務可用，作為基礎軟件，可用性遠大于普通的業務應用，下游應用的業務推進都可以通過 MQ 的可靠消息投遞來達成。

流量解耦

即削峰填谷。如果采用同步調用的方式，上下游的容量必須對齊，否則會出現級聯不可用。容量完全對齊需要投入大量精力進行全鏈路壓測與更多機器成本。而通過引入 RocketMQ，基于 RocketMQ 億級消息的堆積能力，對于實時性要求不高的下游業務，可以盡最大努力消費，既保證了系統穩定性，又降低了機器成本與研發運維成本。

02

基礎特性

Cloud Native

阿里的交易應用流程為：用戶在淘寶上下單時會調用交易應用創建訂單，交易應用將訂單落到數據庫，然后生產一條訂單創建的消息到 RocketMQ，返回給終端用戶訂單創建成功的接口。完成的交易流程推進則是依賴 RocketMQ 將訂單創建消息投遞給下游應用，會員應用收到訂單消息，需要給買家贈送積分、淘金幣，觸發用戶激勵相關的業務。購物車應用則是負責刪除在購物車里面的商品，避免用戶重復購買。同時，支付系統與物流系統也都會基于訂單狀態的變更，推進支付環節與履約環節。

過去十年多年，阿里電商業務持續蓬勃發展，交易的下游應用已達數百個，并且還在不斷增加。基于 RocketMQ 的電商架構極大提高了阿里電商業務的敏捷度，上游核心的交易系統完全無需關心哪些應用在訂閱交易消息，交易應用的延遲與可用性也一直保持在很高水準，只依賴少量的核心系統與 RocketMQ，不會受數百個下游應用的影響。

交易的下游業務類型不一，有大量的業務場景不需要實時消費交易數據，比如物流場景能容忍一定的延遲。通過 RocketMQ 的億級堆積能力，極大降低了機器成本。RocketMQ 的 shared-nothing 架構具備無限橫向擴展的能力，已經連續 10 年支撐了高速增長的雙十一消息峰值，在幾年前達到億級 TPS。

03

增強能力

Cloud Native

經典場景下，RocketMQ 相對于其他消息隊列，擁有諸多差異化優勢與增強。

首先，穩定性方面，穩定性交易是金融場景最重要的需求。RocketMQ 的穩定性不僅限于高可用架構，而是通過全方位的產品能力來構建穩定性競爭力。比如重試隊列，當下游消費者因為業務數據不 ready 或其他原因導致某條消息消費失敗，RocketMQ 不會因此阻塞消費，而是能將此消息加入到重試隊列，然后按時間衰減重試。如果某條消息因為某些因素經過十幾次重試始終無法消費成功，則 RocketMQ 會將它轉到死信隊列，用戶可以通過其他手段來處理失敗的消息，是金融行業的剛需。

同時，消費成功后如果因為代碼 bug 導致業務不符合預期，應用可以對業務 bug 進行修復并重新發布，然后應用消息回溯的功能將消息拉回到之前的時間點，讓業務按照正確邏輯重新處理。

RocketMQ 的消費實現機制采用自適應拉模式的消費，在極端的場景下能夠避免消費者被大流量打垮。同時，在消費者的 SDK 里，做了緩存本地的消息數量與消息內存占用的閾值保護，防止消費應用的內存風險。

其次，RocketMQ 還具備優秀的可觀測能力，是穩定性的重要輔助手段。

RocketMQ 是業界第一個提供消息消息級別可觀測能力的消息隊列，每條消息都可以帶上業務主鍵，比如在交易場景，用戶可以將訂單 ID 作為消息的業務主鍵。當某個訂單的業務需要排查，用戶可以基于訂單 ID 查詢該條消息的生成時間以及消息內容。消息的可觀測數據還能繼續下鉆，通過消息軌跡查看消息由哪臺生產者機器發送、由哪些消費者機器在什么時間消費、消費狀態是成功或失敗等。

除此之外，它支持了幾十種核心的度量數據，包括集群生產者流量分布、慢消費者排行、消費的平均延遲、消費堆積數量、消費成功率等。基于豐富的指標，用戶可以搭建更加完善的監控報警體系來進一步加固穩定性。

為了支撐更靈活的應用架構，RocketMQ 在生產與消費等關鍵接口提供了多種模式。

生產者接口：RocketMQ 同時提供了同步發送接口與異步發送接口。同步發送是最常用的模式，業務流程的編排是串行的，在應用發完消息、Broker 完成存儲后返回成功后，應用再執行下一步邏輯。然而在某些場景下，完成業務涉及多個遠程調用，應用為了進一步降低延遲、提高性能，會采用全異步化的方式，并發發出遠程調用（可以是多次發消息或 RPC 的組合），異步收集結果推，進業務邏輯。



在消費者的接口方面也提供了兩種方式：

監聽器模式被動消費 這是目前使用最廣泛的方式，用戶無需關心客戶端何時去 Broker 拉取消息，何時向 Broker 發出消費成功的確認，也無需維護消費線程池、本地消息緩存等細節。只需要寫一段消息監聽器的業務邏輯，根據業務執行結果返回 Success 或 Failure。它屬于全托管的模式，用戶可以專注于業務邏輯的編寫，而將實現細節完全委托給 RocketMQ 客戶端。

主動消費模式

將更多的自主權交給用戶，也稱為 Simple Consumer。在該種模式下，用戶可以自己決定何時去 Broker 讀取消息、何時發起消費確認消息。對業務邏輯的執行線程也有自主可控性，讀取完消息后，可以將消費邏輯放在自定義的線程池執行。在某些場景下，不同消息的處理時長與優先級會有所不同，采用 Simple Consumer 的模式，用戶可根據消息的屬性、大小做二次分發，隔離到不同的業務線程池執行處理。該模式還提供了消息粒度消費超時時間的設定能力，針對某些消費耗時長的消息，用戶能夠調用 change Invisible Duration 接口，延長消費時間，避免超時重試。

04

總結

Cloud Native

消息經典場景：應用解耦；

RocketMQ 基礎特性：發布訂閱、可靠消息、億級堆積、無限擴展；

業務消息場景的增強能力：穩定性、可觀測、多樣化接口。