@(本節目錄)
RocketMQ消息軌跡主要包含兩篇文章：設計篇與源碼分析篇，本節將詳細介紹RocketMQ消息軌跡-設計相關。
RocketMQ消息軌跡，主要跟蹤消息發送、消息消費的軌跡，即詳細記錄消息各個處理環節的日誌，從設計上至少需要解決如下三個核心問題：
- 消費軌跡數據格式
- 記錄消息軌跡(消息日誌)
- 消息軌跡數據存儲在哪？
1、消息軌跡數據格式
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。
2、記錄消息軌跡
消息中間件的兩大核心主題：消息發送、消息消費，其核心載體就是消息，消息軌跡（消息的流轉）主要是記錄消息是何時發送到哪臺Broker，發送耗時多少時間，在什麼是被哪個消費者消費。記錄消息的軌跡主要是集中在消息發送前後、消息消費前後，可以通過RokcetMQ的Hook機制。通過如下兩個接口來定義鉤子函數。
通過實行上述兩個接口，可以實現在消息發送、消息消費前後記錄消息軌跡，爲了不明顯增加消息發送與消息消費的時延，記錄消息軌跡最好使用異步發送模式。
3、如何存儲消息軌跡數據
消息軌跡需要存儲什麼消息以及在什麼時候記錄消息軌跡的問題都以及解決，那接下來就得思考將消息軌跡存儲在哪裏？存儲在數據庫中或其他媒介中，都會加重消息中間件，使其依賴外部組件，最佳的選擇還是存儲在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 社區佈道師，公衆號：中間件興趣圈 維護者，目前已陸續發表源碼分析Java集合、Java 併發包(JUC)、Netty、Mycat、Dubbo、RocketMQ、Mybatis等源碼專欄。
