01

消息場景

Cloud Native

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

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

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

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

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

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

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

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

流量解耦

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

02

基礎(chǔ)特性

Cloud Native

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

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

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

03

增強(qiáng)能力

Cloud Native

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

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

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

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

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

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

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

為了支撐更靈活的應(yīng)用架構(gòu)，RocketMQ 在生產(chǎn)與消費等關(guān)鍵接口提供了多種模式。

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



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

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

主動消費模式

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

04

總結(jié)

Cloud Native

消息經(jīng)典場景：應(yīng)用解耦；

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

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