RocketMQ為什麼這麼快？我從原始碼中扒出了10大原因！

三友的java日记發表於2024-03-12
MQ原始碼

大家好，我是三友~~

RocketMQ作為阿里開源的訊息中介軟體，深受廣大開發者的喜愛

而這其中一個很重要原因就是，它處理訊息和拉取訊息的速度非常快

那麼，問題來了，RocketMQ為什麼這麼快呢？

接下來，我將從以下10個方面來探討一下RocketMQ這麼快的背後原因

如果你對RocketMQ還不瞭解，可以從公眾號後臺選單欄中檢視我之前寫的關於RocketMQ的幾篇文章

如果你對RocketMQ原始碼也感興趣，可以從下面這個倉庫fork一下原始碼，我在原始碼中加了中文註釋，並且後面我還會持續更新註釋

https://github.com/sanyou3/rocketmq.git

本文是基於RocketMQ 4.9.x版本講解

批次傳送訊息

RocketMQ在傳送訊息的時候支援一次性批次傳送多條訊息，如下程式碼所示：

public class Producer {
    public static void main(String[] args) throws Exception {
        //建立一個生產者，指定生產者組為 sanyouProducer
        DefaultMQProducer producer = new DefaultMQProducer("sanyouProducer");
        // 指定NameServer的地址
        producer.setNamesrvAddr("192.168.200.143:9876");
        // 啟動生產者
        producer.start();

        //用以及集合儲存多個訊息
        List<Message> messages = new ArrayList<>();
        messages.add(new Message("sanyouTopic", "三友的java日記 0".getBytes()));
        messages.add(new Message("sanyouTopic", "三友的java日記 1".getBytes()));
        messages.add(new Message("sanyouTopic", "三友的java日記 2".getBytes()));
        // 傳送訊息並得到訊息的傳送結果，然後列印
        SendResult sendResult = producer.send(messages);
        System.out.printf("%s%n", sendResult);

        // 關閉生產者
        producer.shutdown();
    }

}

透過批次傳送訊息，減少了RocketMQ客戶端與服務端，也就是Broker之間的網路通訊次數，提高傳輸效率

不過在使用批次訊息的時候，需要注意以下三點：

  • 每條訊息的Topic必須都得是一樣的
  • 不支援延遲訊息和事務訊息
  • 不論是普通訊息還是批次訊息，總大小預設不能超過4m

訊息壓縮

RocketMQ在傳送訊息的時候，當發現訊息的大小超過4k的時候，就會對訊息進行壓縮

這是因為如果訊息過大，會對網路頻寬造成壓力

不過需要注意的是，如果是批次訊息的話，就不會進行壓縮，如下所示：

壓縮訊息除了能夠減少網路頻寬造成壓力之外，還能夠節省訊息儲存空間

RocketMQ在往磁碟存訊息的時候，並不會去解壓訊息，而是直接將壓縮後的訊息存到磁碟

消費者拉取到的訊息其實也是壓縮後的訊息

不過消費者在拿到訊息之後會對訊息進行解壓縮

當我們的業務系統拿到訊息的時候，其實就是解壓縮後的訊息

雖然壓縮訊息能夠減少頻寬壓力和磁碟儲存壓力

但是由於壓縮和解壓縮的過程都是在客戶端（生產者、消費者）完成的

所以就會導致客戶端消耗更多的CPU資源，對CPU造成一定的壓力

高效能網路通訊模型

當生產者處理好訊息之後，就會將訊息透過網路通訊傳送給服務端

而RocketMQ之所以快的一個非常重要原因就是它擁有高效能網路通訊模型

RocketMQ網路通訊這塊底層是基於Netty來實現的

Netty是一款非常強大、非常優秀的網路應用程式框架，主要有以下幾個優點：

  • 非同步和事件驅動：Netty基於事件驅動的架構，使用了非同步I/O操作，避免了阻塞式I/O呼叫的缺陷，能夠更有效地利用系統資源，提高併發處理能力。
  • 高效能：Netty針對效能進行了最佳化，比如使用直接記憶體進行緩衝，減少垃圾回收的壓力和記憶體複製的開銷，提供了高吞吐量、低延遲的網路通訊能力。
  • 可擴充套件性：Netty的設計允許使用者自定義各種Handler來處理協議編碼、協議解碼和業務邏輯等。並且，它的模組可插拔性設計使得使用者可以根據需要輕鬆地新增或更換元件。
  • 簡化API：與Java原生NIO庫相比，Netty提供了更加簡潔易用的API，大大降低了網路程式設計的複雜度。
  • 安全：Netty內建了對SSL/TLS協議的支援，使得構建安全通訊應用變得容易。
  • 豐富的協議支援：Netty提供了HTTP、HTTP/2、WebSocket、Google Protocol Buffers等多種協議的編解碼支援，滿足不同網路應用需求。
  • ...

就是因為Netty如此的強大，所以不僅僅RocketMQ是基於Netty實現網路通訊的

幾乎絕大多數只要涉及到網路通訊的Java類框架，底層都離不開Netty的身影

比如知名RPC框架Dubbo、Java gRPC實現、Redis的親兒子Redisson、分散式任務排程平臺xxl-job等等

它們底層在實現網路通訊時，都是基於Netty框架

零複製技術

當訊息達到RocketMQ服務端之後，為了能夠保證服務端重啟之後訊息也不丟失，此時就需要將訊息持久化到磁碟

由於涉及到訊息持久化操作，就涉及到磁碟檔案的讀寫操作

RocketMQ為了保證磁碟檔案的高效能讀寫，使用到了一個叫零複製的技術

1、傳統IO讀寫方式

說零複製之前，先說一下傳統的IO讀寫方式。

比如現在有一個需求，將磁碟檔案透過網路傳輸出去

那麼整個傳統的IO讀寫模型如下圖所示

傳統的IO讀寫其實就是read + write的操作，整個過程會分為如下幾步

  • 使用者呼叫read()方法，開始讀取資料，此時發生一次上下文從使用者態到核心態的切換，也就是圖示的切換1
  • 將磁碟資料透過DMA複製到核心快取區
  • 將核心快取區的資料複製到使用者緩衝區，這樣使用者，也就是我們寫的程式碼就能拿到檔案的資料
  • read()方法返回，此時就會從核心態切換到使用者態，也就是圖示的切換2
  • 當我們拿到資料之後，就可以呼叫write()方法，此時上下文會從使用者態切換到核心態，即圖示切換3
  • CPU將使用者緩衝區的資料複製到Socket緩衝區
  • 將Socket緩衝區資料複製至網路卡
  • write()方法返回，上下文重新從核心態切換到使用者態，即圖示切換4

整個過程發生了4次上下文切換和4次資料的複製，這在高併發場景下肯定會嚴重影響讀寫效能。

所以為了減少上下文切換次數和資料複製次數，就引入了零複製技術。

2、零複製

零複製技術是一個思想，指的是指計算機執行操作時，CPU不需要先將資料從某處記憶體複製到另一個特定區域。

實現零複製的有以下兩種方式：

  • mmap()
  • sendfile()

mmap()

mmap（memory map）是一種記憶體對映檔案的方法，即將一個檔案或者其它物件對映到程序的地址空間，實現檔案磁碟地址和程序虛擬地址空間中一段虛擬地址的一一對映關係。

簡單地說就是核心緩衝區和應用緩衝區進行對映

使用者在操作應用緩衝區時就好像在操作核心緩衝區

比如你往應用緩衝區寫資料，就好像直接往核心緩衝區寫資料，這個過程不涉及到CPU複製

而傳統IO就需要將在寫完應用緩衝區之後需要將資料透過CPU複製到核心緩衝區

同樣地上述檔案傳輸功能，如果使用mmap的話，由於我們可以直接操作核心緩衝區

此時我們就可以將核心緩衝區的資料直接CPU複製到Socket緩衝區

整個IO模型就會如下圖所示：

基於mmap IO讀寫其實就變成mmap + write的操作，也就是用mmap替代傳統IO中的read操作

  • 當使用者發起mmap呼叫的時候會發生上下文切換1，進行記憶體對映，然後資料被複製到核心緩衝區，mmap返回，發生上下文切換2
  • 隨後使用者呼叫write，發生上下文切換3，將核心緩衝區的資料複製到Socket緩衝區，write返回，發生上下文切換4。

上下文切換的次數仍然是4次，但是複製次數只有3次，少了一次CPU複製。

所以總的來說，使用mmap就可以直接少一次CPU複製。

說了這麼多，那麼在Java中，如何去實現mmap，也就是核心緩衝區和應用緩衝區對映呢？

其實在Java NIO類庫中就提供了相應的API，當然底層也還是呼叫Linux系統的mmap()實現的，程式碼如下所示

FileChannel fileChannel = new RandomAccessFile("test.txt", "rw").getChannel();
MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, fileChannel.size());

MappedByteBuffer，你可以認為操作這個物件就好像直接操作核心緩衝區

比如可以透過MappedByteBuffer讀寫磁碟檔案，此時就好像直接從核心緩衝區讀寫資料

當然也可以直接透過MappedByteBuffer將檔案的資料複製到Socket緩衝區，實現上述檔案傳輸的模型

這裡我就不貼相應的程式碼了

RocketMQ在儲存檔案時，就是透過mmap技術來實現高效的檔案讀寫

RocketMQ中使用mmap程式碼
RocketMQ中使用mmap程式碼

雖然前面一直說mmap不涉及CPU複製，但在某些特定場景下，尤其是在寫操作或特定的系統最佳化策略下，還是可能涉及CPU複製。

sendfile()

sendfile()跟mmap()一樣，也會減少一次CPU複製，但是它同時也會減少兩次上下文切換。

sendfile()主要是用於檔案傳輸，比如將檔案傳輸到另一個檔案，又或者是網路

當基於sendfile()時，一次檔案傳輸的過程就如下圖所示：

使用者發起sendfile()呼叫時會發生切換1，之後資料透過DMA複製到核心緩衝區，之後再將核心緩衝區的資料CPU複製到Socket緩衝區，最後複製到網路卡，sendfile()返回，發生切換2。

同樣地，Java NIO類庫中也提供了相應的API實現sendfile

當然底層還是作業系統的sendfile()

FileChannel channel = FileChannel.open(Paths.get("./test.txt"), StandardOpenOption.WRITE, StandardOpenOption.CREATE);
//呼叫transferTo方法向目標資料傳輸
channel.transferTo(position, len, target);

FileChannel的transferTo方法底層就是基於sendfile來的

在如上程式碼中，並沒有檔案的讀寫操作，而是直接將檔案的資料傳輸到target目標緩衝區

也就是說，sendfile傳輸檔案時是無法知道檔案的具體的資料的

但是mmap不一樣，mmap可以來直接修改核心緩衝區的資料

假設如果需要對檔案的內容進行修改之後再傳輸，mmap可以滿足

小總結

在傳統IO中，如果想將使用者快取區的資料放到核心緩衝區，需要經過CPU複製

而基於零複製技術可以減少CPU複製次數，常見的有兩種：

  • mmap()
  • sendfile()

mmap()是將使用者緩衝區和核心緩衝區共享，操作使用者緩衝區就好像直接操作核心緩衝區，讀寫資料時不需要CPU複製

Java中可以使用MappedByteBuffer這個API來達到操作核心緩衝區的效果

sendfile()主要是用於檔案傳輸，可以透過sendfile()將一個檔案內容傳輸到另一個檔案中或者是網路中

sendfile()在整個過程中是無法對檔案內容進行修改的，如果想修改之後再傳輸，可以透過mmap來修改內容之後再傳輸

上面出現的API都是Java NIO標準類庫中的

如果你看的還是很迷糊，那直接記住一個結論

之所以基於零複製技術能夠高效的實現檔案的讀寫操作，主要因為是減少了CPU複製次數和上下文切換次數

在RocketMQ中，底層是基於mmap()來實現檔案的高效讀寫的

順序寫

RocketMQ在儲存訊息時，除了使用零複製技術來實現檔案的高效讀寫之外

還使用順序寫的方式提高資料寫入的速度

RocketMQ會將訊息按照順序一條一條地寫入檔案中

這種順序寫的方式由於減少了磁頭的移動和尋道時間，在大規模資料寫入的場景下，使得資料寫入的速度更快

高效的資料儲存結構

Topic和佇列的關係

在RocketMQ中，預設會為每個Topic在每個服務端Broker例項上建立4個佇列

如果有兩個Broker，那麼預設就會有8個佇列

每個Broker上的佇列上的編號（queueId）都是從0開始

CommitLog

前面一直說，當訊息到達RocektMQ服務端時，需要將訊息存到磁碟檔案

RocketMQ給這個存訊息的檔案起了一個高大上的名字：CommitLog

由於訊息會很多，所以為了防止檔案過大，CommitLog在物理磁碟檔案上被分為多個磁碟檔案，每個檔案預設的固定大小是1G

訊息在寫入到檔案時，除了包含訊息本身的內容資料，也還會包含其它資訊，比如

  • 訊息的Topic
  • 訊息所在佇列的id，生產者傳送訊息時會攜帶這個佇列id
  • 訊息生產者的ip和埠
  • ...

這些資料會和訊息本身按照一定的順序同時寫到CommitLog檔案中

上圖中黃色排列順序和實際的存的內容並非實際情況，我只是舉個例子

ConsumeQueue

除了CommitLog檔案之外，RocketMQ還會為每個佇列建立一個磁碟檔案

RocketMQ給這個檔案也起了一個高大上的名字：ConsumeQueue

當訊息被存到CommitLog之後，其實還會往這條訊息所在佇列的ConsumeQueue檔案中插一條資料

每個佇列的ConsumeQueue也是由多個檔案組成，每個檔案預設是存30萬條資料

插入ConsumeQueue中的每條資料由20個位元組組成，包含3部分資訊

  • 訊息在CommitLog的起始位置（8個位元組），也被稱為偏移量
  • 訊息在CommitLog儲存的長度（8個位元組）
  • 訊息tag的hashCode（4個位元組）

每條資料也有自己的編號（offset），預設從0開始，依次遞增

所以，透過ConsumeQueue中存的資料可以從CommitLog中找到對應的訊息

那麼這個ConsumeQueue有什麼作用呢？

其實透過名字也能猜到，這其實跟訊息消費有關

當消費者拉取訊息的時候，會告訴服務端四個比較重要的資訊

  • 自己需要拉取哪個Topic的訊息
  • 從Topic中的哪個佇列（queueId）拉取
  • 從佇列的哪個位置（offset）拉取訊息
  • 拉取多少條訊息(預設32條)

服務端接收到訊息之後，總共分為四步處理：

  • 首先會找到對應的Topic
  • 之後根據queueId找到對應的ConsumeQueue檔案
  • 然後根據offset位置，從ConsumeQueue中讀取跟拉取訊息條數一樣條數的資料

由於ConsumeQueue每條資料都是20個位元組，所以根據offset的位置可以很快定位到應該從檔案的哪個位置開始讀取資料

  • 最後解析每條資料，根據偏移量和訊息的長度到CommitLog檔案查詢真正的訊息內容

整個過程如下圖所示：

所以，從這可以看出，當消費者在拉取訊息時，ConsumeQueue其實就相當於是一個索引檔案，方便快速查詢在CommitLog中的訊息

並且無論CommitLog存多少訊息，整個查詢訊息的時間複雜度都是O(1)

由於ConsumeQueue每條資料都是20個位元組，所以如果需要找第n條資料，只需要從第n * 20個位元組的位置開始讀20個位元組的資料即可，這個過程是O(1)的

當從ConsumeQueue找到資料之後，解析出訊息在CommitLog儲存的起始位置和大小，之後就直接根據這兩個資訊就可以從CommitLog中找到這條訊息了，這個過程也是O(1)的

所以整個查詢訊息的過程就是O(1)的

所以從這就可以看出，ConsumeQueue和CommitLog相互配合，就能保證快速查詢到訊息，消費者從而就可以快速拉取訊息

非同步處理

RocketMQ在處理訊息時，有很多非同步操作，這裡我舉兩個例子：

  • 非同步刷盤
  • 非同步主從複製

非同步刷盤

前面說到，檔案的內容都是先寫到核心緩衝區，也可以說是PageCache

而寫到PageCache並不能保證訊息一定不丟失

因為如果伺服器掛了，這部分資料還是可能會丟失的

所以為了解決這個問題，RocketMQ會開啟一個後臺執行緒

這個後臺執行緒預設每隔0.5s會將訊息從PageCache刷到磁碟中

這樣就能保證訊息真正的持久化到磁碟中

非同步主從複製

在RocketMQ中，支援主從複製的叢集模式

這種模式下，寫訊息都是寫入到主節點，讀訊息一般也是從主節點讀，但是有些情況下可能會從從節點讀

從節點在啟動的時候會跟主節點建立網路連線

當主節點將訊息儲存的CommitLog檔案之後，會透過後臺一個非同步執行緒，不停地將訊息傳送給從節點

從節點接收到訊息之後，就直接將訊息存到CommitLog檔案

小總結

就是因為有這些非同步操作，大大提高了訊息儲存的效率

不過值得注意的，儘管非同步可以提高效率，但是也增加了不確定性，比如丟訊息等等

當然RocketMQ也支援同步等待訊息刷盤和主從複製成功，但這肯定會導致效能降低

所以在專案中可以根據自己的業務需要選擇對應的刷盤和主從複製的策略

批次處理

除了非同步之外，RocketMQ還大量使用了批次處理機制

比如前面說過，消費者拉取訊息的時候，可以指定拉取拉取訊息的條數，批次拉取訊息

這種批次拉取機制可以減少消費者跟RocketMQ服務端的網路通訊次數，提高效率

除了批次拉取訊息之外，RocketMQ在提交消費進度的時候也使用了批次處理機制

所謂的提交消費進度就是指

當消費者在成功消費訊息之後，需要將所消費訊息的offset（ConsumeQueue中的offset）提交給RocketMQ服務端

告訴RocketMQ，這個Queue的訊息我已經消費到了這個位置了

這樣一旦消費者重啟了或者其它啥的要從這個Queue重新開始拉取訊息的時候

此時他只需要問問RocketMQ服務端上次這個Queue訊息消費到哪個位置了

之後消費者只需要從這個位置開始消費訊息就行了，這樣就解決了接著消費的問題

RocketMQ在提交消費進度的時候並不是說每消費一條訊息就提交一下這條訊息對應的offset

而是預設每隔5s定時去批次提交一次這5s鍾消費訊息的offset

鎖最佳化

由於RocketMQ內部採用了很多執行緒非同步處理機制

這就一定會產生併發情況下的執行緒安全問題

在這種情況下，RocketMQ進行了多方面的鎖最佳化以提高效能和併發能力

就比如拿訊息儲存來說

為了保證訊息是按照順序一條一條地寫入到CommitLog檔案中，就需要對這個寫訊息的操作進行加鎖

而RocketMQ預設使用ReentrantLock來加鎖，並不是synchronized

當然除了預設情況外，RocketMQ還提供了一種基於CAS加鎖的實現

這種實現可以在寫訊息壓力較低的情況下使用

當然除了寫訊息之外，在一些其它的地方，RocketMQ也使用了基於CAS的原子操作來代替傳統的鎖機制

例如使用大量使用了AtomicInteger、AtomicLong等原子類來實現併發控制，避免了顯式的鎖競爭，提高了效能

執行緒池隔離

RocketMQ在處理請求的時候，會為不同的請求分配不同的執行緒池進行處理

比如對於訊息儲存請求和拉取訊息請求來說

Broker會有專門為它們分配兩個不同的執行緒池去分別處理這些請求

這種讓不同的業務由不同的執行緒池去處理的方式，能夠有效地隔離不同業務邏輯之間的執行緒資源的影響

比如訊息儲存請求處理過慢並不會影響處理拉取訊息請求

所以RocketMQ透過執行緒隔離及時可以有效地提高系統的併發效能和穩定性

總結

到這我就從10個方面講完了RocketMQ為什麼這麼快背後的原因

不知道你讀完文章之後有什麼感受

其實實際上RocketMQ快的原因遠遠不止我上面說的這幾點

RocketMQ本身還做了很多其它的最佳化，比如拉取訊息的長輪詢機制、檔案預熱機制等等

正是因為有各種各樣設計細節上的最佳化，才最終決定了RocketMQ出色的效能表現

好了，本文就講到這裡，如果覺得本文對你有點幫助，歡迎點贊、在看、收藏、轉發分享給其他需要的人

你的支援就是我更新的最大動力，感謝感謝！

讓我們下期再見，拜拜！

參考文章：

  • https://mp.weixin.qq.com/s/mOD9Z6pxSxBQuNx3YaUw3A

往期熱門文章推薦

如何去閱讀原始碼，我總結了18條心法

如何寫出漂亮程式碼，我總結了45個小技巧

三萬字盤點Spring/Boot的那些常用擴充套件點

三萬字盤點Spring 9大核心基礎功能

兩萬字盤點那些被玩爛了的設計模式

萬字+20張圖探秘Nacos註冊中心核心實現原理

萬字+20張圖剖析Spring啟動時12個核心步驟

1.5萬字+30張圖盤點索引常見的11個知識點

掃碼或者搜尋關注公眾號 三友的java日記 ，及時乾貨不錯過，公眾號致力於透過畫圖加上通俗易懂的語言講解技術，讓技術更加容易學習，回覆 面試 即可獲得一套面試真題。

相關文章