• ConsumeQueue： 這是邏輯隊(duì)列索引文件。每個(gè)Topic下的每個(gè)MessageQueue都對(duì)應(yīng)一個(gè)ConsumeQueue文件。它并不存儲(chǔ)消息本體，而是存儲(chǔ)消息在CommitLog中的物理偏移量（CommitLog Offset）、消息大小和Tag哈希碼。消費(fèi)者實(shí)際是通過(guò)ConsumeQueue來(lái)定位到CommitLog中的具體消息。這種索引與數(shù)據(jù)分離的設(shè)計(jì)，既保證了寫的順序性，又支持了消費(fèi)的隨機(jī)讀。

• IndexFile： 提供基于Key（Message Key或Unique Key）的消息查詢索引服務(wù)，用于支持按Key查找消息。

1. 刷盤機(jī)制： 保證消息持久化的可靠性。

• 同步刷盤： Producer發(fā)送消息后，Broker會(huì)等待數(shù)據(jù)持久化到磁盤后才返回成功ACK。可靠性最高，但性能有損耗。

• 異步刷盤： Producer發(fā)送消息后，Broker將消息寫入Page Cache后就返回成功，由后臺(tái)線程定期將數(shù)據(jù)刷入磁盤。性能高，但在Broker宕機(jī)且未刷盤時(shí)可能丟失少量消息。

1. 主從復(fù)制（HA）： 保證服務(wù)的高可用性。

• Broker分為Master和Slave角色。Master負(fù)責(zé)處理所有讀寫請(qǐng)求，Slave則從Master同步數(shù)據(jù)，提供只讀服務(wù)和故障時(shí)的備份。

• 同步復(fù)制： Master等待Slave存儲(chǔ)成功后才返回Producer寫入成功。數(shù)據(jù)零丟失，但延遲增加。

• 異步復(fù)制： Master寫入成功后立即返回，數(shù)據(jù)異步復(fù)制到Slave。性能好，但主備有短暫不一致風(fēng)險(xiǎn)。

三、 核心原理：消息處理

1. 生產(chǎn)與發(fā)送：
Producer通過(guò)查詢NameServer獲取目標(biāo)Topic的路由信息（分布在哪些Broker的哪些Queue上），采用內(nèi)置的負(fù)載均衡策略（如輪詢）選擇一個(gè)MessageQueue進(jìn)行發(fā)送。支持同步發(fā)送、異步發(fā)送和單向發(fā)送三種模式，以滿足不同場(chǎng)景下的性能與可靠性需求。

1. 消費(fèi)模式：

• 集群消費(fèi)（Clustering）： 一條消息只會(huì)被同一個(gè)Consumer Group中的一個(gè)消費(fèi)者消費(fèi)。這是默認(rèn)模式，用于實(shí)現(xiàn)負(fù)載均衡。

* 廣播消費(fèi)（Broadcasting）： 一條消息會(huì)被發(fā)送到同一個(gè)Consumer Group中的所有消費(fèi)者。
Consumer支持推（Push）模式和拉（Pull）模式。Push模式由Broker主動(dòng)推送（底層仍是Consumer定時(shí)Pull），實(shí)時(shí)性更好；Pull模式由Consumer主動(dòng)控制，靈活性更高。

3. 消息重試與死信隊(duì)列：
消費(fèi)失敗的消息會(huì)根據(jù)重試策略（如延時(shí)等級(jí)）被重新投遞。經(jīng)過(guò)最大重試次數(shù)（默認(rèn)16次）后仍失敗的消息，會(huì)被投遞到該Consumer Group對(duì)應(yīng)的死信隊(duì)列（Dead-Letter Queue） 中，供后續(xù)人工處理。

四、 存儲(chǔ)支持服務(wù)

1. NameServer的路由管理：
Broker會(huì)定期向所有NameServer注冊(cè)自己的路由信息（Topic配置、隊(duì)列信息等）。Producer和Consumer客戶端定時(shí)從NameServer拉取最新的路由表，并緩存本地。當(dāng)Broker宕機(jī)或上下線時(shí)，NameServer能感知并更新路由，客戶端下次拉取時(shí)即可發(fā)現(xiàn)，實(shí)現(xiàn)了動(dòng)態(tài)的服務(wù)發(fā)現(xiàn)與故障轉(zhuǎn)移。

1. 消息過(guò)濾：

• Tag過(guò)濾： 在Consumer端進(jìn)行，基于ConsumeQueue中存儲(chǔ)的Tag哈希碼進(jìn)行快速過(guò)濾，是最高效的方式。

• SQL92表達(dá)式過(guò)濾： 在Broker端進(jìn)行，根據(jù)用戶發(fā)送消息時(shí)設(shè)置的屬性（Properties）進(jìn)行過(guò)濾，功能更強(qiáng)大但消耗更多Broker CPU資源。

3. 事務(wù)消息：
提供類似XA的分布式事務(wù)功能，通過(guò)“半消息（Half Message）”、“本地事務(wù)執(zhí)行狀態(tài)檢查”和“消息回查”機(jī)制，確保本地事務(wù)與消息發(fā)送的最終一致性。

4. 定時(shí)/延時(shí)消息：
通過(guò)預(yù)設(shè)的延時(shí)等級(jí)，消息會(huì)被存儲(chǔ)在特定的延時(shí)Topic隊(duì)列中，由定時(shí)任務(wù)服務(wù)在到期后將其投遞到目標(biāo)Topic，從而被消費(fèi)者消費(fèi)。

****
RocketMQ通過(guò)CommitLog順序?qū)懪cConsumeQueue索引讀分離的存儲(chǔ)架構(gòu)，奠定了其高吞吐量的基礎(chǔ)；通過(guò)靈活的刷盤與復(fù)制策略，在性能與可靠性之間取得平衡；再輔以NameServer的輕量級(jí)路由、豐富的消息處理模式（集群/廣播、過(guò)濾、事務(wù)、延時(shí)）以及完善的重試與死信機(jī)制，共同構(gòu)成了一個(gè)功能完備、穩(wěn)定可靠的分布式消息系統(tǒng)，能夠滿足現(xiàn)代互聯(lián)網(wǎng)應(yīng)用在異步解耦、削峰填谷、數(shù)據(jù)同步等場(chǎng)景下的嚴(yán)苛需求。