请描述 Apache RocketMQ 的消息存储架构，包括其存储文件布局、写入路径、刷盘机制以及消息索引的组织方式，并说明它们如何协同工作以支持高吞吐和可靠性。
考察说明
考查对 RocketMQ 存储引擎核心机制的理解，包括文件组织、写入流程、刷盘策略和索引构建。
回答思路
- 【回答框架 1】RocketMQ 采用混合存储模型，消息主体和索引分开：消息内容顺序追加到 CommitLog 文件，所有主题都共用一个 CommitLog，避免随机写。每个存储文件大小固定（默认 1GB），通过 MappedFile 映射内存，写入时从文件尾部追加。
- 【回答框架 2】索引存储包括 ConsumeQueue 和 IndexFile。ConsumeQueue 按主题和队列维度组织，记录消息在 CommitLog 中的物理偏移、大小和 tag hash，用于消费拉取；IndexFile 提供按消息 key 的查询能力。两者都是基于 CommitLog 间接构建，保证了写入顺序性。
- 【回答框架 3】写入路径：Broker 收到消息后，先获取写锁，在 CommitLog 找到当前 MappedFile，通过追加方式写入，成功后返回确认。通过 group commit 批量刷盘，减少 fsync 调用次数。刷盘策略可选同步刷盘或异步刷盘，同步刷盘在消息追加后立即落盘并返回，异步刷盘则允许短暂延迟。
- 【回答框架 4】高可用方面，Master 和 Slave 之间通过同步复制或异步复制同步数据。同步复制要求 Slave 确认后才返回，可靠性更高但延迟增加；异步复制吞吐更高但可能丢失少量数据。存储模块还提供过期文件删除和磁盘空间预分配机制，避免运行中磁盘满。
- 【关键点 1】消息顺序写入 CommitLog，避免磁盘随机写，是高性能的基础。
- 【关键点 2】ConsumeQueue 和 IndexFile 作为二级索引，基于 CommitLog 异步构建，支撑消费和 key 查询。
- 【关键点 3】刷盘策略可在同步和异步之间配置，影响可靠性与吞吐的平衡。
- 【关键点 4】同步复制与异步复制决定了 Master 返回时数据是否已同步到 Slave。
- 【易错点 1】不要将同步刷盘等同于同步复制，两者位于不同协议层。
- 【易错点 2】消息存储不包含业务去重，重复消费需要应用层保证幂等。
- 【易错点 3】默认 1GB 文件大小是配置值，实际可通过参数调整。