你需要知道的RoketMQ

1.概述

本篇文章會盡力全面的介紹RocketMQ和Kafka各個關鍵點的比較，希望大家讀完能有所收穫。

RocketMQ前身叫做MetaQ, 在MeataQ發佈3.0版本的時候改名爲RocketMQ，其本質上的設計思路和Kafka類似，但是和Kafka不同的是其使用Java進行開發，由於在國內的Java受衆羣體遠遠多於Scala，所以RocketMQ是很多以Java語言爲主的公司的首選。同樣的RocketMQ和Kafka都是Apache基金會中的頂級項目，他們社區的活躍度都非常高，項目更新迭代也非常快。

2.入門實例

2.1 生產者

public class Producer {
    public static void main(String[] args) throws MQClientException, InterruptedException {

        DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName");
        producer.start();

        for (int i = 0; i < 128; i++)
            try {
                {
                    Message msg = new Message("TopicTest",
                        "TagA",
                        "OrderID188",
                        "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
                    SendResult sendResult = producer.send(msg);
                    System.out.printf("%s%n", sendResult);
                }

            } catch (Exception e) {
                e.printStackTrace();
            }

        producer.shutdown();
    }
}

直接定義好一個producer，創建好Message，調用send方法即可。

2.2 消費者

public class PushConsumer {

    public static void main(String[] args) throws InterruptedException, MQClientException {
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_JODIE_1");
        consumer.subscribe("TopicTest", "*");
        consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
        //wrong time format 2017_0422_221800
        consumer.setConsumeTimestamp("20181109221800");
        consumer.registerMessageListener(new MessageListenerConcurrently() {

            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
                System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });
        consumer.start();
        System.out.printf("Consumer Started.%n");
    }
}

3.RocketMQ架構原理

對於RocketMQ先拋出幾個問題:

• RocketMQ的topic和隊列是什麼樣的，和Kafka的分區有什麼不同？

• RocketMQ網絡模型是什麼樣的，和Kafka對比如何？

• RocketMQ消息存儲模型是什麼樣的，如何保證高可靠的存儲，和Kafka對比如何？

3.1 RocketMQ架構圖

對於RocketMQ的架構圖，在大體上來看和Kafka並沒有太多的差別，但是在很多細節上是有很多差別的，接下來會一一進行講述。

3.2 RocketMQ名詞解釋

在3.1的架構中我們有多個Producer，多個主Broker，多個從Broker,每個Producer可以對應多個Topic,每個Consumer也可以消費多個Topic。

Broker信息會上報至NameServer,Consumer會從NameServer中拉取Broker和Topic的信息。

• Producer：消息生產者，向Broker發送消息的客戶端

• Consumer：消息消費者，從Broker讀取消息的客戶端

• Broker：消息中間的處理節點，這裏和kafka不同，kafka的Broker沒有主從的概念，都可以寫入請求以及備份其他節點數據，RocketMQ只有主Broker節點才能寫，一般也通過主節點讀，當主節點有故障或者一些其他特殊情況纔會使用從節點讀，有點類似- 於mysql的主從架構。

• Topic：消息主題，一級消息類型，生產者向其發送消息, 消費者讀取其消息。

• Group：分爲ProducerGroup,ConsumerGroup,代表某一類的生產者和消費者，一般來說同一個服務可以作爲Group,同一個Group一般來說發送和消費的消息都是一樣的。

• Tag：Kafka中沒有這個概念，Tag是屬於二級消息類型，一般來說業務有關聯的可以使用同一個Tag,比如訂單消息隊列，使用Topic_Order,Tag可以分爲Tag_食品訂單,Tag_服裝訂單等等。

• Queue: 在kafka中叫Partition,每個Queue內部是有序的，在RocketMQ中分爲讀和寫兩種隊列，一般來說讀寫隊列數量一致，如果不一致就會出現很多問題。

• NameServer：Kafka中使用的是ZooKeeper保存Broker的地址信息，以及Broker的Leader的選舉，在RocketMQ中並沒有採用選舉Broker的策略，所以採用了無狀態的NameServer太存儲，由於NameServer是無狀態的，集羣節點之間並不會通信，所以上傳數據的時候都需要向所有節點進行發送。

很多朋友都在問什麼是無狀態呢？狀態的有無實際上就是數據是否會做存儲，有狀態的話數據會被持久化，無狀態的服務可以理解就是一個內存服務，NameServer本身也是一個內存服務，所有數據都存儲在內存中，重啓之後都會丟失。

3.3 Topic和Queue

在RocketMQ中的每一條消息，都有一個Topic，用來區分不同的消息。一個主題一般會有多個消息的訂閱者，當生產者發佈消息到某個主題時，訂閱了這個主題的消費者都可以接收到生產者寫入的新消息。

在Topic中有分爲了多個Queue，這其實是我們發送/讀取消息通道的最小單位，我們發送消息都需要指定某個寫入某個Queue，拉取消息的時候也需要指定拉取某個Queue，所以我們的順序消息可以基於我們的Queue維度保持隊列有序，如果想做到全局有序那麼需要將Queue大小設置爲1，這樣所有的數據都會在Queue中有序。

在上圖中我們的Producer會通過一些策略進行Queue的選擇：

• 非順序消息：非順序消息一般直接採用輪訓發送的方式進行發送。

• 順序消息：根據某個Key比如我們常見的訂單Id,用戶Id，進行Hash，將同一類數據放在同一個隊列中，保證我們的順序性。

我們同一組Consumer也會根據一些策略來選Queue，常見的比如平均分配或者一致性Hash分配。

要注意的是當Consumer出現下線或者上線的時候，這裏需要做重平衡，也就是Rebalance，RocketMQ的重平衡機制如下:

• 定時拉取broker,topic的最新信息

• 每隔20s做重平衡

• 隨機選取當前Topic的一個主Broker，這裏要注意的是不是每次重平衡所有主Broker都會被選中，因爲會存在一個Broker再多個Broker的情況。

• 獲取當前Broker，當前ConsumerGroup的所有機器ID。

• 然後進行策略分配。

由於重平衡是定時做的，所以這裏有可能會出現某個Queue同時被兩個Consumer消費，所以會出現消息重複投遞。

Kafka的重平衡機制和RocketMQ不同，Kafka的重平衡是通過Consumer和Coordinator聯繫來完成的，當Coordinator感知到消費組的變化，會在心跳過程中發送重平衡的信號，然後由一個ConsumerLeader進行重平衡選擇，然後再由Coordinator將結果通知給所有的消費者。

3.3.1 Queue讀寫數量不一致

在RocketMQ中Queue被分爲讀和寫兩種，在最開始接觸RocketMQ的時候一直以爲讀寫隊列數量配置不一致不會出現什麼問題的，比如當消費者機器很多的時候我們配置很多讀的隊列，但是實際過程中發現會出現消息無法消費和根本沒有消息消費的情況。

• 當寫的隊列數量大於讀的隊列的數量，當大於讀隊列這部分ID的寫隊列的數據會無法消費，因爲不會將其分配給消費者。

• 當讀的隊列數量大於寫的隊列數量，那麼多的隊列數量就不會有消息被投遞進來。

這個功能在RocketMQ在我看來明顯沒什麼用，因爲基本上都會設置爲讀寫隊列大小一樣，這個爲啥不直接將其進行統一，反而容易讓用戶配置不一樣出現錯誤。

這個問題在RocketMQ的Issue裏也沒有收到好的答案。

3.4 消費模型

一般來說消息隊列的消費模型分爲兩種，基於推送的消息(push)模型和基於拉取(poll)的消息模型。

基於推送模型的消息系統，由消息代理記錄消費狀態。消息代理將消息推送到消費者後，標記這條消息爲已經被消費，但是這種方式無法很好地保證消費的處理語義。比如當我們把已經把消息發送給消費者之後，由於消費進程掛掉或者由於網絡原因沒有收到這條消息，如果我們在消費代理將其標記爲已消費，這個消息就永久丟失了。如果我們利用生產者收到消息後回覆這種方法，消息代理需要記錄消費狀態，這種不可取。

用過RocketMQ的同學肯定不禁會想到，在RocketMQ中不是提供了兩種消費者嗎？

MQPullConsumer 和 MQPushConsumer ，其中 MQPushConsumer 不就是我們的推模型嗎？其實這兩種模型都是客戶端主動去拉消息，其中的實現區別如下：

• MQPullConsumer：每次拉取消息需要傳入拉取消息的offset和每次拉取多少消息量，具體拉取哪裏的消息，拉取多少是由客戶端控制。

• MQPushConsumer：同樣也是客戶端主動拉取消息，但是消息進度是由服務端保存，Consumer會定時上報自己消費到哪裏，所以Consumer下次消費的時候是可以找到上次消費的點，一般來說使用PushConsumer我們不需要關心offset和拉取多少數據，直接使用即可。

3.4.1 集羣消費和廣播消費

消費模式我們分爲兩種，集羣消費，廣播消費:

• 集羣消費: 同一個GroupId都屬於一個集羣，一般來說一條消息只會被任意一個消費者處理。

• 廣播消費：廣播消費的消息會被集羣中所有消費者進行消息，但是要注意一下因爲廣播消費的offset在服務端保存成本太高，所以客戶端每一次重啓都會從最新消息消費，而不是上次保存的offset。

3.5 網絡模型

在Kafka中使用的原生的socket實現網絡通信，而RocketMQ使用的是Netty網絡框架，現在越來越多的中間件都不會直接選擇原生的socket，而是使用的Netty框架，主要得益於下面幾個原因:

• API使用簡單，不需要關心過多的網絡細節，更專注於中間件邏輯。

• 性能高。

• 成熟穩定，jdk nio的bug都被修復了。

選擇框架是一方面，而想要保證網絡通信的高效，網絡線程模型也是一方面，我們常見的有1+N(1個Acceptor線程，N個IO線程)，1+N+M(1個acceptor線程，N個IO線程，M個worker線程)等模型，RocketMQ使用的是1+N1+N2+M的模型，如下圖所示：

1個acceptor線程，N1個IO線程，N2個線程用來做Shake-hand,SSL驗證,編解碼;M個線程用來做業務處理。這樣的好處將編解碼，和SSL驗證等一些可能耗時的操作放在了一個單獨的線程池，不會佔據我們業務線程和IO線程。

3.6 高可靠的分佈式存儲模型

做爲一個好的消息系統，高性能的存儲，高可用都不可少。

3.6.1 高性能日誌存儲

RocketMQ和Kafka的存儲核心設計有很大的不同，所以其在寫入性能方面也有很大的差別，這是16年阿里中間件團隊對RocketMQ和Kafka不同Topic下做的性能測試:

從圖上可以看出：

• Kafka在Topic數量由64增長到256時，吞吐量下降了98.37%。

• RocketMQ在Topic數量由64增長到256時，吞吐量只下降了16%。

  這是爲什麼呢？kafka一個topic下面的所有消息都是以partition的方式分佈式的存儲在多個節點上。同時在kafka的機器上，每個Partition其實都會對應一個日誌目錄，在目錄下面會對應多個日誌分段。所以如果Topic很多的時候Kafka雖然寫文件是順序寫，但實際上文件過多，會造成磁盤IO競爭非常激烈。

那RocketMQ爲什麼在多Topic的情況下，依然還能很好的保持較多的吞吐量呢？我們首先來看一下RocketMQ中比較關鍵的文件:

這裏有四個目錄（這裏的解釋就直接用RocketMQ官方的了）:

• commitLog：消息主體以及元數據的存儲主體，存儲Producer端寫入的消息主體內容,消息內容不是定長的。單個文件大小默認1G ，文件名長度爲20位，左邊補零，剩餘爲起始偏移量，比如00000000000000000000代表了第一個文件，起始偏移量爲0，文件大小爲1G=1073741824；當第一個文件寫滿了，第二個文件爲00000000001073741824，起始偏移量爲1073741824，以此類推。消息主要是順序寫入日誌文件，當文件滿了，寫入下一個文件；

• config：保存一些配置信息，包括一些Group，Topic以及Consumer消費offset等信息。

• consumeQueue:消息消費隊列，引入的目的主要是提高消息消費的性能，由於RocketMQ是基於主題topic的訂閱模式，消息消費是針對主題進行的，如果要遍歷commitlog文件中根據topic檢索消息是非常低效的。Consumer即可根據ConsumeQueue來查找待消費的消息。其中，ConsumeQueue（邏輯消費隊列）作爲消費消息的索引，保存了指定Topic下的隊列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值。consumequeue文件可以看成是基於topic的commitlog索引文件，故consumequeue文件夾的組織方式如下：topic/queue/file三層組織結構，具體存儲路徑爲：HOME \store\index\${fileName}，文件名fileName是以創建時的時間戳命名的，固定的單個IndexFile文件大小約爲400M，一個IndexFile可以保存 2000W個索引，IndexFile的底層存儲設計爲在文件系統中實現HashMap結構，故rocketmq的索引文件其底層實現爲hash索引。

我們發現我們的消息主體數據並沒有像Kafka一樣寫入多個文件，而是寫入一個文件,這樣我們的寫入IO競爭就非常小，可以在很多Topic的時候依然保持很高的吞吐量。有同學說這裏的ConsumeQueue寫是在不停的寫入呢，並且ConsumeQueue是以Queue維度來創建文件，那麼文件數量依然很多，在這裏ConsumeQueue的寫入的數據量很小，每條消息只有20個字節，30W條數據也才6M左右，所以其實對我們的影響相對Kafka的Topic之間影響是要小很多的。我們整個的邏輯可以如下：

Producer不斷的再往CommitLog添加新的消息，有一個定時任務ReputService會不斷的掃描新添加進來的CommitLog，然後不斷的去構建ConsumerQueue和Index。

注意：這裏指的都是普通的硬盤，在SSD上面多個文件併發寫入和單個文件寫入影響不大。

讀取消息

Kafka中每個Partition都會是一個單獨的文件，所以當消費某個消息的時候，會很好的出現順序讀，我們知道OS從物理磁盤上訪問讀取文件的同時，會順序對其他相鄰塊的數據文件進行預讀取，將數據放入PageCache，所以Kafka的讀取消息性能比較好。

RocketMQ讀取流程如下：

• 先讀取ConsumerQueue中的offset對應CommitLog物理的offset

• 根據offset讀取CommitLog

ConsumerQueue也是每個Queue一個單獨的文件，並且其文件體積小，所以很容易利用PageCache提高性能。而CommitLog，由於同一個Queue的連續消息在CommitLog其實是不連續的，所以會造成隨機讀，RocketMQ對此做了幾個優化：

• Mmap映射讀取，Mmap的方式減少了傳統IO將磁盤文件數據在操作系統內核地址空間的緩衝區和用戶應用程序地址空間的緩衝區之間來回進行拷貝的性能開銷

• 使用DeadLine調度算法+SSD存儲盤

• 由於Mmap映射受到內存限制，當不在Mmmap映射這部分數據的時候(也就是消息堆積過多)，默認是內存的40%，會將請求發送到SLAVE,減緩Master的壓力

3.6.2 可用性

3.6.2.1 集羣模式

我們首先需要選擇一種集羣模式，來適應我們可忍耐的可用程度，一般來說分爲三種：

• 單Master:這種模式，可用性最低，但是成本也是最低，一旦宕機，所有都不可用。這種一般只適用於本地測試。

• 單Master多SLAVE:這種模式，可用性一般，如果主宕機，那麼所有寫入都不可用，讀取依然可用，如果master磁盤損壞，可以依賴slave的數據。

• 多Master:這種模式，可用性一般，如果出現部分master宕機，那麼這部分master上的消息都不可消費，也不可寫數據，如果一個Topic的隊列在多個Master上都有，那麼可以保證沒有宕機的那部分可以正常消費，寫入。如果master的磁盤損壞會導致消息丟失。

• 多Master多Slave：這種模式，可用性最高，但是維護成本也最高，當master宕機了之後，只會出現在這部分master上的隊列不可寫入，但是讀取依然是可以的，並且如果master磁盤損壞，可以依賴slave的數據。

一般來說投入生產環境的話都會選擇第四種，來保證最高的可用性。

3.6.2.2 消息的可用性

當我們選擇好了集羣模式之後，那麼我們需要關心的就是怎麼去存儲和複製這個數據，rocketMQ對消息的刷盤提供了同步和異步的策略來滿足我們的，當我們選擇同步刷盤之後，如果刷盤超時會給返回FLUSH_DISK_TIMEOUT，如果是異步刷盤不會返回刷盤相關信息，選擇同步刷盤可以盡最大程度滿足我們的消息不會丟失。

除了存儲有選擇之後，我們的主從同步提供了同步和異步兩種模式來進行復制，當然選擇同步可以提升可用性，但是消息的發送RT時間會下降10%左右。

3.6.3 Dleger

我們上面對於master-slave部署模式已經做了很多分析，我們發現，當master出現問題的時候，我們的寫入怎麼都會不可用，除非恢復master，或者手動將我們的slave切換成master，導致了我們的Slave在多數情況下只有讀取的作用。RocketMQ在最近的幾個版本中推出了Dleger-RocketMQ，使用Raft協議複製CommitLog，並且自動進行選主，這樣master宕機的時候，寫入依然保持可用。

3.7 定時/延時消息

定時消息和延時消息在實際業務場景中使用的比較多，比如下面的一些場景：

• 訂單超時未支付自動關閉，因爲在很多場景中下單之後庫存就被鎖定了，這裏需要將其進行超時關閉。

• 需要一些延時的操作，比如一些兜底的邏輯，當做完某個邏輯之後，可以發送延時消息比如延時半個小時，進行兜底檢查補償。

• 在某個時間給用戶發送消息，同樣也可以使用延時消息。

在開源版本的RocketMQ中延時消息並不支持任意時間的延時，需要設置幾個固定的延時等級，目前默認設置爲： 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h ，從1s到2h分別對應着等級1到18，而阿里雲中的版本(要付錢)是可以支持40天內的任何時刻（毫秒級別）。我們先看下在RocketMQ中定時任務原理圖：

• Step1：Producer在自己發送的消息上設置好需要延時的級別。

• Step2: Broker發現此消息是延時消息，將Topic進行替換成延時Topic，每個延時級別都會作爲一個單獨的queue，將自己的Topic作爲額外信息存儲。

• Step3: 構建ConsumerQueue

• Step4: 定時任務定時掃描每個延時級別的ConsumerQueue。

• Step5: 拿到ConsumerQueue中的CommitLog的Offset，獲取消息，判斷是否已經達到執行時間

• Step6: 如果達到，那麼將消息的Topic恢復，進行重新投遞。如果沒有達到則延遲沒有達到的這段時間執行任務。

可以看見延時消息是利用新建單獨的Topic和Queue來實現的，如果我們要實現40天之內的任意時間度，基於這種方案，那麼需要40 24 60 60 1000個queue，這樣的成本是非常之高的，那阿里雲上面的支持任意時間是怎麼實現的呢？這裏猜測是持久化二級TimeWheel時間輪，二級時間輪用於替代我們的ConsumeQueue，保存Commitlog-Offset，然後通過時間輪不斷的取出當前已經到了的時間，然後再次投遞消息。具體的實現邏輯需要後續會單獨寫一篇文章。

3.8 事務消息

事務消息同樣的也是RocketMQ中的一大特色，其可以幫助我們完成分佈式事務的最終一致性，有關分佈式事務相關的可以看我以前的很多文章都有很多詳細的介紹。

具體使用事務消息步驟如下：

• Step1：調用sendMessageInTransaction發送事務消息

• Step2:  如果發送成功，則執行本地事務。

• Step3:  如果執行本地事務成功則發送commit，如果失敗則發送rollback。

• Step4:  如果其中某個階段比如commit發送失敗，rocketMQ會進行定時從Broker回查，本地事務的狀態。

事務消息的使用整個流程相對之前幾種消息使用比較複雜，下面是事務消息實現的原理圖：

• Step1: 發送事務消息,這裏也叫做halfMessage，會將Topic替換爲HalfMessage的Topic。

• Step2: 發送commit或者rollback，如果是commit這裏會查詢出之前的消息，然後將消息復原成原Topic，並且發送一個OpMessage用於記錄當前消息可以刪除。如果是rollback這裏會直接發送一個OpMessage刪除。

• Step3: 在Broker有個處理事務消息的定時任務，定時對比halfMessage和OpMessage,如果有OpMessage且狀態爲刪除，那麼該條消息必定commit或者rollback，所以就可以刪除這條消息。

• Step4: 如果事務超時（默認是6s），還沒有opMessage，那麼很有可能commit信息丟了，這裏會去反查我們的Producer本地事務狀態。

• Step5: 根據查詢出來的信息做Step2。

我們發現RocketMQ實現事務消息也是通過修改原Topic信息，和延遲消息一樣，然後模擬成消費者進行消費，做一些特殊的業務邏輯。當然我們還可以利用這種方式去做RocketMQ更多的擴展。

4.總結

這裏讓我們在回到文章中提到的幾個問題：

• RocketMQ的topic和隊列是什麼樣的，和Kafka的分區有什麼不同？

• RocketMQ網絡模型是什麼樣的，和Kafka對比如何？

• RocketMQ消息存儲模型是什麼樣的，如何保證高可靠的存儲，和Kafka對比如何？

想必讀完這篇文章，你心中已經有答案