通过这三个文件彻底搞懂rocketmq的存储原理

前言

RocketMQ是阿里开发的一个高性能的消息队列，支持各种消息类型，而且支持事务消息，可以说是现在的很多系统中的香饽饽了，所以呢，怎么使用大家肯定是要学习的

我们作为一个有梦想的程序员，在学习一门技术的时候，肯定是不能光知其然，这是远远不够的，我们必须要知其所以然，这样才能在面试的时候侃侃而谈，啊呸，不对，这样我们才能在工作中遇到问题的时候，理性的去思考如何解决问题

我们知道RocketMQ的架构是producer、NameServer、broker、Consumer，producer是生产消息的，NameServer是路由中心，负责服务的注册发现以及路由管理这些。

Consumer是属于消费消息的，broker则属于真正的存储消息，以及进行消息的持久化，也就是存储消息的文件和索引消息的文件都在broker上

消息队列的主要作用是解耦异步削峰，也就意味着消息队列中的存储功能是必不可少的，而随着时代的发展，业务量的增加也对消息队列的存储功能的强度的要求越来越高了

也就是说你不能光性能好，你得存储的消息也得足够支撑我的业务量，你只能存储100MB的消息，我这系统每分钟的消息业务量可能500MB了，那肯定不够使啊，那还削个啥的峰啊，峰来了你自己都顶不住

RocketMQ凭借其强大的存储能力和强大的消息索引能力，以及各种类型消息和消息的特性脱颖而出，于是乎，我们这些有梦想的程序员学习RocketMQ的存储原理也变得尤为重要

而要说起这个存储原理，则不得不说的就是RocketMQ的消息存储文件commitLog文件，消费方则是凭借着巧妙的设计Consumerqueue文件来进行高性能并且不混乱的消费，还有RocketMQ的强大的支持消息索引的特性，靠的就是indexfile索引文件

我们这篇文章就从这commitLog、Consumerqueue、indexfile这三个神秘的文件说起，搞懂这三个文件，RocketMQ的核心就被你掏空了

先上个图，写入commitLog文件时commitLog和Consumerqueue、indexfile文件三者的关系

Commitlog文件

大小和命名规则

RocketMQ中的消息存储文件放在${ROCKET_HOME}/store 目录下，当生产者发送消息时，broker会将消息存储到Commit文件夹下，文件夹下面会有一个commitLog文件，但是并不是意味着这个文件叫这个，文件命名是根据消息的偏移量来决定的

文件有自己的生成规则，每个commitLog文件的大小是1G，一般情况下第一个 CommitLog 的起始偏移量为 0，第二个 CommitLog 的起始偏移量为 1073741824 （1G = 1073741824byte）。

也正是因为该文件的文件名字规则，所以也可以更好的知道消息处于哪个文件中，假设物理偏移量是1073741830，则相对的偏移量是6（6 = 1073741830 - 1073741824），于是判断出该消息位于第二个commitLog文件上，下面要说的Consumerqueue文件和indexfile文件都是通过偏移量来计算出消息位于哪个文件，进行更为精准的定位，减少了IO次数

文件存储规则和特点

commitLog文件的最大的一个特点就是消息的顺序写入，随机读写，关于commitLog的文件的落盘有两种，一种是同步刷盘，一种是异步刷盘，可通过 flushDiskType 进行配置

在写入commitLog的时候内部会有一个mappedFile内存映射文件，消息是先写入到这个内存映射文件中，然后根据刷盘策略写到硬盘中，对于producer的角度来说就是，同步就是当消息真正的写到硬盘的时候才会给producer返回成功，而异步就是当消息到达内存的时候就返回成功了，然后异步的去刷盘

跑题了，最大的特点顺序写入，所有的topic的消息都存储到commitLog文件中，顺序写入可以充分的利用磁盘顺序减少了IO争用数据存储的性能，kafka也是通过硬盘顺序存盘的

大家都常说硬盘的速度比内存慢，其实这句话也是有歧义的，当硬盘顺序写入和读取的时候，速度不比内存慢，甚至比内存速度快，这种存储方式就好比数组，我们如果知道数组的下标，则可以直接通过下标计算出位置，找到内存地址，众所周知，数组的读取是很快的，但是数组的缺点在于插入数据比较慢，因为如果在中间插入数据需要将后面的数据往后移动

而对于数组来说，如果我们只会顺序的往后添加，数组的速度也是很快的，因为数组没有后续的数据的移动，这一操作很耗时

回到RocketMQ中的commitLog文件，也是同样的道理，顺序的写入文件也就不需要太多的去考虑写入的位置，直接找到文件往后放就可以了，而取数据的时候，也是和数组一样，我们可以通过文件的大小去精准的定位到哪一个文件，然后再精准的定位到文件的位置

当然，至于这个索引位置就是靠下面的Consumerqueue文件和indexfile文件来找到消息的位置的，也就是索引地址

哦对了，数组的元素大小是一样的，并不意味这commitLog文件的各个消息存储空间一样

简单看下源码

这部分源码在DefaultMessageStore.putMessage

  @Override
    public PutMessageResult putMessage(MessageExtBrokerInner msg) {
   
        if (this.shutdown) {
   
            log.warn("message store has shutdown, so putMessage is forbidden");
            return new PutMessageResult(PutMessageStatus.SERVICE_NOT_AVAILABLE, null);
        }

        // 从节点不允许写入
        if (BrokerRole.SLAVE == this.messageStoreConfig.getBrokerRole()) {
   
            long value = this.printTimes.getAndIncrement();
            if ((value % 50000) == 0) {
   
                log.warn("message store is slave mode, so putMessage is forbidden ");
            }

            return new PutMessageResult(PutMessageStatus.SERVICE_NOT_AVAILABLE, null);
        }

        // store是否允许写入
        if (!this.runningFlags.isWriteable()) {
   
            long value = this.printTimes.getAndIncrement();
            if ((value % 50000) == 0) {
   
                log.warn("message store is not writeable, so putMessage is forbidden " + this.runningFlags.getFlagBits());
            }

            return new PutMessageResult(PutMessageStatus.SERVICE_NOT_AVAILABLE, null);
        } else {
   
            this.printTimes.set(0);
        }

        // topic过长
        if (msg.getTopic().length() > Byte.MAX_VALUE) {
   
            log.warn("putMessage message topic length too long " + msg.getTopic().length());
            return new PutMessageResult(PutMessageStatus.MESSAGE_ILLEGAL, null);
        }

        // 消息附加属性过长
        if (msg.getPropertiesString() != null && msg.getPropertiesString().length() > Short.MAX_VALUE) {
   
            log.warn("putMessage message properties length too long " + msg.getPropertiesString().length());
            return new PutMessageResult(PutMessageStatus.PROPERTIES_SIZE_EXCEEDED, null);
        }

        if (this.isOSPageCacheBusy()) {
   
            return new PutMessageResult(PutMessageStatus.OS_PAGECACHE_BUSY, null);
        }

        long beginTime = this