本文共 1338 字，大约阅读时间需要 4 分钟。
RocketMQ的消息存储结构与Kafka存在显著差异，理解这一点有助于更好地掌握其工作机制。本文将详细阐述RocketMQ的核心存储逻辑。
RocketMQ采用双层存储架构：即CommitLog和ConsumerQueue。这里 CommitLog 负责存储消息的高 متحده数据，而 ConsumerQueue 则负责维护消息的位置信息。这种设计充分利用了磁盘的顺序写优化能力，确保数据存储效率。
CommitLog 实际上是一个日志文件，默认大小不超过1GB，超过后会切换到新文件继续存储。每条消息在存储过程中需要经过多个步骤才能完成落地：
消息编码：消息会被拆分为多个固定格式的区块，每个区块包含以下字段：
数据存储：所有信息按固定顺序写入CommitLog文件，确保磁盘IO为顺序执行，提升性能。
ConsumerQueue 旨在维护消息的位置信息，主要包含以下字段：
值得注意的是，RocketMQ并未直接存储消息内容。所有具体消息数据均留存在CommitLog文件中，而ConsumerQueue仅存储消息在存储系统中的位置信息。这与Kafka的存储方式存在显著不同（Kafka直接储存消息内容）。这一设计使得 RocketMQ 的 ConsumerQueue 较小，且能更高效地支持大量 partition。
I/O 顺序：RocketMQ 的 CommitLog 采用顺序I/O，减少磁盘操作成本。相比之下，Kafka采用随机I/O，导致读写性能较低。
消息存储方式：RocketMQ 仅存储消息的位置信息（20字节），而Kafka 则完整储存消息内容。这种差异使 RocketMQ 在单 broker 环境下能支持更多 topic 和 partition。
消息数据大小：由于每条消息仅需存储20字节位置信息，RocketMQ 的 ConsumerQueue 读写效率较高。其通过使用 MappedFile 技术，利用操作系统的内存缓存进一步提升性能。
通过上述分析，可以看出 RocketMQ 的设计理念与 Kafka 有着本质的区别，其核心目标在于平衡存储效率与系统扩展性。了解这一点对于分布式系统的优化选择至关重要。
转载地址：http://ztisz.baihongyu.com/