2.內(nèi)存映射：通過MappedByteBuffer實(shí)現(xiàn)文件映射，減少數(shù)據(jù)拷貝次數(shù)

3.文件分割：單個CommitLog文件默認(rèn)1GB，寫滿后創(chuàng)建新文件（文件名用起始偏移量命名）

舉個例子，當(dāng)生產(chǎn)者發(fā)送三條消息時，CommitLog文件可能長這樣：

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

溫馨提示：雖然CommitLog是順序?qū)?，但讀取時需要配合索引結(jié)構(gòu)，否則遍歷文件找消息就像大海撈針。

消費(fèi)隊(duì)列ConsumeQueue：消息的快速目錄

如果每次消費(fèi)都要掃描CommitLog，性能會慘不忍睹。于是RocketMQ設(shè)計(jì)了ConsumeQueue——它是基于Topic和Queue的二級索引文件。

每個ConsumeQueue條目包含三個關(guān)鍵信息（固定20字節(jié)）：

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

這相當(dāng)于給CommitLog里的消息做了一個目錄：

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

當(dāng)消費(fèi)者拉取TopicA-Queue0的消息時：

1.先查ConsumeQueue獲取消息的物理位置

2.根據(jù)CommitLog Offset直接定位到CommitLog文件

3.讀取指定位置的消息內(nèi)容

關(guān)鍵設(shè)計(jì)點(diǎn)：

?ConsumeQueue采用內(nèi)存映射+異步刷盤，保證高性能

?單個文件存儲30萬條索引，約5.72MB（30萬*20字節(jié)）

?通過hashCode快速過濾Tag，實(shí)現(xiàn)消息過濾

索引文件IndexFile：消息的全局字典

如果需要根據(jù)MessageID或Key查詢消息，ConsumeQueue就不夠用了。這時候就要用到IndexFile這個全局索引。

IndexFile的結(jié)構(gòu)類似HashMap：

1.Slot槽位（500萬個）：存儲相同hash值的Index條目鏈表頭

2.Index條目（2000萬條）：包含Key的hash值、CommitLog偏移量、時間差等信息

當(dāng)寫入消息時：

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

查詢時通過兩次查找快速定位：

1.根據(jù)Key的hash值找到Slot槽位

2.遍歷Slot對應(yīng)的鏈表，比對CommitLog中的實(shí)際Key值

性能優(yōu)化必知：

?消息體積差異大時，CommitLog仍然保持順序?qū)懀獵onsumeQueue可能出現(xiàn)「稀疏索引」（相鄰索引指向的物理位置間隔大）

?生產(chǎn)環(huán)境中CommitLog建議放在單獨(dú)SSD磁盤，ConsumeQueue和IndexFile可放普通磁盤

?遇到消息堆積時，優(yōu)先檢查消費(fèi)者速度，而不是無腦擴(kuò)容Broker存儲

理解這些底層機(jī)制，下次遇到消息查詢性能問題或者磁盤IO瓶頸時，就知道該從CommitLog的寫入模式還是ConsumeQueue的索引結(jié)構(gòu)入手排查了。

2.2 數(shù)據(jù)流轉(zhuǎn)機(jī)制

?生產(chǎn)者寫入 CommitLog，生成全局唯一偏移量（PHYOFFSET）?

?后臺線程異步構(gòu)建 ConsumeQueue 索引，同步消息元數(shù)據(jù)?

?消費(fèi)者通過 ConsumeQueue 定位 CommitLog 中的消息，避免全量掃描

存儲過程全景圖

現(xiàn)在把各個模塊串起來看消息的生命周期：

1.生產(chǎn)者發(fā)送消息到Broker

2.Broker將消息順序?qū)懭隒ommitLog

3.異步線程同時構(gòu)建ConsumeQueue和IndexFile

4.消費(fèi)者通過ConsumeQueue快速定位消息

5.按需查詢IndexFile實(shí)現(xiàn)消息回溯

整個過程就像圖書館的管理系統(tǒng)：

?CommitLog是藏書庫（按入庫時間擺放）

?ConsumeQueue是分類目錄（按題材/出版社分類）

?IndexFile是檢索電腦（支持按書名/作者查詢）

2.4 設(shè)計(jì)優(yōu)勢

?讀寫分離：CommitLog 僅負(fù)責(zé)寫入，ConsumeQueue 負(fù)責(zé)查詢，提升并發(fā)性能?

?事務(wù)支持：通過 CommitLog 中的事務(wù)狀態(tài)標(biāo)記 + 回查機(jī)制，實(shí)現(xiàn)分布式事務(wù)消息?

?刷盤策略：支持「異步刷盤（高吞吐）」「同步刷盤（金融級可靠性）」動態(tài)切換

三、JMQ存儲架構(gòu)

JMQ的消息存儲分別參考了Kafka和RocketMQ存儲設(shè)計(jì)上優(yōu)點(diǎn)，并根據(jù)京東內(nèi)部的應(yīng)用場景進(jìn)行了改進(jìn)和創(chuàng)新。

3.1 核心存儲模型：分區(qū)日志 + 隊(duì)列兼容

??

JMQ存儲的基本單元是PartitionGroup。在同一個Broker上，每個PartitionGroup對應(yīng)一組消息文件（Journal Files），順序存放這個Topic的消息。

與Kafka類似，每個Topic包含若干Partition，每個Partition對應(yīng)一組索引文件（Index Files），索引中存放消息在消息文件中的位置和消息長度。消息寫入時，收到的消息按照對應(yīng)的PartitionGroup寫入依次追加寫入消息文件中，然后異步創(chuàng)建索引并寫入對應(yīng)Partition的索引文件中。

以PartionGroup為基本存儲單元的設(shè)計(jì)，在兼顧靈活性的同時，具有較好的性能，并且單個PartitionGroup可以支持更多的并發(fā)。

3.2 消息讀/寫過程

??

寫消息：

JMQ的寫操作使用DirectBuffer作為緩存，數(shù)據(jù)先寫入DirectBuffer，再異步通過FileChannel寫入到文件中。

?消息寫入DirectBuffer后，默認(rèn)寫入該節(jié)點(diǎn)成功（數(shù)據(jù)的高可靠是通過Raft協(xié)議復(fù)制，用多個內(nèi)存副本來保證），相對Kafka的寫操作來看，JMQ響應(yīng)寫入請求的處理過程沒有發(fā)生系統(tǒng)調(diào)用，在京東內(nèi)部的大量單條同步發(fā)送的場景下開銷更低、性能更優(yōu)。

?同時也避免使用MappedByteBuffer（Mmap方式）產(chǎn)生Page Fault中斷，OS在中斷中將該頁對應(yīng)磁盤中的數(shù)據(jù)拷貝到內(nèi)存中，在對文件進(jìn)行追加寫入的情況下，這一無法避免的過程是完全沒有必要，反而增加了寫入的耗時的問題。

讀消息：

JMQ采用定長稠密索引設(shè)計(jì)，每個索引固定長度。

?定長設(shè)計(jì)的好處是，直接根據(jù)索引序號就可以計(jì)算出索引在文件中的位置：索引位置 = 索引序號 * 索引長度。這樣，消息的查找過程就比較簡單了，首先計(jì)算出索引所在的位置，直接讀取索引，然后根據(jù)索引中記錄的消息位置讀取消息。

?在京東內(nèi)部應(yīng)用場景中，單條消息處理耗時高是比較常見的，微服務(wù)架構(gòu)下用戶一般會申請更多的消費(fèi)節(jié)點(diǎn)，讓每個消費(fèi)節(jié)點(diǎn)單次拉取較小批量的消息進(jìn)行處理，以提升消費(fèi)并行度，這樣消費(fèi)拉取請求的次數(shù)會比較多，稠密索引的設(shè)計(jì)會更適用內(nèi)部的應(yīng)用場景。

JMQ消費(fèi)讀操作99%以上都能命中緩存（JMQ設(shè)計(jì)的堆外內(nèi)存與文件映射的一種緩存機(jī)制），避免了Kafka可能遇到的Cache被污染，影響性能和吞吐的問題。同時直接讀內(nèi)存也規(guī)避了RocketMQ在讀取消息存儲的日志數(shù)據(jù)文件時容易產(chǎn)生較多的隨機(jī)訪問讀取磁盤，影響性能的問題。（當(dāng)沒有命中緩存時，會默認(rèn)降級為通過Mmap的方式讀取消息）。

四、競品對比分析

在單副本場景下，JMQ與Kafka的單機(jī)寫入性能均十分出色，均可達(dá)到網(wǎng)絡(luò)帶寬上限。

然而，在更貼近生產(chǎn)環(huán)境的三副本場景中，兩者特性出現(xiàn)分化：

JMQ在三副本異步寫入下的極限吞吐優(yōu)勢明顯，且在跨機(jī)房部署時，其同步寫入性能表現(xiàn)良好，幾乎不受網(wǎng)絡(luò)延遲影響；而Kafka則在多分區(qū)同步寫入場景下展現(xiàn)出更穩(wěn)定的性能，衰減小于JMQ。在大部分異步吞吐場景及不同消息體下的性能趨勢上，兩者表現(xiàn)相當(dāng)。

綜上所述，JMQ尤其適合對同步寫入性能和副本異步吞吐有極高要求的場景，而Kafka在復(fù)雜分區(qū)的高并發(fā)同步寫入方面適應(yīng)性更廣。

審核編輯 黃宇