1 介绍

在之前的章节中，我们介绍了消息的发送 和 消息通信 的原理。但是这边有一个比较核心的关键点，那就是如果已经把消息传递给Broker。在Broker在被消费之前，如何保证消息的稳定性，避免消息丢失和数据。
这时候就需要数据持久化数据来进行保障了。
根据之前我们 MQ系列2：消息中间件的技术选型 章节做的分析，RabbitMQ支持 1W+ 级别的吞吐，
Kafka 和 Rocket 支持 10W+ 级别的吞吐，想要实现这么大的吞吐，必须具备一个很强悍的存储功能。下面我们来看看。

2 Broker 存储架构

RocketMQ采用文件存储机制（类似Kafka），即直接在磁盘上使用文件来保存消息，而不是采用Redis或者MySQL之类的持久化工具。
它会把消息存储所属相关的文件存储在ROCKETMQ_HOME下，包含三个部分：

2.1 CommitLog 消息元数据

存储消息的元数据，所有消息都会顺序存入到CommitLog文件中。CommitLog由多个文件组成，每个文件固定大小1G。它有如下特征：

• 单个文件默认大小为1G
• 文件名称长度20，保存偏移量，偏移量不够20位的补0。
  • 如第1个文件没有偏移量，则为：00000000000000000000
  • 第2个文件起始偏移量为1073741824（1G=1073740842），则文件名为 00000000001073741824。
• 第一个1G文件文件写满之后之后转入第2个文件，如此反复，因为是顺序的，所以写入效率较高。

2.2 ConsumeQueue 消息逻辑队列

ConsumeQueue是指存储消息在CommitLog上的索引，一个MessageQueue一个文件，记录当前MessageQueue被哪些消费者组消费到了哪一条CommitLog。它有如下特征：

• ComsumeQueue的结构组成共 20 个字节，包含 8 字节的 commitlog 物理偏移量、4 字节的消息长度、8 字节 tag hashcode
• ConsumeQueue 里只存偏移量信息，内容精悍。加载到内存中，操作效率非常高。
• 一致性保障，CommitLog 里存储了 ConsumeQueues、Message Key、Tag 等所有信息，在 ConsumeQueue 丢失或者故障时候，数据可快速回复。
• 因为每个Topic下可能有多个Queueu，所以存储结构为：HOME/store/consumequeue/{topic}/{queueId}/{fileName}。

2.3 IndexFile 索引文件

IndexFile 是一种可选索引文件，提供了一种可以通过 key 或时间区间来查询消息的方法，并且这种查找消息的方法不影响发送与消费消息的主流程。它的特征如下：

• 算法原理：IndexFile 索引文件的底层实现 为 hash 索引，可以对照 Java 的HashMap比较，通过计算 Key 的 hashcode， 取余获得 hash 槽，并通过拉链法解决哈希冲突。
• 大小限制：IndexFile 以创建时间戳命名，单个 IndexFile 文件大小约为 400M，一个 IndexFile 可以保存 2000W 个索引。

通过上面的三个部件说明可以了解到，RocketMQ 消息存储结构主要是由 CommitLog，ConsumeQueue，IndexFile 三部分组成的。当我们发送消息的时候，会执行如下过程：

• 消息格式化成 CommitLog的字段结构，并按照顺序写入到CommitLog 文件中。
• Broker会按照 ConsumeQueue 的字段结构的要求创建一条索引记录。
• 按需创建IndexFile索引文件。

3 存储的执行过程

通过上面我们已经了解到了，Kafka 和 Rocket 均支持 10W+ 级别的吞吐，那么上述的存储结构是如何保持这样的高超性能的呢？

标签：icode9,NET,性能优化,内存,磁盘混合,网络存储,数据 来源：

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。