01

消息場景

Cloud Native

RocketMQ 5.0 是消息事件流一體的實時數(shù)據(jù)處理平臺，是業(yè)務消息領域的事實標準，很多互聯(lián)網(wǎng)公司在業(yè)務消息場景會使用 RocketMQ。

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

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

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

通過引入消息隊列實現(xiàn)應用的異步集成可以獲得四大解耦優(yōu)勢。

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

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

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

流量解耦

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

02

基礎特性

Cloud Native

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

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

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

03

增強能力

Cloud Native

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

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

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

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

其次，RocketMQ 還具備優(yōu)秀的可觀測能力，是穩(wěn)定性的重要輔助手段。

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

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

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

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



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

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

主動消費模式

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

04

總結

Cloud Native

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

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

業(yè)務消息場景的增強能力：穩(wěn)定性、可觀測、多樣化接口。