rocketmq 學習二基本概念

教程：
基本概念 | RocketMQ

視頻教程

https://www.bilibili.com/video/BV1d5411y7UW?vd_source=f1bd3b5218c30adf0a002c8c937e0a27

版本：5.0

一基本概念

1.1 生產者/Producer??????

1.1.1? 定義

????????消息發布者。是構建并傳輸消息到服務端的運行實體。

????????生產者通常被集成在業務系統中，將業務消息按照要求封裝成消息(Message)并發送至服務端

????????傳輸行為:

發送方式：生產者可通過API接口設置消息發送的方式。Apache RocketMQ 支持同步傳輸和異步傳輸。
批量發送：生產者可通過API接口設置消息批量傳輸的方式。例如，批量發送的消息條數或消息大小。
事務行為：Apache RocketMQ 支持事務消息，對于事務消息需要生產者配合進行事務檢查等行為保障事務的最終一致性。詳見事務消息（Transaction）。

????????生產者和主題的關系為多對多關系，即同一個生產者可以向多個主題發送消息，對于平臺類場景如果需要發送消息到多個主題，并不需要創建多個生產者；同一個主題也可以接收多個生產者的消息，以此可以實現生產者性能的水平擴展和容災。

1.1.2 模型關系

消息由生產者（Producer）初始化并發送到Apache RocketMQ 服務端。
消息按照到達Apache RocketMQ 服務端的順序存儲到主題(Topic)的指定隊列(MessageQueue)中。
消費者(Consumer)按照指定的訂閱關系從Apache RocketMQ 服務端中獲取消息并消費。

1.1.3 內部屬性

客戶端ID

定義：生產者客戶端的標識，用于區分不同的生產者。集群內全局唯一。
取值：客戶端ID由Apache RocketMQ 的SDK自動生成，主要用于日志查看、問題定位等運維場景，不支持修改。

通信參數

接入點信息 （必選） ：連接服務端的接入地址，用于識別服務端集群。接入點必須按格式配置，建議使用域名，避免使用IP地址，防止節點變更無法進行熱點遷移。
身份認證信息 （可選） ：客戶端用于身份驗證的憑證信息。僅在服務端開啟身份識別和認證時需要傳輸。
請求超時時間 （可選） ：客戶端網絡請求調用的超時時間。取值范圍和默認值，參考系統說明規范系統設置。

預綁定主題列表

事務檢查器

發送重試策略

1.1.4 使用建議

不建議單一進程創建大量生產者

生產者（Producer）和主題（Topic）是多對多的關系，支持同一個生產者向多個主題(Topic)發送消息（Message）。對于生產者（Producer）的創建和初始化，建議遵循夠用即可、最大化復用原則，如果有需要發送消息（Message）到多個主題（Topic）的場景，無需為每個主題（Topic）都創建一個生產者（Producer）。

不建議頻繁創建和銷毀生產者

生產者（Producer）是可以重復利用的底層資源，類似數據庫的連接池。因此不需要在每次發送消息（Message）時動態創建生產者（Producer），且在發送結束后銷毀生產者。這樣頻繁的創建銷毀會在服務端產生大量短連接請求，嚴重影響系統性能。

1.2 主題/Topic

1.2.1 定義

????????Topic是消息傳輸和存儲的頂層容器，用于標識同一類業務邏輯的信息。

??????? 為邏輯概念，非實體的消息容器。

定義數據的分類隔離： 在 Apache RocketMQ 的方案設計中，建議將不同業務類型的數據拆分到不同的主題中管理，通過主題實現存儲的隔離性和訂閱隔離性。
定義數據的身份和權限： Apache RocketMQ 的消息本身是匿名無身份的，同一分類的消息使用相同的主題來做身份識別和權限管理。

1.2.2 模型關系

????????主題是 Apache RocketMQ 的頂層存儲，所有消息資源的定義都在主題內部完成，但主題是一個邏輯概念，并不是實際的消息容器。

????????主題內部由多個隊列組成，消息的存儲和水平擴展能力最終是由隊列實現的；并且針對主題的所有約束和屬性設置，最終也是通過主題內部的隊列來實現。?

1.2.3 內部屬性

主題名稱

定義：主題的名稱，用于標識主題，主題名稱集群內全局唯一。

取值：由用戶創建主題時定義。

約束：參考系統說明規范系統設置。

隊列列表

定義：隊列（MessageQueue）作為主題的組成單元，是消息存儲的實際容器，一個主題內包含一個或多個隊列，消息實際存儲在主題的各隊列內。

取值：系統根據隊列數量給主題分配隊列，隊列數量創建主題時定義。

約束：一個主題內至少包含一個隊列。

消息類型

定義：主題所支持的消息類型

取值：創建主題時選擇消息類型。包括Normal（普通消息）、FIFO（順序消息）、Delay（定時/延時消息）、Transaction（事務消息）。

約束：Apache RocketMQ 從5.0版本開始，支持強制校驗消息類型，即每個主題只允許發送一種消息類型的消息，這樣可以更好的運維和管理生產系統，避免混亂。為保證向下兼容4.x版本行為，強制校驗功能默認開啟。

1.2.4 行為約束

消息類型強制校驗

????????Apache RocketMQ 5.x版本支持將消息類型拆分到主題中進行獨立運維和處理，因此系統會對發送的消息類型和主題定的消息類型進行強制校驗，若校驗不通過，則消息發送請求會被拒絕，并返回類型不匹配異常。校驗原則如下：

消息類型必須一致：發送的消息的類型，必須和目標主題定義的消息類型一致。
主題類型必須單一：每個主題只支持一種消息類型，不允許將多種類型的消息發送到同一個主題中。
為保證向下兼容4.x版本行為，上述強制校驗功能默認開啟。

常見錯誤使用場景

發送的消息類型不匹配例如，創建主題時消息類型定義為順序消息，發送消息時發送事務消息到該主題中，此時消息發送請求會被拒絕，并返回類型不匹配異常。
單一消息主題混用例如，創建主題時消息類型定義為普通消息，發送消息時同時發送普通消息和順序消息到該主題中，則順序消息的發送請求會被拒絕，并返回類型不匹配異常。

1.2.5 使用建議

按照業務分類合理拆分主題

主題拆分設計應遵循大類統一原則，即將相同業務域內同一功能屬性的消息劃分為同一主題。

消息類型是否一致：不同類型的消息，如順序消息和普通消息需要使用不同的主題。
消息業務是否關聯：如果業務沒有直接關聯。比如，淘寶交易消息和盒馬物流消息沒有業務交集，需要使用不同的消息主題；同樣是淘寶交易消息，女裝類訂單和男裝類訂單可以使用同一個訂單。當然，如果業務量較大或其他子模塊應用處理業務時需要進一步拆分訂單類型，您也可以將男裝訂單和女裝訂單的消息拆分到兩個主題中。
消息量級是否一樣：數量級不同或時效性不同的業務消息建議使用不同的主題。例如某些業務消息量很小但是時效性要求很強。如果跟某些萬億級消息量的業務使用同一個主題，會增加消息的等待時長。

正確拆分示例： 線上商品購買場景下：
訂單交易如訂單創建、支付、取消等流程消息使用一個主題。
物流相關消息使用一個主題。
積分管理相關消息使用一個主題。錯誤拆分示例：拆分粒度過粗：會導致業務隔離性差，不利于獨立運維和故障處理。例如，所有交易消息和物流消息都共用一個主題。拆分粒度過細：會消耗大量主題資源，造成系統負載過重。例如，按照用戶ID區分，每個用戶ID使用一個主題。

單一主題只收發一種類型消息，避免混用

????????主題的設計原則為通過主題隔離業務，不同業務邏輯的消息建議使用不同的主題。同一業務邏輯消息的類型都相同，因此，對于指定主題，應該只收發同一種類型的消息。

主題管理盡量避免自動化機制

????????主題屬于頂層資源和容器，擁有獨立的權限管理、可觀測性指標采集和監控等能力，創建和管理主題會占用一定的系統資源。因此，生產環境需要嚴格管理主題資源，請勿隨意進行增、刪、改、查操作。

????????雖然提供了自動創建主題的功能，但是建議僅在測試環境使用，生產環境請勿打開，避免產生大量垃圾主題，無法管理和回收并浪費系統資源。

1.3 消息/Message

1.3.1 定義

????????消息是 Apache RocketMQ 中的最小數據傳輸單元。生產者（Producer）將業務數據的負載和拓展屬性包裝成消息（Message）發送到服務端，服務端按照相關語義將消息投遞到消費端進行消費。

消息不可變性

消息（Message）本質上是已經產生并確定的事件，一旦產生后，消息的內容不會發生改變。即使經過傳輸鏈路的控制也不會發生變化，消費端獲取的消息都是只讀消息視圖。

消息持久化

默認對消息進行持久化，即將接收到的消息（Message）存儲到 Apache RocketMQ 服務端的存儲文件中，保證消息的可回溯性和系統故障場景下的可恢復性。

1.3.2 模型關系

消息所處的流程和位置如下：

消息（Message）由生產者(Prpducer)初始化并發送到Apache RocketMQ 服務端。
消息（Message）按照到達Apache RocketMQ 服務端的順序存儲到隊列（MessageQueue）中。
消費者（Consumer）按照指定的訂閱關系從Apache RocketMQ 服務端中獲取消息（Message）并消費。

1.3.3 消息內部屬性

系統保留屬性

主題名稱

定義：當前消息所屬的主題（Topic）的名稱。集群內全局唯一。
取值：從客戶端SDK接口獲取。

消息類型

定義：當前消息的類型。
取值：從客戶端SDK接口獲取。參考1.2.3 消息類型

消息隊列

定義：實際存儲當前消息的隊列。詳見1.4。
取值：由服務端指定并填充。

消息位點

定義：當前消息存儲在隊列中的位置。詳見消息進度管理。
取值：由服務端指定并填充。取值范圍：0~long.Max。

消息ID

定義：消息的唯一標識，集群內每條消息的ID全局唯一。
取值：生產者客戶端系統自動生成。固定為數字和大寫字母組成的32位字符串。

索引Key列表（可選）

定義：消息的索引鍵，可通過設置不同的Key區分消息和快速查找消息。
取值：由生產者客戶端定義。

過濾標簽Tag（可選）

定義：消息的過濾標簽。消費者可通過Tag對消息進行過濾，僅接收指定標簽的消息。
取值：由生產者客戶端定義。
約束：一條消息僅支持設置一個標簽。

定時時間（可選）

定義：定時場景下，消息觸發延時投遞的毫秒級時間戳。更多信息，詳見? 消息模型定時/延時消息。
取值：由消息生產者定義。
約束：最大可設置定時時長為40天。

消息發送時間

定義：消息發送時，生產者客戶端系統的本地毫秒級時間戳。
取值：由生產者客戶端系統填充。
說明：客戶端系統時鐘和服務端系統時鐘可能存在偏差，消息發送時間是以客戶端系統時鐘為準。

消息保存時間戳

定義：消息在Apache RocketMQ 服務端完成存儲時，服務端系統的本地毫秒級時間戳。對于定時消息和事務消息，消息保存時間指的是消息生效對消費方可見的服務端系統時間。

取值：由服務端系統填充。
說明：客戶端系統時鐘和服務端系統時鐘可能存在偏差，消息保留時間是以服務端系統時鐘為準。

消費重試次數

定義：消息消費失敗后，Apache RocketMQ 服務端重新投遞的次數。每次重試后，重試次數加1。更多信息，、詳見1.11。
取值：由服務端系統標記。首次消費，重試次數為0；消費失敗首次重試時，重試次數為1。

業務自定義屬性

定義：生產者可以自定義設置的擴展信息。
取值：由消息生產者自定義，按照字符串鍵值對設置。

消息負載

定義：業務消息的實際報文數據。
取值：由生產者負責序列化編碼，按照二進制字節傳輸。
約束：詳見三系統說明規范系統設置。

1.3.4 行為約束

????????消息大小不得超過其類型所對應的限制，否則消息會發送失敗。

系統默認的消息最大限制如下：

普通和順序消息：4 MB
事務和定時或延時消息：64 KB

1.3.4 使用建議

單條消息不建議傳輸超大負載

????????作為一款消息中間件產品，Apache RocketMQ 一般傳輸的是都是業務事件數據。單個原子消息事件的數據大小需要嚴格控制，如果單條消息過大容易造成網絡傳輸層壓力，不利于異常重試和流量控制。

????????生產環境中如果需要傳輸超大負載，建議按照固定大小做報文拆分，或者結合文件存儲等方法進行傳輸。

消息中轉時做好不可變設計

????????Apache RocketMQ 服務端5.x版本中，消息本身不可編輯，消費端獲取的消息都是只讀消息視圖。但在歷史版本3.x和4.x版本中消息不可變性沒有強約束，因此如果您需要在使用過程中對消息進行中轉操作，務必將消息重新初始化。

1.4 消息隊列/MessageQueue ??

????????消息存儲和傳輸的實際容器，也是消息的最小存儲單元。

1.4.1 定義

????????隊列（MessageQueue）是 Apache RocketMQ 中消息存儲和傳輸的實際容器，也是 Apache RocketMQ 消息的最小存儲單元。 Apache RocketMQ 的所有主題（Topic）都是由多個隊列（MessageQueue）組成，以此實現隊列數量的水平拆分和隊列內部的流式存儲。

隊列的主要作用如下：

存儲順序性

隊列天然具備順序性，即消息按照進入隊列的順序寫入存儲，同一隊列間的消息天然存在順序關系，隊列頭部為最早寫入的消息，隊列尾部為最新寫入的消息。消息在隊列中的位置和消息之間的順序通過位點（Offset）進行標記管理。
流式操作語義

Apache RocketMQ 基于隊列的存儲模型可確保消息從任意位點讀取任意數量的消息，以此實現類似聚合讀取、回溯讀取等特性，這些特性是RabbitMQ、ActiveMQ等非隊列存儲模型不具備的。

1.4.2 模型關系

????????Apache RocketMQ 默認提供消息可靠存儲機制，所有發送成功的消息都被持久化存儲到隊列中，配合生產者和消費者客戶端的調用可實現至少投遞一次的可靠性語義。

????????Apache RocketMQ 隊列模型和Kafka的分區（Partition）模型類似。在 Apache RocketMQ 消息收發模型中，隊列屬于主題的一部分，雖然所有的消息資源以主題粒度管理，但實際的操作實現是面向隊列。

????????例如，生產者指定某個主題，向主題內發送消息，但實際消息發送到該主題下的某個隊列中。

????????Apache RocketMQ 中通過修改隊列數量，以此實現橫向的水平擴容和縮容。

1.4.3 內部屬性

讀寫權限

定義：當前隊列是否可以讀寫數據。
取值：由服務端定義，枚舉值如下
- 6：讀寫狀態，當前隊列允許讀取消息和寫入消息。
- 4：只讀狀態，當前隊列只允許讀取消息，不允許寫入消息。
- 2：只寫狀態，當前隊列只允許寫入消息，不允許讀取消息。
- 0：不可讀寫狀態，當前隊列不允許讀取消息和寫入消息。

約束：隊列的讀寫權限屬于運維側操作，不建議頻繁修改。

1.4.4 行為約束

????????每個主題（Topic）下會由一到多個隊列（MessageQueue）來存儲消息，每個主題對應的隊列數與消息類型以及實例所處地域（Region）相關。

1.4.5 使用建議

按照實際業務消耗設置隊列數

????????Apache RocketMQ 的隊列數可在創建主題或變更主題時設置修改，隊列數量的設置應遵循少用夠用原則，避免隨意增加隊列數量。

主題內隊列數過多可能對導致如下問題：

集群元數據膨脹

Apache RocketMQ 會以隊列粒度采集指標和監控數據，隊列過多容易造成管控元數據膨脹。
客戶端壓力過大

Apache RocketMQ 的消息讀寫都是針對隊列進行操作，隊列過多對應更多的輪詢請求，增加系統負荷。

常見隊列增加場景

需要增加隊列實現物理節點負載均衡

Apache RocketMQ 每個主題的多個隊列可以分布在不同的服務節點上，在集群水平擴容增加節點后，為了保證集群流量的負載均衡，建議在新的服務節點上新增隊列，或將舊的隊列遷移到新的服務節點上。
需要增加隊列實現順序消息性能擴展

在 Apache RocketMQ 服務端4.x版本中，順序消息的順序性在隊列內生效的，因此順序消息的并發度會在一定程度上受隊列數量的影響，因此建議僅在系統性能瓶頸時再增加隊列。

1.5 消費者/Consumer

??????? 消息訂閱者，是用來接受并處理消息的運行實體。

1.5.1 定義

????????消費者是 Apache RocketMQ 中用來接收并處理消息的運行實體。消費者通常被集成在業務系統中，從 Apache RocketMQ 服務端獲取消息，并將消息轉化成業務可理解的信息，供業務邏輯處理。

在消息消費端，可以定義如下傳輸行為：

消費者身份：消費者必須關聯一個指定的消費者分組，以獲取分組內統一定義的行為配置和消費狀態。
消費者類型：Apache RocketMQ 面向不同的開發場景提供了多樣的消費者類型，包括PushConsumer類型、SimpleConsumer類型、PullConsumer類型（僅推薦流處理場景使用）等。具體信息，詳見消費者分類。
消費者本地運行配置：消費者根據不同的消費者類型，控制消費者客戶端本地的運行配置。例如消費者客戶端的線程數，消費并發度等，實現不同的傳輸效果。

1.5.2 模型關系

消息由生產者初始化并發送到Apache RocketMQ 服務端。
消息按照到達Apache RocketMQ 服務端的順序存儲到主題的指定隊列中。
消費者按照指定的訂閱關系從Apache RocketMQ 服務端中獲取消息并消費。

1.5.3 內部屬性

消費者分組名稱

定義：當前消費者關聯的消費者分組名稱，消費者必須關聯到指定的消費者分組，通過消費者分組獲取消費行為。更多信息，詳見1.6。
取值：消費者分組為Apache RocketMQ 的邏輯資源，需要您提前通過控制臺或OpenAPI創建。具體命名格式，詳見三系統說明規范系統設置。

客戶端ID

定義：消費者客戶端的標識，用于區分不同的消費者。集群內全局唯一。
取值：客戶端ID由Apache RocketMQ 的SDK自動生成，主要用于日志查看、問題定位等運維場景，不支持修改。

通信參數

接入點信息 （必選） ：連接服務端的接入地址，用于識別服務端集群。接入點必須按格式配置，建議使用域名，避免使用IP地址，防止節點變更無法進行熱點遷移。
身份認證信息 （可選） ：客戶端用于身份驗證的憑證信息。僅在服務端開啟身份識別和認證時需要傳輸。
請求超時時間 （可選） ：客戶端網絡請求調用的超時時間。取值范圍和默認值，詳見三系統說明規范系統設置。

預綁定訂閱關系列表

定義：指定消費者的訂閱關系列表。 Apache RocketMQ 服務端可在消費者初始化階段，根據預綁定的訂閱關系列表對目標主題進行權限及合法性校驗，無需等到應用啟動后才能校驗。

取值：建議在消費者初始化階段明確訂閱關系即要訂閱的主題列表，若未設置，或訂閱的主題動態變更，Apache RocketMQ 會對目標主題進行動態補充校驗。

消費監聽器

定義：Apache RocketMQ 服務端將消息推送給消費者后，消費者調用消息消費邏輯的監聽器。
取值：由消費者客戶端本地配置。
約束：使用PushConsumer類型的消費者消費消息時，消費者客戶端必須設置消費監聽器。消費者類型的具體信息，詳見消費者分類。

1.5.4 行為約束

????????在 Apache RocketMQ 領域模型中，消費者的管理通過消費者分組實現，同一分組內的消費者共同分攤消息進行消費。因此，為了保證分組內消息的正常負載和消費，

????????Apache RocketMQ 要求同一分組下的所有消費者以下消費行為保持一致：

投遞順序
消費重試策略

1.5.5 使用建議

不建議在單一進程內創建大量消費者

????????Apache RocketMQ 的消費者在通信協議層面支持非阻塞傳輸模式，網絡通信效率較高，并且支持多線程并發訪問。因此，大部分場景下，單一進程內同一個消費分組只需要初始化唯一的一個消費者即可，開發過程中應避免以相同的配置初始化多個消費者。

不建議頻繁創建和銷毀消費者

????????Apache RocketMQ 的消費者是可以重復利用的底層資源，類似數據庫的連接池。因此不需要在每次接收消息時動態創建消費者，且在消費完成后銷毀消費者。這樣頻繁地創建銷毀會在服務端產生大量短連接請求，嚴重影響系統性能。

1.6 消費者組/ConsumerGroup

1.6.1 定義

????????消費者分組是 Apache RocketMQ 系統中承載多個消費行為一致的消費者的負載均衡分組。

????????和消費者不同，消費者分組并不是運行實體，而是一個邏輯資源。在 Apache RocketMQ 中，通過消費者分組內初始化多個消費者實現消費性能的水平擴展以及高可用容災。

????????在消費者分組中，統一定義以下消費行為，同一分組下的多個消費者將按照分組內統一的消費行為和負載均衡策略消費消息。

訂閱關系：Apache RocketMQ 以消費者分組的粒度管理訂閱關系，實現訂閱關系的管理和追溯。具體信息，詳見六訂閱關系
投遞順序性：Apache RocketMQ 的服務端將消息投遞給消費者消費時，支持順序投遞和并發投遞，投遞方式在消費者分組中統一配置。具體信息，詳見四消息模式順序消息
消費重試策略：消費者消費消息失敗時的重試策略，包括重試次數、死信隊列設置等。具體信息，詳見消息重試。

1.6.2 模型關系

消息由生產者初始化并發送到Apache RocketMQ 服務端。
消息按照到達Apache RocketMQ 服務端的順序存儲到主題的指定隊列中。
消費者按照指定的訂閱關系從Apache RocketMQ 服務端中獲取消息并消費。

1.6.3 內部屬性

消費者分組名稱

定義：消費者分組的名稱，用于區分不同的消費者分組。集群內全局唯一。
取值：消費者分組由用戶設置并創建。具體命名規范，詳見三系統說明給范系統設置。

投遞順序性

定義：消費者消費消息時，Apache RocketMQ 向消費者客戶端投遞消息的順序。

根據不同的消費場景，Apache RocketMQ 提供順序投遞和并發投遞兩種方式。具體信息，詳見四消息模式順序消息。
取值：默認投遞方式為并發投遞。

消費重試策略

定義：消費者消費消息失敗時，系統的重試策略。消費者消費消息失敗時，系統會按照重試策略，將指定消息投遞給消費者重新消費。具體信息，詳見消息重試。
取值：重試策略包括：
- 最大重試次數：表示消息可以重新被投遞的最大次數，超過最大重試次數還沒被成功消費，消息將被投遞至死信隊列或丟棄。
- 重試間隔：Apache RocketMQ 服務端重新投遞消息的間隔時間。最大重試次數和重試間隔的取值范圍及默認值，詳見三系統說明給范系統設置。
約束：重試間隔僅在PushConsumer消費類型下有效。

訂閱關系

定義：當前消費者分組關聯的訂閱關系集合。包括消費者訂閱的主題，以及消息的過濾規則等。訂閱關系由消費者動態注冊到消費者分組中，Apache RocketMQ 服務端會持久化訂閱關系并匹配消息的消費進度。更多信息，詳見? 訂閱關系。

1.6.4 行為約束

????????Apache RocketMQ 要求同一分組下的所有消費者以下消費行為保持一致：

投遞順序
消費重試策略

1.6.5 使用建議

按照業務合理拆分分組

????????Apache RocketMQ 的消費者和主題是多對多的關系，對于消費者分組的拆分設計，建議遵循以下原則：

消費者的投遞順序一致：同一消費者分組下所有消費者的消費投遞順序是相同的，統一都是順序投遞或并發投遞，不同業務場景不能混用消費者分組。
消費者業務類型一致：一般消費者分組和主題對應，不同業務域對消息消費的要求不同，例如消息過濾屬性、消費重試策略不同。因此，不同業務域主題的消費建議使用不同的消費者分組，避免一個消費者分組消費超過10個主題。

消費者分組管理盡量避免自動化機制

????????在 Apache RocketMQ 架構中，消費分組屬于狀態管理類的邏輯資源，每個消費分組都會涉及關聯的消費狀態、堆積信息、可觀測指標和監控采集數據。因此，生產環境需要嚴格管理消費者分組資源，請勿隨意進行增、刪、改、查操作。

Apache RocketMQ 雖然提供了自動創建消費者分組的功能，但是建議僅在測試環境使用，生產環境請勿打開，避免產生大量消費者分組，無法管理和回收，且浪費系統資源。

1.7 訂閱關系

1.7.1 定義

????????訂閱關系是 Apache RocketMQ 系統中消費者獲取消息、處理消息的規則和狀態配置。

????????訂閱關系由消費者分組動態注冊到服務端系統，并在后續的消息傳輸中按照訂閱關系定義的過濾規則進行消息匹配和消費進度維護。

通過配置訂閱關系，可控制如下傳輸行為：

消息過濾規則：用于控制消費者在消費消息時，選擇主題內的哪些消息進行消費，設置消費過濾規則可以高效地過濾消費者需要的消息集合，靈活根據不同的業務場景設置不同的消息接收范圍。具體信息，請參見消息過濾。
消費狀態：Apache RocketMQ 服務端默認提供訂閱關系持久化的能力，即消費者分組在服務端注冊訂閱關系后，當消費者離線并再次上線后，可以獲取離線前的消費進度并繼續消費。

1.7.2 訂閱關系判斷原則

????????Apache RocketMQ 的訂閱關系按照消費者分組和主題粒度設計，因此，一個訂閱關系指的是指定某個消費者分組對于某個主題的訂閱，判斷原則如下：

????????不同消費者分組對于同一個主題的訂閱相互獨立如下圖所示，消費者分組Group A和消費者分組Group B分別以不同的訂閱關系訂閱了同一個主題Topic A，這兩個訂閱關系互相獨立，可以各自定義，不受影響。????????

????????同一個消費者分組對于不同主題的訂閱也相互獨立如下圖所示，消費者分組Group A訂閱了兩個主題Topic A和Topic B，對于Group A中的消費者來說，訂閱的Topic A為一個訂閱關系，訂閱的Topic B為另外一個訂閱關系，且這兩個訂閱關系互相獨立，可以各自定義，不受影響。

1.7.3 模型關系

消息由生產者初始化并發送到Apache RocketMQ 服務端。
消息按照到達Apache RocketMQ 服務端的順序存儲到主題的指定隊列中。
消費者按照指定的訂閱關系從Apache RocketMQ 服務端中獲取消息并消費。

1.7.4 內部屬性

過濾類型

定義：消息過濾規則的類型。訂閱關系中設置消息過濾規則后，系統將按照過濾規則匹配主題中的消息，只將符合條件的消息投遞給消費者消費，實現消息的再次分類。
取值：
- TAG過濾：按照Tag字符串進行全文過濾匹配。
- SQL92過濾：按照SQL語法對消息屬性進行過濾匹配。

過濾表達式

定義：自定義的過濾規則表達式。
取值：具體取值規范，請參見過濾表達式語法規范。

1.7.5 行為約束

訂閱關系一致

Apache RocketMQ 是按照消費者分組粒度管理訂閱關系，因此，同一消費者分組內的消費者在消費邏輯上必須保持一致，否則會出現消費沖突，導致部分消息消費異常。

1.7.6 使用建議

建議不要頻繁修改訂閱關系

????????在 Apache RocketMQ 領域模型中，訂閱關系關聯了過濾規則、消費進度等元數據和相關配置，同時系統需要保證消費者分組下的所有消費者的消費行為、消費邏輯、負載策略等一致，整體運算邏輯比較復雜。因此，不建議在生產環境中通過頻繁修改訂閱關系來實現業務邏輯的變更，這樣可能會導致客戶端一直處于負載均衡調整和變更的過程，從而影響消息接收。

二系統說明規范系統設置

參數約束和建議 | RocketMQ

三消息傳輸過程

3.1 NameServer

??????? 可以理解為注冊中心，負責更新和發布Broker服務。在NameServer中的集群中，NameServer和NameServer之間沒有消息通訊，無狀態。

3.2 Broker

??????? 可以理解為消息中轉角色，負責消息的存儲和轉發，接收生產者的消息并持久化消息。

??????? 消息發送到Broker時，Broker會將消息轉發到與之關聯Topic中，以便讓更多的接收者進行處理。

?????? 啟動時向nameserver注冊信息，包括ip、端口、主題（Topic）。

?????? 生產者和消費者，都是與nameserver建立連接，再通過對應的broker信息與borker鏈接。

四調用命令

4.1 創建主題

sh mqadmin updateTopic -n <nameserver_address> -t <topic_name> -c <cluster_name> -a +message.type=<message_type>

message_type根據消息類型設置成Normal/FIFO/Delay/Transaction。如果不設置，默認為Normal類型。?