在RocketMQ中，消息存储是由CommitLog和ConsumerQueue配合完成
消息存储结构
首先我们先来看下整体的消息存储结构
基本过程：
- 生产者在生产消息的时候是将消息存储在
CommitLog文件中 - 消费者在读取消息时，先读取 ConsumeQueue，然后再通过ConsumeQueue中的位置信息读取CommitLog文件中具体的消息数据得到原始消息。
这里有两个需要注意的地方，CommitLog和ConsumeQueue结构
CommitLog
可以理解这个其实就是一个日志文件，该文件默认最大为1GB，超过1GB后会轮到下一个CommitLog文件进行存储。通过CommitLog，RocketMQ将所有消息都进行顺序存储，充分利用了磁盘顺序写提高数据存储性能
- 4字节表示消息的长度，消息的长度是整个消息体所占用的字节数的大小
- 4字节的魔数，是固定值，有MESSAGE_MAGIC_CODE和BLANK_MAGIC_CODE
- 4字节的CRC，是消息体的校验码，用于防止网络、硬件等故障导致数据与发送时不一样带来的问题 – 4字节的queueId，表示消息发到了哪个MessageQueue(逻辑上相当于kakka的partition)
- 4字节的flag，flag是创建Message对象时由生产者通过构造器设定的flag值
- 8字节的queueOffset，表示在queue中的偏移量
- 8字节的physicalPosition，表示在存储文件中的偏移量
- 4字节sysFlag，是生产者相关的信息标识，具体生产逻辑可以看相关代码
- 8字节消息创建时间
- 8字节消息生产者的host
- 8字节消息存储时间
- 8字节消息存储的机器的host
- 4字节表示重复消费次数
- 8字节消息事务相关偏移量
- 4字节表示消息体的长度消息休，不是固定长度，和前面的4字节的消息体长度值相等
- 1字节表示topic的长度，因此topc的长度最多不能超过127个字节，超过的话存储会出错（有前置校验）
- Topic，存储topic，因为topic不是固定长度，所以这里所占的字节是不固定的，和前一个表示topic长度的字节的值相等
- 2字节properties的长度，properties是创建消息时添加到消息中的，因此，添加在消息中的poperties不能太多太大，所有的properties的kv对在拼接成string后，所占的字节数不能超过2^15-1
- Properties的内容，也不是固定长度，和前面的2字节properties长度的值相同
ConsumeQueue
Offset：表示在默认1GB的CommitLog文件中的偏移量（位置）Size：表示消息占用的长度tagCode：消息所属的tag的hash值
可以看到一个消息的数据包占用共20个字节，RocketMQ在消息存储上并没有存储具体的消息，而是将具体消息数据存储在CommitLog文件中，这也是和Kafka很大的一个不同点（Kafka中是存储具体消息数据的）
总结
RocketMQ这样的消息存储结构它的优势是什么，接下来我们通过与Kafka对比来看下
写顺序不同：RocketMQ 将所有消息存储在同一个CommitLog中，使得RocketMQ中的消息是磁盘顺序写，顺序IO可以接近内存的速度。而Kafka中在消息存储上是随机IO，随机IO要比顺序IO慢得多- 消息数据存储方式不同：RocketMQ中每个消息仅存储20字节的消息位置信息（原始数据存在CommitLog），而Kafka将每个partition的消息分开存储，因此在单个Broker中RocketMQ能支持更多的topic、partition
消息数据大小不同：在RocketMQ中，ConsumeQueue也是随机IO，但确能比Kafka支持更多的partition，原因是RocketMQ通过MappedFile的方式读写ConsumeQueue，操作系统对内存映射文件有page cache，且一个消息位置数据仅有20字节，一个page中可以包含很多的消息数据，相当于直接对内存随机IO，所以效率要比Kafka高出得多
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/17856.html
