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端至少須要處理：

一、 消息的獲取

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

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

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