本文介紹雲訊息佇列 RocketMQ 版中主題（Topic）的定義、模型關係、內部屬性、行為約束、版本相容性及使用建議。
定義
主題是雲訊息佇列 RocketMQ 版中訊息傳輸和儲存的頂層容器，用於標識同一類商務邏輯的訊息。
主題的作用主要如下：
定義資料的分類隔離
在雲訊息佇列 RocketMQ 版的方案設計中，建議將不同業務類型的資料拆分到不同的主題中管理，通過主題實現儲存的隔離性和訂閱隔離性。
定義資料的身份和許可權
雲訊息佇列 RocketMQ 版的訊息本身是匿名無身份的，同一分類的訊息使用相同的主題來做身份識別和許可權管理。
模型關係
在整個雲訊息佇列 RocketMQ 版的領域模型中，主題所處的流程和位置如下：
主題是雲訊息佇列 RocketMQ 版的頂層儲存，所有訊息資源的定義都在主題內部完成，但主題是一個邏輯概念，並不是實際的訊息容器。
主題內部由一個或多個隊列組成，訊息的儲存和水平擴充能力最終是由隊列實現的；並且針對主題的所有約束和屬性設定，最終也是通過主題內部的隊列來實現。
當主題類型為Lite類型時，主題下可建立二級資源LiteTopic，每個LiteTopic預設由一個隊列組成。
概念說明
主題（Topic）
雲訊息佇列 RocketMQ 版中訊息傳輸和儲存的頂層容器，用於標識同一類商務邏輯的訊息。主題通過TopicName來做唯一標識和區分。
輕量主題（LiteTopic）
當主題類型為Lite類型時，主題下可建立輕量主題（LiteTopic），由Topic和LiteTopic共同唯一確認訊息的儲存容器，每個儲存容器預設由一個隊列組成。
內部屬性
行為約束
訊息類型強制校正
雲訊息佇列 RocketMQ 版 5.x版本將訊息類型拆分到主題中進行獨立營運和處理，因此系統會對發送的訊息類型和主題定的訊息類型進行強制校正，若校正不通過，則訊息發送請求會被拒絕，並傳回型別不匹配異常。校正原則如下：
訊息類型必須一致
發送的訊息的類型，必須和目標主題定義的訊息類型一致。
主題類型必須單一
每個主題只支援一種訊息類型，不允許將多種類型的訊息發送到同一個主題中。
常見錯誤使用情境
發送的訊息類型不匹配
例如，建立主題時訊息類型定義為順序訊息，發送訊息時發送事務訊息到該主題中，此時訊息發送請求會被拒絕，並傳回型別不匹配異常。
單一訊息主題混用
例如，建立主題時訊息類型定義為普通訊息，發送訊息時同時發送普通訊息和順序訊息到該主題中，則順序訊息的發送請求會被拒絕，並傳回型別不匹配異常。
版本相容性
訊息類型的強制校正，僅針對雲訊息佇列 RocketMQ 版服務端5.x版本生效。
雲訊息佇列 RocketMQ 版服務端4.x版本執行個體未對訊息類型強制校正，但建議使用時保證訊息類型一致
使用建議
按照業務分類合理拆分主題
雲訊息佇列 RocketMQ 版的主題拆分設計應遵循大類統一原則，即將相同業務域內同一功能屬性的訊息劃分為同一主題。拆分主題時，您可以從以下角度考慮拆分粒度：
訊息類型是否一致：不同類型的訊息，如順序訊息和普通訊息需要使用不同的主題。
訊息業務是否關聯：如果業務沒有直接關聯，比如，淘寶交易訊息和盒馬物流訊息沒有業務交集，需要使用不同的訊息主題；同樣是淘寶交易訊息，女裝類訂單和男裝類訂單可以使用同一個主題。當然，如果業務量較大或其他子模組應用處理業務時需要進一步拆分訂單類型，您也可以將男裝訂單和女裝訂單的訊息拆分到兩個主題中。
訊息量級是否一樣：數量級不同或時效性不同的業務訊息建議使用不同的主題，例如某些業務訊息量很小但是時效性要求很強，如果跟某些萬億級訊息量的業務使用同一個主題，會增加訊息的等待時間長度。
正確拆分樣本：線上商品購買情境下，訂單交易如訂單建立、支付、取消等流程訊息使用一個主題，物流相關訊息使用一個主題，積分管理相關訊息使用一個主題。
錯誤拆分樣本：
拆分粒度過粗：會導致業務隔離性差，不利於獨立營運和故障處理。例如，所有交易訊息和物流訊息都共用一個主題。
拆分粒度過細：會消耗大量佈景主題資源，造成系統負載過重。例如，按照使用者ID區分，每個使用者ID使用一個主題。
單一主題只收發一種類型訊息，避免混用
雲訊息佇列 RocketMQ 版主題的設計原則為通過主題隔離業務，不同商務邏輯的訊息建議使用不同的主題。同一商務邏輯訊息的類型都相同，因此，對於指定主題，應該只收發同一種類型的訊息。
主旨管理員盡量避免自動化機制
在雲訊息佇列 RocketMQ 版架構中，主題屬於頂層資源和容器，擁有獨立的許可權管理、可觀測性指標採集和監控等能力，建立和管理主題會佔用一定的系統資源。因此，生產環境需要嚴格管理佈景主題資源，請勿隨意進行增、刪、改、查操作。