vlambda博客
学习文章列表

从源码分析rocketmq的存储原理

rocketmq在存储消息的时候,最终是通过mmap映射成磁盘文件进行存储的,本文就消息的存储流程作一个整理。源码版本是4.9.2

主要的存储组件有如下4个:

CommitLog:存储的业务层,接收“保存消息”的请求

MappedFile:存储的最底层对象,一个MappedFile对象就对应了一个实际的文件

MappedFileQueue:管理MappedFile的容器

AllocateMappedFileService:异步创建mappedFile的服务 

对于rocketmq来说,存储消息的主要文件被称为CommitLog,因此就从该类入手。处理存储请求的入口方法是asyncPutMessage,主要流程如下:

public CompletableFuture<PutMessageResult> asyncPutMessage(final MessageExtBrokerInner msg) {
    ...
    //可能会有多个线程并发请求,虽然支持集群,但是对于每个单独的broker都是本地存储,所以内存锁就足够了
    putMessageLock.lock();
    try {
      //获取最新的文件
        MappedFile mappedFile = this.mappedFileQueue.getLastMappedFile();
        ...
        //如果文件为空,或者已经存满,则创建一个新的commitlog文件
        if (null == mappedFile || mappedFile.isFull()) {
            mappedFile = this.mappedFileQueue.getLastMappedFile(0); // Mark: NewFile may be cause noise
        }
        ...
        
//存储消息
        result = mappedFile.appendMessage(msg, this.appendMessageCallback, putMessageContext);
        ...
    } finally {
        putMessageLock.unlock();
    }
    PutMessageResult putMessageResult = new PutMessageResult(PutMessageStatus.PUT_OK, result);
 ...
}

因此对于Commitlog.asyncPutMessage来说,主要的工作就是2步:

1.获取或者创建一个MappedFile 

2.调用appendMessage进行存储

接下去我们先看MappedFile的创建,查看mappedFileQueue.getLastMappedFile方法,最终会调用到doCreateMappedFile方法,调用流如下:

getLastMappedFile-->tryCreateMappedFile-->doCreateMappedFile

protected MappedFile doCreateMappedFile(String nextFilePath, String nextNextFilePath) {
    MappedFile mappedFile = null;
  //如果异步服务对象不为空,那么就采用异步创建文件的方式
    if (this.allocateMappedFileService != null) {
        mappedFile = this.allocateMappedFileService.putRequestAndReturnMappedFile(nextFilePath,
                nextNextFilePath, this.mappedFileSize);
    } else {
     //否则就同步创建
        try {
            mappedFile = new MappedFile(nextFilePath, this.mappedFileSize);
        } catch (IOException e) {
            log.error("create mappedFile exception", e);
        }
    }
    ...
    return mappedFile;
}

因此对于MappedFileQueue来说,主要工作就2步:

1.如果有异步服务,那么就异步创建mappedFile

2.否则就同步创建

接下去主要看异步创建的流程,查看allocateMappedFileService.putRequestAndReturnMappedFile

public MappedFile putRequestAndReturnMappedFile(String nextFilePath, String nextNextFilePath, int fileSize) {
    ...
    //创建mappedFile的请求
    AllocateRequest nextReq = new AllocateRequest(nextFilePath, fileSize);
    //将其放入ConcurrentHashMap中,主要用于并发判断,保证不会创建重复的mappedFile
    boolean nextPutOK = this.requestTable.putIfAbsent(nextFilePath, nextReq) == null;
  //如果map添加成功,就可以将request放入队列中,实际创建mappedFile的线程也是从该queue中获取request
    if (nextPutOK) {
        boolean offerOK = this.requestQueue.offer(nextReq);
    }
 
    AllocateRequest result = this.requestTable.get(nextFilePath);
    try {
        if (result != null) {
          //因为是异步创建,所以这里需要await,等待mappedFile被异步创建成功
            boolean waitOK = result.getCountDownLatch().await(waitTimeOut, TimeUnit.MILLISECONDS);
            //返回创建好的mappedFile
            return result.getMappedFile();
        }
    } catch (InterruptedException e) {
        log.warn(this.getServiceName() + " service has exception. ", e);
    }
    return null;
}

因此对于AllocateMappedFileService.putRequestAndReturnMappedFile,主要工作也是2步:

1.将“创建mappedFile”的请求放入队列中 

2.等待异步线程实际创建完mappedFile

接下去看异步线程是如何具体创建mappedFile的。既然AllocateMappedFileService本身就是负责创建mappedFile的,并且其本身也实现了Runnable接口,我们查看其run方法,其中会调用mmapOperation,这就是最终执行创建mappedFile的方法

private boolean mmapOperation() {
    boolean isSuccess = false;
    AllocateRequest req = null;
    try {
        //从队列中拿request
        req = this.requestQueue.take();
        ...
        if (req.getMappedFile() == null) {
            MappedFile mappedFile;
            //判断是否采用堆外内存
            if (messageStore.getMessageStoreConfig().isTransientStorePoolEnable()) {
                try {
                    //如果开启了堆外内存,rocketmq允许外部注入自定义的MappedFile实现
                    mappedFile = ServiceLoader.load(MappedFile.class).iterator().next();
                    mappedFile.init(req.getFilePath(), req.getFileSize(), messageStore.getTransientStorePool());
                } catch (RuntimeException e) {
                  //如果没有自定义实现,那么就采用默认的实现
                    mappedFile = new MappedFile(req.getFilePath(), req.getFileSize(), messageStore.getTransientStorePool());
                }
            } else {
                //如果未采用堆外内存,那么就直接采用默认实现
                mappedFile = new MappedFile(req.getFilePath(), req.getFileSize());
            }
    ...
            //这里会预热文件,这里涉及到了系统的底层调用
            mappedFile.warmMappedFile(this.messageStore.getMessageStoreConfig().getFlushDiskType(),
                    this.messageStore.getMessageStoreConfig().getFlushLeastPagesWhenWarmMapedFile());
            req.setMappedFile(mappedFile);
        }
        ...
    } finally {
        if (req != null && isSuccess)
            //无论是否创建成功,都要唤醒putRequestAndReturnMappedFile方法中的等待线程
            req.getCountDownLatch().countDown();
    }
    return true;
}

因此对于mmapOperation创建mappedFile,主要工作为4步:

1.从队列中获取putRequestAndReturnMappedFile方法存放的request 

2.根据是否启用堆外内存,分支创建mappedFile 

3.预热mappedFile

4.唤醒putRequestAndReturnMappedFile方法中的等待线程

接下去查看mappedFile内部的具体实现,我们可以发现在构造函数中,也会调用内部的init方法,这就是主要实现mmap的方法

private void init(final String fileName, final int fileSize) throws IOException {
    ...
    //创建文件对象
    this.file = new File(fileName);
    try {
        //获取fileChannel
        this.fileChannel = new RandomAccessFile(this.file, "rw").getChannel();
        //进行mmap操作,将磁盘空间映射到内存
        this.mappedByteBuffer = this.fileChannel.map(MapMode.READ_WRITE, 0, fileSize);
        ...
    } finally {
        ...
    }
}

因此对于init执行mmap,主要工作分为2步:

1.获取文件的fileChannel 

2.执行mmap映射

而如果采用了堆外内存,那么除了上述的mmap操作,还会额外分配内存

this.writeBuffer = transientStorePool.borrowBuffer();

到这里,CommitLog.asyncPutMessage方法中的获取或创建mappedFile就完成了。

接下去需要查看消息具体是符合被写入文件中的。查看mappedFile的appendMessage方法,最终会调用到appendMessagesInner方法:

public AppendMessageResult appendMessagesInner(final MessageExt messageExt, final AppendMessageCallback cb,
                                               PutMessageContext putMessageContext) {
    //如果是启用了堆外内存,那么会优先写入堆外内存,否则直接写入mmap内存
    ByteBuffer byteBuffer = writeBuffer != null ? writeBuffer.slice() : this.mappedByteBuffer.slice();
    byteBuffer.position(currentPos);
    AppendMessageResult result;
    ...
    //调用外部的callback执行实际的写入操作
    result = cb.doAppend(this.getFileFromOffset(), byteBuffer, this.fileSize - currentPos,
           (MessageExtBrokerInner) messageExt, putMessageContext);
    ...
    return result;
}

因此对于appendMessage方法,主要工作分为2步:

1.判断是否启用内存,从而选择对应的buffer对象 

2.调用传入的callback方法进行实际写入

接下去查看外部传入的callback方法,是由CommitLog.asyncPutMessage传入

result = mappedFile.appendMessage(msg, this.appendMessageCallback, putMessageContext);

而this.appendMessageCallback则是在CommitLog的构造函数中初始化的

this.appendMessageCallback = new DefaultAppendMessageCallback(defaultMessageStore.getMessageStoreConfig().getMaxMessageSize());

查看DefaultAppendMessageCallback.doAppend方法,因为本文不关心消息的具体结构,所以省略了大部分构造buffer的代码:

public AppendMessageResult doAppend(final long fileFromOffset, final ByteBuffer byteBuffer, final int maxBlank,
    final MessageExtBrokerInner msgInner, PutMessageContext putMessageContext) {
    ...
    //获取消息编码后的buffer
    ByteBuffer preEncodeBuffer = msgInner.getEncodedBuff();
    ...
    //写入buffer中,如果启用了堆外内存,那么就会写入外部传入的writerBuffer,否则直接写入mappedByteBuffer中
    byteBuffer.put(preEncodeBuffer);
    ...
    return result;
}

因此对于doAppend方法,主要工作分为2步:

1.将消息编码

2.将编码后的消息写入buffer中,可以是writerBuffer或者mappedByteBuffer

此时虽然字节流已经写入了buffer中,但是对于堆外内存,此时数据还仅存在于内存中,而对于mappedByteBuffer,虽然会有系统线程定时刷数据落盘,但是这并非我们可以控,因此也只能假设还未落盘。为了保证数据能落盘,rocketmq还有一个异步刷盘的线程,接下去再来看下异步刷盘是如何处理的。

查看CommitLog的构造函数,其中有3个service,分别负责同步刷盘、异步刷盘和堆外内存写入fileChannel

public CommitLog(final DefaultMessageStore defaultMessageStore) {
    ...
    //同步刷盘
    if (FlushDiskType.SYNC_FLUSH == defaultMessageStore.getMessageStoreConfig().getFlushDiskType()) {
        this.flushCommitLogService = new GroupCommitService();
    } else {
        //异步刷盘
        this.flushCommitLogService = new FlushRealTimeService();
    }
    //将堆外内存的数据写入fileChannel
    this.commitLogService = new CommitRealTimeService();
    ...
}

先看CommitRealTimeService.run方法,其中最关键的代码如下:

boolean result = CommitLog.this.mappedFileQueue.commit(commitDataLeastPages);

查看mappedFileQueue.commit方法,关键如下:

int offset = mappedFile.commit(commitLeastPages);

查看mappedFile.commit方法:

public int commit(final int commitLeastPages) {
  //如果为空,说明不是堆外内存,就不需要任何操作,只需等待刷盘即可
    if (writeBuffer == null) {
        return this.wrotePosition.get();
    }
    if (this.isAbleToCommit(commitLeastPages)) {
        if (this.hold()) {
            //如果是堆外内存,那么需要做commit
            commit0();
            this.release();
        }
        ...
    }
    return this.committedPosition.get();
}

查看commit0方法:

protected void commit0() {
    ...
    //获取堆外内存
    ByteBuffer byteBuffer = writeBuffer.slice();
    //写入fileChannel
    this.fileChannel.write(byteBuffer);
    ...
}

因此对于CommitRealTimeService,工作主要分2步:
1.判断是否是堆外内存,如果不是那就不需要处理
2.如果是对外内存,则写入fileChannel

最后查看同步刷盘的GroupCommitService和异步刷盘FlushRealTimeService,查看其run方法,会发现其本质都是调用了如下方法:

CommitLog.this.mappedFileQueue.flush

当然在处理的逻辑上还有计算position等等逻辑,但这不是本文所关心的,所以就省略了。同步和异步的区别体现在了执行刷盘操作的时间间隔,对于同步刷盘,固定间隔10ms:

this.waitForRunning(10);

而对于异步刷盘,时间间隔为配置值,默认500ms:

int interval = CommitLog.this.defaultMessageStore.getMessageStoreConfig().getFlushIntervalCommitLog();
...
if (flushCommitLogTimed) {
    Thread.sleep(interval);
else {
    this.waitForRunning(interval);
}

最后查看mappedFileQueue.flush是如何刷盘的。最终会调用到mappedFile的flush方法:

public int flush(final int flushLeastPages) {
  ...
    //如果是使用了堆外内存,那么调用的是fileChannel的刷盘
    if (writeBuffer != null || this.fileChannel.position() != 0) {
        this.fileChannel.force(false);
    } else {
    //如果非堆外内存,那么调用的是mappedByteBuffer的刷盘
        this.mappedByteBuffer.force();
    }
    ...       
    return this.getFlushedPosition();
}

因此最终的刷盘,工作主要分2步,正和前面的CommitRealTimeService工作对应:

  1. 如果是使用了堆外内存,那么调用fileChannel的刷盘

  2. 如果非堆外内存,那么调用mappedByteBuffer的刷盘

至此,整个rocketmq消息落盘的流程就完成了,接下去重新整理下整个流程:

1.CommitLog:存储的业务层,接收“保存消息”的请求,主要有2个功能:创建mappedFile、异步写入消息。

2.AllocateMappedFileService:异步创建mappedFile的服务,通过构建AllocateRequest对象和队列进行线程间的通讯。虽然MappedFile的实际创建是通过异步线程执行的,但是当前线程会等待创建完成后再返回,所以实际上是异步阻塞的。

3.MappedFile:存储的最底层对象,一个MappedFile对象就对应了一个实际的文件。在init方法中创建了fileChannel,并完成了mmap操作。如果启用了外内存,则会额外初始化writeBuffer,实现读写分离。

4.MappedFileQueue:管理MappedFile的容器。

5.写入消息的时候,会根据是否启用堆外内存,写入writeBuffer或者mappedByteBuffer。

6.实际落盘是通过异步的线程实现的,分为名义上的同步(GroupCommitService)和异步(FlushRealTimeService),不过主要区别在于执行落盘方法的时间间隔不同,最终都是调用mappedFile的flush方法

7.落盘会根据是否启用堆外内存,分别调用fileChannel.force或者mappedByteBuffer.force