RocketMQ Broker是怎么保存数据的呢？

type

status

date

slug

summary

一、RocketMQ Broker 存储架构概述

RocketMQ 的存储系统主要围绕文件系统展开，Broker 将接收到的消息持久化到磁盘中，并通过特定的存储结构和机制确保数据的可靠性与高效访问。RocketMQ 的存储架构可以分为以下几个关键组成部分：

CommitLog：消息的主要存储文件，所有的消息都会首先被写入到 CommitLog 中。

ConsumeQueue：消费队列文件，记录了每个主题（Topic）下每个消息队列（Message Queue）中的消息位置，用于消费者的消息拉取。

IndexFile：索引文件，提供根据消息键值（Key）快速查找消息的能力。

这些文件共同构成了 RocketMQ 的消息存储体系，确保消息能够高效、安全地存储并被快速消费。

二、CommitLog：消息存储的核心

1. CommitLog 的文件结构

CommitLog 是 RocketMQ 消息存储的核心，所有的消息数据都首先被写入到 CommitLog 中。CommitLog 由多个连续的物理文件组成，每个文件的默认大小为 1 GB。当一个文件写满时，系统会自动创建下一个文件，继续写入。

顺序写入：消息以追加的方式顺序写入 CommitLog 文件，这种顺序写盘方式非常高效，能够充分利用磁盘的顺序写性能。

文件命名：CommitLog 文件按照顺序编号进行命名，文件名实际上是文件的起始偏移量。例如，第一个 CommitLog 文件命名为 00000000000000000000，第二个文件名为 00000000001073741824，表示文件起始偏移量为 1073741824 字节。

2. 消息的写入过程

当 Producer 发送一条消息时，Broker 会将这条消息的内容写入到 CommitLog 文件中。写入流程如下：

接收消息：Broker 接收到 Producer 发来的消息后，将消息序列化，并准备写入 CommitLog。

预分配内存：RocketMQ 通过内存映射（Memory-Mapped I/O）技术，将磁盘文件的某个区域映射到内存中，消息将首先写入到这块内存区域。

顺序写盘：消息被顺序写入到内存映射区域，操作系统会在合适的时机将数据刷新到磁盘中，以此完成持久化。

刷盘策略：RocketMQ 提供了同步刷盘和异步刷盘两种策略。同步刷盘在消息写入后立即刷新到磁盘，保证了数据的强一致性；异步刷盘则更注重性能，允许一定的延迟，这种模式下操作系统会在后台自动将数据刷新到磁盘。

3. 消息的读取与重放

读取消息时，RocketMQ 会根据 Consumer 的消费进度，从 CommitLog 中定位到相应的消息偏移量，然后通过内存映射技术直接从磁盘读取消息内容。由于 CommitLog 是顺序写入和顺序读取的，读取操作非常高效，能够满足高并发消息消费的需求。

三、ConsumeQueue：消费队列文件

1. ConsumeQueue 的作用

ConsumeQueue 是 RocketMQ 为每个 Topic 下的每个消息队列（Message Queue）创建的逻辑队列文件。它记录了消息在 CommitLog 中的物理偏移量、消息大小以及消息的标签（Tag）哈希值。ConsumeQueue 的存在使得 Consumer 能够快速定位并读取指定消息，而无需遍历整个 CommitLog。

2. ConsumeQueue 的文件结构

ConsumeQueue 由一系列定长（20 字节）的条目（Entry）组成，每个条目对应于一条消息。一个 ConsumeQueue 文件的大小是固定的（通常为 5.72MB），当文件写满后，系统会自动创建一个新的文件继续写入。

条目结构：每个条目包含以下信息：

消息在 CommitLog 中的物理偏移量（8 字节）
消息大小（4 字节）
消息 Tag 的哈希值（8 字节）

这种设计使得 ConsumeQueue 能够以固定的步长快速进行定位和读取操作。

3. 消息消费流程

消费者（Consumer）在消费消息时，首先会从 ConsumeQueue 中查找消息的偏移量，然后根据偏移量从 CommitLog 中读取实际的消息内容。这个过程极大地提高了消息消费的效率，因为 ConsumeQueue 使得消费者不必遍历整个 CommitLog 文件。

四、IndexFile：索引文件

1. IndexFile 的作用

IndexFile 为 RocketMQ 提供了根据消息的 Key 或者消息的唯一 ID（MsgID）快速查找消息的能力。它通过哈希索引的方式，将消息的键值（Key）映射到 CommitLog 中的物理偏移量，用户可以通过键值快速定位到消息。

2. IndexFile 的文件结构

IndexFile 文件采用散列表（Hash Table）结构，由多个哈希槽（Hash Slot）和哈希条目（Hash Entry）组成：

哈希槽（Hash Slot）：每个哈希槽保存了对应的哈希链表的起始位置。Hash Slot 记录了消息 Key 的哈希值在文件中的位置。

哈希条目（Hash Entry）：每个条目包含消息的 Key 的哈希值、消息在 CommitLog 中的物理偏移量、消息的存储时间戳以及指向下一个哈希条目的指针。

3. 消息查找流程

当用户需要根据 Key 查找消息时，RocketMQ 会计算 Key 的哈希值，并定位到对应的哈希槽，然后顺着哈希链表依次查找匹配的消息。如果找到匹配的 Key，系统会根据记录的 CommitLog 偏移量读取消息内容并返回给用户。

这种哈希索引机制使得 RocketMQ 能够在海量消息中快速定位到指定的消息，极大地提高了消息查询的效率。

五、RocketMQ 的持久化策略

1. 同步刷盘与异步刷盘

RocketMQ 提供了两种刷盘策略，以满足不同业务场景的需求：

同步刷盘：消息写入后立即触发刷盘操作，确保消息实时持久化到磁盘。这种方式提供了最高的可靠性，适用于对数据一致性要求极高的场景。

异步刷盘：消息写入后不会立即触发刷盘，而是由后台线程定期执行刷盘操作。这种方式能够显著提升写入性能，但在系统崩溃时可能会丢失少量未刷盘的消息数据。

2. 数据恢复

RocketMQ 具备数据恢复机制，即使在异常宕机后也能够通过 CommitLog 恢复数据。系统在重启时，会根据 CommitLog 文件的最后一条记录恢复未完成的写入操作，并确保数据的一致性。

六、性能优化与高可用性设计

1. 内存映射技术

RocketMQ 采用内存映射技术（Memory-Mapped I/O）将 CommitLog 文件映射到内存，这使得消息的读写操作都可以直接在内存中进行，而无需频繁访问磁盘，从而大幅提升了系统的 I/O 性能。

2. 批量消息处理

RocketMQ 支持批量消息处理，即多条消息可以在一次磁盘写入操作中被持久化。这种批量写入大幅提高了系统的吞吐量，减少了磁盘 I/O 的开销。

3. 主从同步

为了保证数据的高可用性，RocketMQ 支持主从同步机制。主 Broker 节点将消息写入 CommitLog 后，会异步或同步地将消息同步到从节点（Slave Broker）。在主节点故障时，从节点可以接管服务，保证消息数据不丢失。

七、总结

RocketMQ 作为一款高性能的分布式消息中间件，其 Broker 在数据存储方面进行了诸多优化设计。通过 CommitLog、ConsumeQueue 和 IndexFile 这三大核心组件，RocketMQ 实现了高效的消息存储和检索机制。同时，RocketMQ 通过灵活的刷盘策略、内存映射技术、批量处理和主从同步等手段，进一步提升了系统的性能和高可用性。

这些设计不仅确保了消息的可靠性和一致性，还使得 RocketMQ 能够在高并发、高吞吐量的业务场景中保持卓越的表现。随着业务需求的不断增长，RocketMQ 的存储架构也将继续发展，以应对更大规模的数据处理和存储挑战。