引言

消息隊列的存儲架構(gòu)是決定其可靠性、吞吐量、延遲性能的核心因素，直接影響業(yè)務場景適配能力。本文聚焦三款主流消息隊列 ——Kafka（LinkedIn 開源，側(cè)重高吞吐）、RocketMQ（阿里開源，金融級特性突出）、JMQ（京東開源，側(cè)重高可用與靈活性），從存儲模型、數(shù)據(jù)組織、索引設計等維度展開深度對比，為技術(shù)選型與架構(gòu)優(yōu)化提供參考。?

本文將從概念辨析出發(fā)，系統(tǒng)拆解主流存儲模型與存儲引擎的設計邏輯，對比 JMQ、Kafka、RocketMQ的技術(shù)選型差異與架構(gòu)設計。?

一、Kafka存儲架構(gòu)

1.1 核心存儲模型：分區(qū)日志流

??

Topic - 主題

Kafka學習了數(shù)據(jù)庫里面的設計，在里面設計了topic（主題），這個東西類似于關系型數(shù)據(jù)庫的表，此時我需要獲取中國移動的數(shù)據(jù)，那就直接監(jiān)聽中國移動訂閱的Topic即可。

Partition - 分區(qū)

Kafka還有一個概念叫Partition（分區(qū)），分區(qū)具體在服務器上面表現(xiàn)起初就是一個目錄，一個主題下面有多個分區(qū)，這些分區(qū)會存儲到不同的服務器上面，或者說，其實就是在不同的主機上建了不同的目錄。這些分區(qū)主要的信息就存在了.log文件里面。跟數(shù)據(jù)庫里面的分區(qū)差不多，是為了提高性能。

至于為什么提高了性能，很簡單，多個分區(qū)多個線程，多個線程并行處理肯定會比單線程好得多。

Topic和partition像是HBASE里的table和region的概念，table只是一個邏輯上的概念，真正存儲數(shù)據(jù)的是region，這些region會分布式地存儲在各個服務器上面，對應于kafka，也是一樣，Topic也是邏輯概念，而partition就是分布式存儲單元。這個設計是保證了海量數(shù)據(jù)處理的基礎。我們可以對比一下，如果HDFS沒有block的設計，一個100T的文件也只能單獨放在一個服務器上面，那就直接占滿整個服務器了，引入block后，大文件可以分散存儲在不同的服務器上。

注意：

1.分區(qū)會有單點故障問題，所以我們會為每個分區(qū)設置副本數(shù)

2.分區(qū)的編號是從0開始的

??

Kafka 以「主題（Topic）- 分區(qū)（Partition）」為核心組織數(shù)據(jù)，每個分區(qū)本質(zhì)是一個 append-only 的日志流，消息按生產(chǎn)順序追加存儲，保證分區(qū)內(nèi)消息有序性。?

優(yōu)點：可以充分利用磁盤順序讀寫高性能的特性。存儲介質(zhì)也可以選擇廉價的SATA磁盤，這樣可以獲得更長的數(shù)據(jù)保留時間、更低的數(shù)據(jù)存儲成本。

1.2 數(shù)據(jù)組織：分段日志文件

?每個分區(qū)拆分為多個 Segment 文件（默認 1GB），命名格式為「起始偏移量.log」（如 00000000000000000000.log）?，做這個限制目的是為了方便把.log加載到內(nèi)存去操作

?配套兩類索引文件：.index（偏移量→物理地址映射）、.timeindex（時間戳→偏移量映射）??

??

這個9936472之類的數(shù)字，就是代表了這個日志段文件里包含的起始offset，也就說明這個分區(qū)里至少都寫入了接近1000萬條數(shù)據(jù)了。

Kafka broker有一個參數(shù)，log.segment.bytes，限定了每個日志段文件的大小，最大就是1GB，一個日志段文件滿了，就自動開一個新的日志段文件來寫入，避免單個文件過大，影響文件的讀寫性能，這個過程叫做log rolling，正在被寫入的那個日志段文件，叫做active log segment。

1.3 消息讀/寫過程

??

寫消息：

?Index文件寫入，Index文件較小，可以直接用mmap進行內(nèi)存映射，避免頻繁的磁盤I/O操作，提高寫入性能；由于Index文件是稀疏索引，只需要記錄關鍵位置的偏移量，因此即使使用mmap，寫入的開銷也相對較低。

?Segment文件寫入，Segment文件較大，可以采用普通的寫操作（FileChannel.write），由于Segment文件是順序?qū)懭氲?，并且Kafka會利用操作系統(tǒng)的PageCache（頁緩存）機制，寫入操作會先寫入到內(nèi)存中，然后由操作系統(tǒng)在后臺異步刷新到磁盤，可以進一步提高寫入的性能。

讀消息：

?Index文件讀取，通常使用mmap方式讀取，由于Index文件較小，且是稀疏索引，缺頁中斷的可能性較小。

?Segment文件讀取，通常使用sendfile系統(tǒng)調(diào)用來實現(xiàn)零拷貝讀取和發(fā)送，減少數(shù)據(jù)在用戶空間與內(nèi)核空間之間的拷貝次數(shù)，提高數(shù)據(jù)傳輸?shù)男省?/p>

1.4 關鍵技術(shù)

Kafka 作為高性能的消息中間件，其超高吞吐量的核心秘訣之一就是深度依賴 PageCache + 順序 I/O + mmap 內(nèi)存映射的組合。

PageCache，中文名稱為頁高速緩沖存儲器。它是將磁盤上的數(shù)據(jù)加載到內(nèi)存中，當系統(tǒng)需要訪問這些數(shù)據(jù)時，可以直接從內(nèi)存中讀取，而不必每次都去讀取磁盤。這種方式顯著減少了磁盤I/O操作，從而提高了系統(tǒng)性能。

mmap（Memory-mapped file）是操作系統(tǒng)提供的一種將磁盤文件與進程虛擬地址空間建立映射關系的核心技術(shù)，本質(zhì)是讓進程通過直接操作內(nèi)存地址的方式讀寫文件，無需傳統(tǒng)的 read/write 系統(tǒng)調(diào)用。核心價值在于零拷貝和內(nèi)存式文件訪問，尤其適合大文件、高吞吐、隨機訪問的場景。

將日志段（.log）文件映射到內(nèi)存，生產(chǎn)者寫入時直接寫內(nèi)存（內(nèi)核異步刷盤），消費者讀取時直接從內(nèi)存讀取，實現(xiàn)超高吞吐（Kafka 的 “順序?qū)?+ mmap” 是其高性能核心）；

??

零拷貝流程示意圖

零拷貝過程：

1.用戶進程發(fā)起sendfile系統(tǒng)調(diào)用，上下文（切換1）從用戶態(tài)轉(zhuǎn)向內(nèi)核態(tài)

2.DMA控制器，把數(shù)據(jù)從硬盤中拷貝到內(nèi)核緩沖區(qū)。

3.CPU將讀緩沖區(qū)中數(shù)據(jù)拷貝到socket緩沖區(qū)

4.DMA控制器，異步把數(shù)據(jù)從socket緩沖區(qū)拷貝到網(wǎng)卡，

5.上下文（切換2）從內(nèi)核態(tài)切換回用戶態(tài)，sendfile調(diào)用返回。

1.5 設計優(yōu)勢

?順序?qū)懘疟P：Segment 文件僅追加寫入，規(guī)避隨機 IO，吞吐量極高（單分區(qū)可達 10 萬 + TPS）??

?索引輕量化：僅維護偏移量與時間戳索引，降低存儲開銷?

?副本同步：基于 ISR 機制，僅同步已提交消息，兼顧一致性與可用性

二、RocketMQ存儲架構(gòu)

Kafka的每個Partition都是一個完整的、順序?qū)懭氲奈募擯artition數(shù)量增多時，從操作系統(tǒng)的角度看，這些寫入操作會變得相對隨機，這可能會影響寫入性能。

2.1 核心存儲模型：分離式設計

RocketMQ采用「CommitLog + ConsumeQueue + IndexFile」三層結(jié)構(gòu)，徹底分離數(shù)據(jù)存儲與索引查詢：?

?CommitLog：全局單一日志文件（默認 1GB / 個，循環(huán)覆蓋），存儲所有主題的原始消息??

?ConsumeQueue：按主題 - 隊列維度拆分的索引文件，存儲「消息物理地址 + 偏移量 + 長度」，供消費者快速查詢?

?IndexFile：哈希索引文件，支持按消息 Key 查詢

CommitLog：消息的原始日記本

CommitLog是RocketMQ存儲消息的物理文件，所有消息都會按到達順序?qū)懭脒@個文件。你可以把它想象成一本不斷追加的日記本——每條消息都是按時間順序記錄的新日記。

// 消息存儲的核心邏輯簡化示例（非源碼）
publicvoidputMessage(Message message){
 // 1. 將消息序列化為字節(jié)數(shù)組
 byte[] data = serialize(message);
 // 2. 計算消息物理偏移量
 longoffset = commitLog.getMaxOffset();
 // 3. 將數(shù)據(jù)追加到CommitLog文件末尾
   commitLog.append(data);
 // 4. 返回消息的全局唯一物理偏移量
  returnoffset;
}

消息寫入CommitLog時有三個關鍵特性：

1.順序?qū)懭?/strong>：所有消息按到達順序追加到文件末尾，避免磁盤隨機尋址

0000000000000000000（文件1，1GB） 
2|--消息A(offset=0) 
3|--消息B(offset=100) 
4|--消息C(offset=200) 
500000000001073741824（文件2，起始偏移量1073741824） 

1| CommitLog Offset (8字節(jié)) |Message Size (4字節(jié))| Tag Hashcode (8字節(jié)) |

TopicA-Queue0的ConsumeQueue 
2|--0（對應CommitLog偏移0的消息A） 
3|--100（對應CommitLog偏移100的消息B） 
4|--200（對應CommitLog偏移200的消息C）

// 索引構(gòu)建過程簡化示意
publicvoidbuildIndex(Message message){
 // 計算Key的hash值
 inthash = hash(message.getKey());
 // 定位到對應的Slot槽位
 intslotPos = hash % slotNum;
 // 在Index區(qū)域追加新條目
  indexFile.addEntry(hash, message.getCommitLogOffset());
}