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消息轨迹-设计篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。