RocketMQ消息軌跡-設計篇

RocketMQ消息軌跡主要包含兩篇文章：設計篇與源碼分析篇，本節將詳細介紹RocketMQ消息軌跡-設計相關。

RocketMQ消息軌跡，主要跟蹤消息發送、消息消費的軌跡，即詳細記錄消息各個處理環節的日誌，從設計上至少須要解決以下三個核心問題：

• 消費軌跡數據格式
• 記錄消息軌跡(消息日誌)
• 消息軌跡數據存儲在哪？

一、消息軌跡數據格式

RocketMQ4.5版本消息軌跡主要記錄以下信息：

• traceType 跟蹤類型，可選值：Pub(消息發送)、SubBefore(消息拉取到客戶端，執行業務定義的消費邏輯以前)、SubAfter(消費後)。
• timeStamp 當前時間戳。
• regionId broker所在的區域ID，取自BrokerConfig#regionId。
• groupName 組名稱，traceType爲Pub時爲生產者組的名稱；若是traceType爲subBefore或subAfter時爲消費組名稱。
• requestId traceType爲subBefore、subAfter時使用，消費端的請求Id。
• topic 消息主題。
• msgId 消息惟一ID。
• tags 消息tag。
• keys 消息索引key，根據該key可快速檢索消息。
• storeHost 跟蹤類型爲PUB時爲存儲該消息的Broker服務器IP；跟蹤類型爲subBefore、subAfter時爲消費者IP。
• bodyLength 消息體的長度。
• costTime 耗時。
• msgType 消息的類型，可選值：Normal_Msg(普通消息),Trans_Msg_Half(預提交消息),Trans_msg_Commit(提交消息),Delay_Msg(延遲消息)。
• offsetMsgId 消息偏移量ID,該ID中包含了broker的ip以及偏移量。
• success 是發送成功。
• contextCode 消費狀態碼，可選值：SUCCESS,TIME_OUT,EXCEPTION,RETURNNULL,FAILED。

二、記錄消息軌跡

消息中間件的兩大核心主題：消息發送、消息消費，其核心載體就是消息，消息軌跡（消息的流轉）主要是記錄消息是什麼時候發送到哪臺Broker，發送耗時多少時間，在什麼是被哪一個消費者消費。記錄消息的軌跡主要是集中在消息發送先後、消息消費先後，能夠經過RokcetMQ的Hook機制。經過以下兩個接口來定義鉤子函數。

經過實行上述兩個接口，能夠實如今消息發送、消息消費先後記錄消息軌跡，爲了避免明顯增長消息發送與消息消費的時延，記錄消息軌跡最好使用異步發送模式。

三、如何存儲消息軌跡數據

消息軌跡須要存儲什麼消息以及在何時記錄消息軌跡的問題都以及解決，那接下來就得思考將消息軌跡存儲在哪裏？存儲在數據庫中或其餘媒介中，都會加劇消息中間件，使其依賴外部組件，最佳的選擇仍是存儲在Broker服務器中，將消息軌跡數據也當成一條消息存儲到Broker服務器。

既然把消息軌跡當成消息存儲在Broker服務器，那存儲消息軌跡的Topic如何肯定呢？RocketMQ提供了兩種方法來定義消息軌跡的Topic。

• 系統默認Topic 若是Broker的traceTopicEnable配置設置爲true，表示在該Broker上建立topic名爲：RMQ_SYS_TRACE_TOPIC，隊列個數爲1，默認該值爲false，表示該Broker不承載系統自定義用於存儲消息軌跡的topic。
• 自定義Topic 在建立消息生產者或消息消費者時，能夠經過參數自定義用於記錄消息軌跡的Topic名稱，不過要注意的是，rokcetmq控制檯(rocketmq-console)中只支持配置一個消息軌跡Topic，故自定義Topic，在目前這個階段或許還不是一個最佳實踐，建議使用系統默認的Topic便可。

一般爲了不消息軌跡的數據與正常的業務數據混合在一塊兒，官方建議，在Broker集羣中，新增長一臺機器，只在這臺機器上開啓消息軌跡跟蹤，這樣該集羣內的消息軌跡數據只會發送到這一臺Broker服務器上，並不會增長集羣內原先業務Broker的負載壓力。

RocketMQ消息軌跡的設計細節就介紹到這裏了，下一篇將從源碼的角度對其實現細節進行詳細的剖析；若是以爲本文對您有幫助的話，期待您的點贊，謝謝。

---

> 做者簡介：《RocketMQ技術內幕》做者，RocketMQ 社區佈道師，維護公衆號：中間件興趣圈，可掃描以下二維碼與做者進行互動。