RocketMQ如何高效应对高并发下的消息持久化？

上篇文章我们分析完RocketMQ发送消息的原理， 得到后来啊客户端会通过RPC组件向Broker进行通信

Broker收到请求后需要将消息进行持久化，一旦涉及到持久化，服务器的性能会急速下降，甚至出现卡顿、掉帧的现象！消费者在读取磁盘时也会被迫慢下来简直是“血泪史”。

先说说那些神奇的文件：CommitLog、 ConsumerQueue、IndexFile

Broker提供三套文件来满足高并发下的持久化需求：，这事儿我得说道说道。

• CommitLog——顺序写入的大肥肉文件。
• ConsumerQueue——二级索引的“小碎片”。
• IndexFile——哈希索引，像是给消息装上了GPS。

深得我心。 为了避免写入时产生巨大的IO开销， RocketMQ干脆把所有Topic和队列的消息都塞进同一个CommitLog里顺序写、顺序读，省得每次都去找“哪儿”。

CommitLog 的命名哲学

踩个点。 CommitLog 文件以起始偏移量命名， 每个文件固定 1GB：

00000000000000000000
00000000001073741824
00000000002147483648
……

这些文件在源码里叫 MappedFile用的是 mmap所以写入几乎没有拷贝开销。 实不相瞒... 可别小看它们，一个 MappedFile 就相当于一块“大块头”。

ConsumerQueue：二级索引的灵魂伴侣

ConsumerQueue 按 Topic 分一级， 再按队列 ID 分二级， 拭目以待。 每个文件大小固定 6MB，记录长度只有 20B：

• 8B —— CommitLog 偏移量。
• 4B —— 消息体大小。
• 8B —— Tag 哈希，用于过滤。