本文介紹雲訊息佇列 RocketMQ 版的基本概念，以便您更好地理解和使用雲訊息佇列 RocketMQ 版。
主題（Topic）
雲訊息佇列 RocketMQ 版中訊息傳輸和儲存的頂層容器，用於標識同一類商務邏輯的訊息。主題通過TopicName來做唯一標識和區分。更多資訊，請參見主題（Topic）。
輕量主題（LiteTopic）
當主題類型為Lite類型時，主題下可建立輕量主題（LiteTopic），由Topic和LiteTopic共同唯一確認訊息的儲存容器。每個儲存容器預設由一個隊列組成。更多資訊，請參見輕量主題模型。
訊息類型（MessageType）
雲訊息佇列 RocketMQ 版中按照訊息傳輸特性的不同而定義的分類，用於類型管理和安全校正。雲訊息佇列 RocketMQ 版支援的訊息類型有普通訊息、順序訊息、事務訊息和定時/延時訊息。
訊息佇列（MessageQueue）
隊列是雲訊息佇列 RocketMQ 版中訊息儲存和傳輸的實際容器，也是訊息的最小儲存單元。雲訊息佇列 RocketMQ 版的所有主題都是由多個隊列組成，以此實現隊列數量的水平分割和隊列內部的流式儲存。隊列通過QueueId來做唯一標識和區分。更多資訊，請參見隊列（MessageQueue）。
訊息（Message）
訊息是雲訊息佇列 RocketMQ 版中的最小數據傳輸單元。生產者將業務資料的負載和拓展屬性包裝成訊息發送到雲訊息佇列 RocketMQ 版服務端，服務端按照相關語義將訊息投遞到消費端進行消費。更多資訊，請參見訊息（Message）。
每條訊息都擁有全域唯一的訊息 ID（MessageID），不同主題（Topic）之間也不會重複。需注意，在網路波動或消費失敗重試等情境下，同一條訊息可能被多次投遞（即重複投遞）；建議業務端通過訊息索引 Key（MessageKey）實現等冪性處理（訊息去重），而非依賴 Message ID 的唯一性去重。
此外，雲訊息佇列 RocketMQ 版服務端不會對用戶端發送的訊息內容做任何修改，包括欄位大小寫、格式轉換等；訊息體（Message Body）中的資料始終保持發送時的原始狀態。
訊息視圖（MessageView）
訊息視圖是雲訊息佇列 RocketMQ 版面向開發視角提供的一種訊息唯讀介面。通過訊息視圖可以讀取訊息內部的多個屬性和負載資訊，但是不能對訊息本身做任何修改。
訊息標籤（MessageTag）
訊息標籤是雲訊息佇列 RocketMQ 版提供的細粒度訊息分類屬性，可以在主題層級之下做訊息類型的細分。消費者通過訂閱特定的標籤來實現細粒度過濾。更多資訊，請參見訊息過濾。
訊息位點（MessageQueueOffset）
訊息是按到達雲訊息佇列 RocketMQ 版服務端的先後順序儲存在指定主題的多個隊列中，每條訊息在隊列中都有一個唯一的Long類型座標，這個座標被定義為訊息位點。更多資訊，請參見消費進度管理。
消費位點（ConsumerOffset）
一條訊息被某個消費者消費完成後不會立即從隊列中刪除，雲訊息佇列 RocketMQ 版會基於每個消費者分組記錄消費過的最新一條訊息的位點，即消費位點。更多資訊，請參見消費進度管理。
訊息索引（MessageKey）
訊息索引是雲訊息佇列 RocketMQ 版提供的面向訊息的索引屬性。通過設定的訊息索引可以快速尋找到對應的訊息內容。
生產者（Producer）
生產者是雲訊息佇列 RocketMQ 版系統中用來構建並傳輸訊息到服務端的運行實體。生產者通常被整合在業務系統中，將業務訊息按照要求封裝成雲訊息佇列 RocketMQ 版的訊息並發送至服務端。更多資訊，請參見生產者（Producer）。
事務檢查器（TransactionChecker）
雲訊息佇列 RocketMQ 版中生產者用來執行本地事務檢查和異常事務恢複的監聽器。事務檢查器應該通過業務側資料的狀態來檢查和判斷事務訊息的狀態。更多資訊，請參見事務訊息。
事務狀態（TransactionResolution）
雲訊息佇列 RocketMQ 版中事務訊息發送過程中，事務提交的狀態標識，服務端通過事務狀態控制事務訊息是否應該提交和投遞。事務狀態包括事務提交、交易回復和事務未決。更多資訊，請參見事務訊息。
消費者分組（ConsumerGroup）
消費者分組是雲訊息佇列 RocketMQ 版系統中承載多個消費行為一致的消費者的負載平衡分組。和消費者不同，消費者分組並不是運行實體，而是一個邏輯資源。在雲訊息佇列 RocketMQ 版中，通過消費者分組內初始化多個消費者實現消費效能的水平擴充以及高可用容災。更多資訊，請參見消費者分組（ConsumerGroup）。
消費者（Consumer）
消費者是雲訊息佇列 RocketMQ 版中用來接收並處理訊息的運行實體。消費者通常被整合在業務系統中，從雲訊息佇列 RocketMQ 版服務端擷取訊息，並將訊息轉化成業務可理解的資訊，供商務邏輯處理。更多資訊，請參見消費者（Consumer）。
訊息的推送方式取決於消費模式：
叢集消費（Clustering）：訊息按隊列（MessageQueue）分配給不同的消費者執行個體，同一隊列內的訊息串列投遞，不同隊列的訊息可並發推送。
廣播消費（Broadcasting）：每條訊息會被推送給消費者分組內的所有消費者執行個體。
順序訊息情境下：同一隊列內嚴格保證順序投遞，前一條訊息處理完成後才會投遞下一條。
消費結果（ConsumeResult）
雲訊息佇列 RocketMQ 版中PushConsumer消費監聽器處理訊息完成後返回的處理結果，用來標識本次訊息是否正確處理。消費結果包含消費成功和消費失敗。
訂閱關係（Subscription）
訂閱關係是雲訊息佇列 RocketMQ 版系統中消費者擷取訊息、處理訊息的規則和狀態配置。訂閱關係由消費者分組動態註冊到服務端系統，並在後續的訊息傳輸中按照訂閱關係定義的過濾規則進行訊息匹配和消費進度維護。更多資訊，請參見訂閱關係（Subscription）。
訊息過濾
消費者可以通過訂閱指定訊息標籤（Tag）對訊息進行過濾，確保最終只接收被過濾後的訊息合集。過濾規則的計算和匹配在雲訊息佇列 RocketMQ 版的服務端完成。更多資訊，請參見訊息過濾。
重設消費位點
以時間軸為座標，在訊息持久化儲存的時間範圍內，重新設定消費者分組對已訂閱主題的消費進度，設定完成後消費者將接收設定時間點之後，由生產者發送到雲訊息佇列 RocketMQ 版服務端的訊息。更多資訊，請參見重設消費位點。
訊息軌跡
在一條訊息從生產者發出到消費者接收並處理過程中，由各個相關節點的時間、地點等資料匯聚而成的完整鏈路資訊。通過訊息軌跡，您能清晰定位訊息從生產者發出，經由雲訊息佇列 RocketMQ 版服務端，投遞給消費者的完整鏈路，方便定位排查問題。
訊息堆積
生產者已經將訊息發送到雲訊息佇列 RocketMQ 版的服務端，但由於消費者的消費能力有限，未能在短時間內將所有訊息正確消費掉，此時在雲訊息佇列 RocketMQ 版的服務端儲存著未被消費的訊息，該狀態即訊息堆積。
事務訊息
事務訊息是雲訊息佇列 RocketMQ 版提供的一種進階訊息類型，支援在分布式情境下保障訊息生產和本地事務的最終一致性。
定時/延時訊息
定時/延時訊息是雲訊息佇列 RocketMQ 版提供的一種進階訊息類型，訊息被發送至服務端後，在指定時間後才能被消費者消費。通過設定一定的定時時間可以實現分布式情境的延時調度觸發效果。
順序訊息
順序訊息是雲訊息佇列 RocketMQ 版提供的一種進階訊息類型，支援消費者按照發送訊息的先後順序擷取訊息，從而實現業務情境中的順序處理。
輕量訊息
輕量訊息是雲訊息佇列 RocketMQ 版提供的一種進階訊息類型，支援動態建立百萬級輕量主題，並提供自動化生命週期管理、高效能訂閱等能力。更多資訊，請參見輕量主題模型。
常見問題
Q：跨 VPC 訪問 RocketMQ 時應使用內網存取點網域名稱還是 IP 位址？
A：應使用 RocketMQ 控制台提供的 VPC 專用網路存取點網域名稱（即帶 -vpc 尾碼的網域名稱，例如 rmq-cn-ai54re6l701-vpc.cn-guangzhou.rmq.aliyuncs.com:8080）。該地址專為內網訪問設計，配合 VPC 對等串連及正確的路由和 DNS 配置即可實現跨 VPC 互連。請避免使用 IP 位址——RocketMQ 存取點 IP 可能變化，直接使用 IP 位址將導致串連不穩定甚至失敗。
Q：從 AWS SQS 遷移至阿里雲 RocketMQ 需要注意什嗎？
A：從 AWS SQS 遷移至雲訊息佇列 RocketMQ 版時，請重點關注以下事項：
SDK 適配：使用 gRPC SDK 接入，並將
Namespace設定為 RocketMQ 執行個體 ID。網路接入：建議通過私網存取點訪問，避免產生公網流量費用。
訊息大小：建議將訊息大小控制在 4 KB 以內，以降低單次業務的收發次數，從而最大化利用每月 2000 萬次的免費調用額度。
Q：下載 RocketMQ ONS 系列 .NET SDK Linux 版時報錯 AccessDenied 無 OSS 許可權怎麼辦？
A：原公開下載連結因 OSS 許可權配置問題可能已無法訪問。若遇到 AccessDenied 錯誤，請通過以下方式擷取最新 SDK 下載地址：
前往官方文檔查看最新 SDK 下載地址。
在阿里雲 SDK 中心搜尋並下載對應版本。
請勿繼續使用已失效的舊連結，建議收藏官方文檔頁面以擷取持續更新的下載入口。
Q：Remoting 協議與 gRPC 協議在同一 ConsumerGroup 下的並發處理能力有何差異？
A：在同一 ConsumerGroup 下，兩種協議的並發處理能力存在顯著差異：
gRPC 協議（5.x）：支援按 MessageGroup 將訊息分配至不同線程並發消費，可有效提升消費輸送量。該特性需使用 gRPC SDK 5.0.3 及以上版本。
Remoting 協議（4.x）：僅支援單線程順序消費，不支援按 MessageGroup 平行處理。
如需利用 MessageGroup 實現並發消費能力，請升級至 5.x 系列並使用 gRPC SDK。
Q：雙執行個體並行運行時，Topic 和 Group 資源是否隔離？訊息是否會錯發？
A：雙執行個體因執行個體 ID 不同，資源完全隔離，訊息不會錯發。只要用戶端配置中 PropertyKeyConst.NAMESRV_ADDR 正確填寫（指向對應執行個體的存取點地址），即使不同執行個體使用了相同的 Topic 名稱，兩套執行個體之間也不會相互影響。請確保每個用戶端的存取點配置與目標執行個體嚴格對應，以避免因配置錯誤導致的訊息路由異常。
Q：TCP 和 HTTP 存取點地址是否可以混用？
A：不可混用。TCP SDK 必須配置 TCP 協議的存取點地址，HTTP SDK 必須配置 HTTP 協議的存取點地址，二者不可互換。例如，ons-client-2.0.6.Final（通常用於 TCP 協議）必須使用 TCP 協議的 Region 化存取點地址，若誤配置為 HTTP 存取點地址將導致串連失敗。請在控制台的執行個體詳情頁分別擷取對應協議的存取點地址，確保 SDK 與存取點協議一致。