RocketMQ消息模型

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）

 

具體看一下消息模型圖:

　　

 

 一、topic中隊列的意義？

　　1）topic中隊列是可配置的，多個隊列至關因而負載均衡，將生產者投遞到該topic中的消息分別加入各個隊列中，圖中爲2個隊列，即至關於將topic的消息承載體分爲兩段（即每條消息只會往每一個隊列裏發一次，在topic中是惟一的），這樣是爲了提供性能，多實例併發生產和消費

　　2）topic中不能保證消息有序，可是在隊列中消息有序

二、消費者組如何消費？

　　1）同一個消費者組的消費者只能同時有一個消費者獲取一個隊列的消息，其餘的消費者能夠獲取其餘隊列的消息。而且每一個消費組本身維護在隊列中讀取消息的位置

　　2）每一個消費組都消費主題中一份完整的消息，不一樣消費組之間消費進度彼此不受影響，也就是說，一條消息被 Consumer Group1 消費過，也會再給 Consumer Group2 消費。

　　3）topic中的消息被一個消費組消費完不會刪除，應該是全部的消費者組消費完後刪除

　　4）對與一個消費者組來講，在同一個隊列中的消費是串行的，可是多個隊列加在一塊兒就是並行消費，因此水平擴展能夠提升消費性能

 

三、如何保證讀取消息的有序性（一個消費組在一個主題下的多個隊列併發消費就沒法保證消息的順序性）？

　　後臺將消息發送到同一隊列中（fe:按照訂單ID或者用戶ID，用一致性哈希算法，計算出隊列ID，指定隊列ID發送，這樣能夠保證相同的訂單/用戶的消息總被髮送到同一個隊列上，就能夠確保嚴格順序了。）

四、消息發送確認是否會影響效率？

　　rocket是批量確認消息的。

 

因而可知，rocketmq的消息模型簡單來講，producer投遞消息到topic中的各個隊列，各消費者組訂閱topic,消費者組中的消費者並行消費隊列中的消息。