rocketmq采用的是發布-訂閱的模式，不需要每個消費者維護自己的消息隊列，生產者將消息發送到topic,消費者訂閱此topic 讀取消息。
基本概念：
消息模型：消息模型包括producer,consumer,broker三部分。producer生產消息，consumer消費消息，broker存儲消息，broker可以是集群部署，其中topic位於broker中
Producer: 一般是業務系統為生產者，將消息投遞到broker，投遞消息要經歷“請求-確認”機制，確保消息不會在投遞過程中丟失。過程：生產者生產消息到broker,broker接受消息寫入topic.
之后給生產者發送確認相應，如果生產者沒有收到服務端的確認或者收到失敗的響應，則會重新發送消息；在消費端，消費者在收到消息並完成自己的消費業務邏輯（比如，將數據保存到數據庫中）后，也會給服務端發送消費成功的確認，服務端只有收到消費確認后，才認為一條消息被成功消費，否則它會給消費者重新發送這條消息，直到收到對應的消費成功確認。
Topic:表示一類消息的集合，每個主題包含若干條消息，每條消息只能屬於一個主題，是RocketMQ進行消息訂閱的基本單位。
生產者組：同一類Producer的集合，這類Producer發送同一類消息且發送邏輯一致。如果發送的是事物消息且原始生產者在發送之后崩潰，則Broker服務器會聯系同一生產者組的其他生產者實例以提交或回溯消費。
消費者組：同一類Consumer的集合，這類Consumer通常消費同一類消息且消費邏輯一致。消費者組使得在消息消費方面，實現負載均衡和容錯的目標變得非常容易。要注意的是，消費者組的消費者實例必須訂閱完全相同的Topic。RocketMQ 支持兩種消息模式：集群消費（Clustering）和廣播消費（Broadcasting）
具體看一下消息模型圖:
1、topic中隊列的意義？
1）topic中隊列是可配置的，多個隊列相當於是負載均衡，將生產者投遞到該topic中的消息分別加入各個隊列中，圖中為2個隊列，即相當於將topic的消息承載體分為兩段（即每條消息只會往每個隊列里發一次，在topic中是唯一的），這樣是為了提供性能，多實例並發生產和消費
2）topic中不能保證消息有序，但是在隊列中消息有序
2、消費者組如何消費？
1）同一個消費者組的消費者只能同時有一個消費者獲取一個隊列的消息，其他的消費者可以獲取其他隊列的消息。並且每個消費組自己維護在隊列中讀取消息的位置
2）每個消費組都消費主題中一份完整的消息，不同消費組之間消費進度彼此不受影響，也就是說，一條消息被 Consumer Group1 消費過，也會再給 Consumer Group2 消費。
3）topic中的消息被一個消費組消費完不會刪除，應該是所有的消費者組消費完后刪除
4）對與一個消費者組來說，在同一個隊列中的消費是串行的，但是多個隊列加在一起就是並行消費，所以水平擴展可以提高消費性能
3、如何保證讀取消息的有序性（一個消費組在一個主題下的多個隊列並發消費就無法保證消息的順序性）？
后台將消息發送到同一隊列中（fe:按照訂單ID或者用戶ID，用一致性哈希算法，計算出隊列ID，指定隊列ID發送，這樣可以保證相同的訂單/用戶的消息總被發送到同一個隊列上，就可以確保嚴格順序了。）
4、消息發送確認是否會影響效率？
rocket是批量確認消息的。
由此可見，rocketmq的消息模型簡單來說，producer投遞消息到topic中的各個隊列，各消費者組訂閱topic,消費者組中的消費者並行消費隊列中的消息。