RocketMQ基本概念及原理介紹

基本概念

ProducerGroup

通常具有同樣屬性（處理的消息種類-topic、以及消息處理邏輯流程—分布式多個客戶端）的一些producer可以歸為同一個group。在事務消息機制中，如果某條發送某條消息的producer-A宕機，使得事務消息一直處於PREPARED狀態並超時，則broker會回查 同一個group的其他producer，確認這條消息應該commit還是rollback。

ConsumerGroup

具有同樣邏輯消費同樣消息的consumer，可以歸並為一個group。同一個group內的消費者，可以共同消費（CLUSTERING）對應topic的消息，達到分布式並行處理的功能。

Topoic

消息的邏輯管理單位。

Queue

消息的物理管理單位。一個Topic下可以有多個Queue，Queue的引入使得消息存儲可以分布式集群化，具有了水平擴展的能力。

消費進度管理

RocketMQ的broker端，不負責推送消息，無論消費者是否消費消息，都將消息存儲起來。誰要消費消息，就向broker發請求獲取消息，消費記錄由consumer來維護。RocketMQ提供了兩種存儲方式來保留消費記錄：一種是保留在consumer所在的服務器上；另一種是保存在broker服務器上。用戶還可以自己實現相應的消費進度存儲接口。

默認情況下，采用集群消費（CLUSTERING），會將記錄保存在broker端；而采用廣播消費（BROADCASTING）則會將消費記錄保存在本地。

順序消息

用戶實現MessageQueueSelector為某一批消息（通常是有同樣的唯一的標示ID），選擇同一個Queue，則這一批消息的消費將是順序消費（並由同一個consumer完成消費）。

事務消息

這樣的消息有多個狀態，並且其發送是兩階段的。第一個階段發送PREPARED狀態的消息，此時consumer是看不見這種狀態的消息的，發送完畢后回調用戶的TransactionExecutor接口，執行相應的事務操作（如數據庫），當事務操作成功時，則對此條消息返回commit，讓broker對該消息執行commit操作，成為commit狀態的消息對consumer是可見的。

基本原理

總覽

RocketMQ以Topic來管理不同應用的消息。對於生產者而言，發送消息是，需要指定消息的Topic，對於消費者而言，在啟動后，需要訂閱相應的Topic，然后可以消費相應的消息。Topic是邏輯上的概念，在物理實現上，一個Topic由多個Queue組成，采用多個Queue的好處是可以將Broker存儲分布式化，提高系統性能。[pagebreak][pagebreak]

RocketMQ中，producer將消息發送給Broker時，需要制定發送到哪一個隊列中，默認情況下，producer會輪詢的將消息發送到每個隊列中（所有broker下的Queue合並成一個List去輪詢）。

對於consumer而言，會為每個consumer分配固定的隊列（如果隊列總數沒有發生變化），consumer從固定的隊列中去拉取沒有消費的消息進行處理。

Producer

Producer端（屬於client）的邏輯概述：

producer端的邏輯都比較簡單，將消息發送到某個Queue中即可，具體發送到那個Queue可以由用戶控制（MessageQueueSelector接口），默認情況下，將輪詢方式選擇Queue。在producer端，會從NameServer將所有Broker的Topic及對應的Queue信息（即：TopicRoute信息）拉取到本地，然后根據<brokerName， queueId>組建成一個List。因此在MessageQueueSelector，可以看到所有的Queue信息。

RocketMQ將topic的消息以多個Queue來管理，使得其較為容易的就可以進行水平擴展，提供系統吞吐力。這樣分布帶來的問題，就是從全局上不能做到順序性（很多時候也並不需要全局上的順序性）。

RocketMQ提到支持順序消息，實際上是指基於Queue級別的順序。用戶將某些需要滿足順序的一批消息（比如電商某個訂單號的一系列后續操作、比如數據庫的某個主鍵的insert、delete、update等操作）發送到固定的某個Queue中，則從這個Queue消費消息的consumer，針對這一批消息是順序消費。

問題1：針對順序消息的隊列，是否可以做到不停服務下的集群動態擴展？

Consumer

consumer邏輯稍微復雜一點。初步思考，consumer端至少需要處理：

1、 消息的獲取

2、 offset（消費進度）的管理與存儲

3、 集群消費模式下，Queue的分配問題（rebalance）

RocketMQ對外提供了兩種不同形式的Consumer：PushConsumer和PullConsumer。顧名思義，對於PullConsumer而言，用戶需要主動調用相應的接口去拉取未消費的消息。對於PushConsumer而言，用戶提供消息處理的CallBack，有未曾消費的消息時，會主動回調這個CallBack來處理消息。雖從用戶角度而言，Consumer存在主動（pull）和被動（push），但RocketMQ本身的broker端僅僅保存所有的消息，並不負責push消息，因此PushConsumer的底層實現也是有一個長連接主動去broker上拉取未消費的消息，然后回調用戶的callback邏輯。