RocketMQ源码分析(十三)之ConsumeQueue

最新推荐文章于 2026-04-04 00:00:03 发布
原创 最新推荐文章于 2026-04-04 00:00:03 发布 · 755 阅读 · 0 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
收录于
RocketMQ源码分析

当前文章被收录于：

RocketMQ源码分析
21 篇文章 13 人学习

RocketMQ源码分析

订阅专栏 查看详情
本文深入分析RocketMQ的ConsumeQueue，包括其作为索引文件的角色、消息加载与恢复过程、消息追加以及ReputMessageService和CommitLogDispatcher的工作原理。ConsumeQueue的每个实例对应一个queueId，存储格式为20B，包含消息的offset等信息，用于消费者定位CommitLog中的原始消息。

文章目录

版本

  1. 基于rocketmq-all-4.3.1版本

ConsumeQueue

  1. 每个ConsumeQueue都有一个queueId，queueId 的值为0到TopicConfig配置的队列数量。比如某个Topic的消费队列数量为4，那么四个ConsumeQueue的queueId就分别为0、1、2、3。

  2. ConsumerQueue相当于CommitLog的索引文件，消费者消费时会先从ConsumerQueue中查找消息在CommitLog中的offset，再去CommitLog中找原始消息数据。如果某个消息只在CommitLog中有数据，没在ConsumerQueue中， 则消费者无法消费

  3. Consumequeue类对应的是每个topic和queuId下面的所有文件.默认存储路径是**$HOME/store/consumequeue/{topic}/{queueId}/{fileName}，每个文件由30w条数据组成，单个文件的大小是30w x 20Byte**

  4. 每一个ConsumeQueue存储的格式为commitLogOffset(8B)+size(4B)+tagHashCode(8B),总共20B。存tag是为了在Consumer取到消息offset后先根据tag做一次过滤，剩下的才需要到CommitLog中取消息详情

  5. ConsumeQueue核心属性

    public class ConsumeQueue {
   private final DefaultMessageStore defaultMessageStore;
   //映射文件队列，管理ConsumeQueue
   private final MappedFileQueue mappedFileQueue;
   // 消息topic
   private final String topic;
   // 消息队列Id
   private final int queueId;
   //指定大小的缓冲，记录的大小是20byte的固定大小
   private final ByteBuffer byteBufferIndex;
   //保存的路径
   private final String storePath;
   //映射文件的大小
   private final int mappedFileSize;
   //最后一个消息对应的物理偏移量  也就是在CommitLog中的偏移量
   private long maxPhysicOffset = -1;
   //最小的逻辑偏移量 在ConsumeQueue中的最小偏移量
   private volatile long minLogicOffset = 0;
   //ConsumeQueue的扩展文件
   private ConsumeQueueExt consumeQueueExt = null;
}

  6. 构造方法

    public ConsumeQueue(
    final String topic,
    final int queueId,
    final String storePath,
    final int mappedFileSize,
    final DefaultMessageStore defaultMessageStore) {
    this.storePath = storePath;
    this.mappedFileSize = mappedFileSize;
    this.defaultMessageStore = defaultMessageStore;

    this.topic = topic;
    this.queueId = queueId;
    //存储路径${this.storePath}/{topic}/{queueId}/{fileName}
    String queueDir = this.storePath
        + File.separator + topic
        + File.separator + queueId;

    this.mappedFileQueue = new MappedFileQueue(queueDir, mappedFileSize, null);
    //分配一个存储单元大小（20B）的缓冲区
    this.byteBufferIndex = ByteBuffer.allocate(CQ_STORE_UNIT_SIZE);
    //是否启用消息队列的扩展存储
    if (defaultMessageStore.getMessageStoreConfig().isEnableConsumeQueueExt()) {
        this.consumeQueueExt = new ConsumeQueueExt(
            topic,
            queueId,
            StorePathConfigHelper.getStorePathConsumeQueueExt(defaultMessageStore.getMessageStoreConfig().getStorePathRootDir()),
            defaultMessageStore.getMessageStoreConfig().getMappedFileSizeConsumeQueueExt(),
            defaultMessageStore.getMessageStoreConfig().getBitMapLengthConsumeQueueExt()
        );
    }
}

加载(load)

  1. Broker启动时，调用load加载ConsumeQueue。加载直接委托mappedFileQueue进行加载

    public boolean load() {
    boolean result = this.mappedFileQueue.load();
    log.info("load consume queue " + this.topic + "-" + this.queueId + " " + (result ? "OK" : "Failed"));
    //扩展存储存在则加载
    if (isExtReadEnable()) {
        result &= this.consumeQueueExt.load();
    }
    return result;
}

恢复(recover)

  1. Broker启动时会尝试恢复ConsumeQueue文件。

    • 如果文件个数大于3个就从倒数第三个文件开始恢复，否则从第一个开始
    • 循环遍历文件中的的所有数据，按照20个字节读取。知道全部读取完成
    • 删除有效offset之后的文件

  2. 源码

    public void recover() {
    final List<MappedFile> mappedFiles = this.mappedFileQueue.getMappedFiles();
    if (!mappedFiles.isEmpty()) {
        //如果文件列表大于3就从倒数第3个开始，否则从第一个开始
        int index = mappedFiles.size() - 3;
        if (index < 0)
            index = 0;
        //获取consumeQueue单个文件的大小
        int mappedFileSizeLogics = this.mappedFileSize;
        //获取index对应的映射文件
        MappedFile mappedFile = mappedFiles.get(index);
        ByteBuffer byteBuffer = mappedFile.sliceByteBuffer();
        //映射文件的起始偏移量（也是文件名）
        long processOffset = mappedFile.getFileFromOffset();
        long mappedFileOffset = 0;
        long maxExtAddr = 1;
        while (true) {
            //遍历文件中的所有数据（20个字节一次遍历）
            for (int i = 0; i < mappedFileSizeLogics; i += CQ_STORE_UNIT_SIZE) {
                long offset = byteBuffer.getLong();
                int size = byteBuffer.getInt();
                long tagsCode = byteBuffer.getLong();
                //顺序解析，每个数据单元隔20个字节,如果offset跟size大于0则表示有效
                if (offset >= 0 && size > 0) {
                    //正常数据的大小
                    mappedFileOffset = i + CQ_STORE_UNIT_SIZE;
                    //设置最大的物理偏移量
                    this.maxPhysicOffset = offset;
                    if (isExtAddr(tagsCode)) {
                        maxExtAddr = tagsCode;
                    }
                } else {
                    log.info("recover current consume queue file over,  " + mappedFile.getFileName() + " "
                        + offset + " " + size + " " + tagsCode);
                    break;
                }
            }
            //文件加载完毕
            if (mappedFileOffset == mappedFileSizeLogics) {
                index++;
                // 完成加载跳出循环
                if (index >= mappedFiles.size()) {

                    log.info("recover last consume queue file over, last mapped file "
                        + mappedFile.getFileName());
                    break;
                } else {
                    //下一个文件，继续循环读取
                    mappedFile = mappedFiles.get(index);
                    byteBuffer = mappedFile.sliceByteBuffer();
                    processOffset = mappedFile.getFileFromOffset();
                    mappedFileOffset = 0;
                    log.info("recover next consume queue file, " + mappedFile.getFileName());
                }
            } else {
                log.info("recover current consume queue queue over " + mappedFile.getFileName() + " "
                    + (processOffset + mappedFileOffset));
                break;
            }
        }
        // 最后一个文件的起始偏移量+正常数据的长度
        processOffset += mappedFileOffset;
        //设置flush和commit偏移量位置
        this.mappedFileQueue.setFlushedWhere(processOffset);
        this.mappedFileQueue.setCommittedWhere(processOffset);
        //删除有效的 offset 之后的文件（后面的是无效的，需要删除掉）
        this.mappedFileQueue.truncateDirtyFiles(processOffset);
        //如果有扩展文件，则恢复扩展文件
        if (isExtReadEnable()) {
            this.consumeQueueExt.recover();
            log.info("Truncate consume queue extend file by max {}", maxExtAddr);
            this.consumeQueueExt.truncateByMaxAddress(maxExtAddr);
        }
    }
}

追加分发的消息（putMessagePositionInfoWrapper）

  1. 分发的消息通过putMessagePositionInfoWrapper方法追加

    • 判断消息队列是否可写，是否开启写ConsumeQueue扩展文件默认false
    • 将消息写入缓存区MappedFile中
    • 如果追加成功，则更新checkpoint的时间戳

  2. putMessagePositionInfoWrapper源码

    public void putMessagePositionInfoWrapper(DispatchRequest request) {
    final int maxRetries = 30;
    //判断ConsumeQueue是否可写
    boolean canWrite = this.defaultMessageStore.getRunningFlags().isCQWriteable();
    for (int i = 0; i < maxRetries && canWrite; i++) {
        long tagsCode = request.getTagsCode();
        //是否开启写ConsumeQueue扩展文件，默认false
        //bloom过滤器先记录消息的bitMap，这样consumer来读取消息时先通过bloom过滤器判断是否有符合过滤条件的消息
        if (isExtWriteEnable()) {
            ConsumeQueueExt.CqExtUnit cqExtUnit = new ConsumeQueueExt.CqExtUnit();
            cqExtUnit.setFilterBitMap(request.getBitMap());
            cqExtUnit.setMsgStoreTime(request.getStoreTimestamp());
            cqExtUnit.setTagsCode(request.getTagsCode());

            long extAddr = this.consumeQueueExt.put(cqExtUnit);
            if (isExtAddr(extAddr)) {
                tagsCode = extAddr;
            } else {
                log.warn("Save consume queue extend fail, So just save tagsCode! {}, topic:{}, queueId:{}, offset:{}", cqExtUnit,
                    topic, queueId, request.getCommitLogOffset());
            }
        }
        //写入缓冲区
        boolean result = this.putMessagePositionInfo(request.getCommitLogOffset(),
            request.getMsgSize(), tagsCode, request.getConsumeQueueOffset());
        //如果更新成功，则更新checkpoint文件
        if (result) {
            this.defaultMessageStore.getStoreCheckpoint().setLogicsMsgTimestamp(request.getStoreTimestamp());
            return;
        } else {
            // XXX: warn and notify me
            log.warn("[BUG]put commit log position info to " + topic + ":" + queueId + " " + request.getCommitLogOffset()
                + " failed, retry " + i + " times");

            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                log.warn("", e);
            }
        }
    }

    // XXX: warn and notify me
    log.error("[BUG]consume queue can not write, {} {}", this.topic, this.queueId);
    this.defaultMessageStore.getRunningFlags().makeLogicsQueueError();
}

private boolean putMessagePositionInfo(final long offset, final int size, final long tagsCode,
    final long cqOffset) {

    //maxPhysicOffset记录了上一次ConsumeQueue更新的消息在CommitLog中的偏移量
    // 如果消息已经被处理，则直接返回true
    if (offset <= this.maxPhysicOffset) {
        return true;
    }

    this.byteBufferIndex.flip();
    //20byte
    this.byteBufferIndex.limit(CQ_STORE_UNIT_SIZE);
    this.byteBufferIndex.putLong(offset);//写入消息偏移量
    this.byteBufferIndex.putInt(size);//写入消息长度
    this.byteBufferIndex.putLong(tagsCode);//写入tag hashcode
    //cqOffset为ConsumerQueue中记录了偏移量总数
    final long expectLogicOffset = cqOffset * CQ_STORE_UNIT_SIZE;
    //获取ConsumeQueue当前对应的MappedFile，ConsumeQueue本身也是通过MappedFileQueue来管理的
    MappedFile mappedFile = this.mappedFileQueue.getLastMappedFile(expectLogicOffset);
    if (mappedFile != null) {
        //对于新建的文件，填充0来预热PageCache
        if (mappedFile.isFirstCreateInQueue() && cqOffset != 0 && mappedFile.getWrotePosition() == 0) {
            this.minLogicOffset = expectLogicOffset;
            this.mappedFileQueue.setFlushedWhere(expectLogicOffset);
            this.mappedFileQueue.setCommittedWhere(expectLogicOffset);
            this.fillPreBlank(mappedFile, expectLogicOffset);
            log.info("fill pre blank space " + mappedFile.getFileName() + " " + expectLogicOffset + " "
                + mappedFile.getWrotePosition());
        }

        if (cqOffset != 0) {
            long currentLogicOffset = mappedFile.getWrotePosition() + mappedFile.getFileFromOffset();
            //说明已经处理过
            if (expectLogicOffset < currentLogicOffset) {
                log.warn("Build  consume queue repeatedly, expectLogicOffset: {} currentLogicOffset: {} Topic: {} QID: {} Diff: {}",
                    expectLogicOffset, currentLogicOffset, this.topic, this.queueId, expectLogicOffset - currentLogicOffset);
                return true;
            }

            if (expectLogicOffset != currentLogicOffset) {
                LOG_ERROR.warn(
                    "[BUG]logic queue order maybe wrong, expectLogicOffset: {} currentLogicOffset: {} Topic: {} QID: {} Diff: {}",
                    expectLogicOffset,
                    currentLogicOffset,
                    this.topic,
                    this.queueId,
                    expectLogicOffset - currentLogicOffset
                );
            }
        }
        //更新物理偏移量，追加到MappedFile。如果appendMessage追加失败了,等下次继续追加，所以这里可以直接给maxPhysicOffset赋值，不用关心是否追加成功
        this.maxPhysicOffset = offset;
        return mappedFile.appendMessage(this.byteBufferIndex.array());
    }
    return false;
}

private void fillPreBlank(final MappedFile mappedFile, final long untilWhere) {
    ByteBuffer byteBuffer = ByteBuffer.allocate(CQ_STORE_UNIT_SIZE);
    byteBuffer.putLong(0L);
    byteBuffer.putInt(Integer.MAX_VALUE);
    byteBuffer.putLong(0L);

    int until = (int) (untilWhere % this.mappedFileQueue.getMappedFileSize());
    for (int i = 0; i < until; i += CQ_STORE_UNIT_SIZE) {
        mappedFile.appendMessage(byteBuffer.array());
    }
}

ReputMessageService

  1. ReputMessageService是一个服务线程，用于ConsumeQueue持久化，它是DefaultMessageStore的内部类。此服务线程主要运行doReput方法。每间隔1ms执行一次

    public void run() {
    DefaultMessageStore.log.info(this.getServiceName() + " service started");

    while (!this.isStopped()) {
        try {
            Thread.sleep(1);
            this.doReput();
        } catch (Exception e) {
            DefaultMessageStore.log.warn(this.getServiceName() + " service has exception. ", e);
        }
    }

    DefaultMessageStore.log.info(this.getServiceName() + " service end");
}

  2. doReput大致步骤

    • 获取CommitLog在reputFromOffset处存储的可以被处理的消息（可能在不同的MappedFile中）
    • 循环遍历这些消息，并将每个消息相关数据转换为DispatchRequest
    • 分发DispatchRequest到CommitLogDispatcher中执行

  3. doReput流程图
    在这里插入图片描述

CommitLogDispatcher

  1. CommitLogDispatcher是CommitLog日志消息分发器，主要用来生成ConsumerQueue和IndexFile。此接口有三个实现

    • CommitLogDispatcherBuildConsumeQueue 处理ConsumeQueue的生成
    • CommitLogDispatcherBuildIndex处理IndexFile的生成
    • CommitLogDispatcherCalcBitMap 处理计算bit Map

  2. CommitLogDispatcherBuildConsumeQueue源码。只处理TRANSACTION_NOT_TYPE和TRANSACTION_COMMIT_TYPE这两种消息。这两种消息一种是非事务消息，即普通消息。一种是事务已经确切提交的消息

    class CommitLogDispatcherBuildConsumeQueue implements CommitLogDispatcher {

    @Override
    public void dispatch(DispatchRequest request) {
        final int tranType = MessageSysFlag.getTransactionValue(request.getSysFlag());
        switch (tranType) {
            case MessageSysFlag.TRANSACTION_NOT_TYPE:
            case MessageSysFlag.TRANSACTION_COMMIT_TYPE:
                DefaultMessageStore.this.putMessagePositionInfo(request);
                break;
            case MessageSysFlag.TRANSACTION_PREPARED_TYPE:
            case MessageSysFlag.TRANSACTION_ROLLBACK_TYPE:
                break;
        }
    }
}
public void putMessagePositionInfo(DispatchRequest dispatchRequest) {
    //根据主题与队列获取对应的ConsumeQueue
    ConsumeQueue cq = this.findConsumeQueue(dispatchRequest.getTopic(), dispatchRequest.getQueueId());
    cq.putMessagePositionInfoWrapper(dispatchRequest);
}
标签
#RocketMQ源码 #ConsumeQueue
RocketMQ ConsumeQueue（消费队列）
LZJLZJLZJLZJLZJLZJ的专栏
04-09 5715
目录说明ConsumerQueue建立过程ConsumerQueue文件结构总结 说明 RocketMQ对新消息是顺序存在MapperFile上，但不同的Consumer需要订阅不同topic的数据，针对不同的Consumer，如果从原始数据进行数据拉取，这样效率非常低，有可能扫描完所有的MapperFile后，只有几条消息可供消费的。RocketMQ为了解决这种问题，引入了ConsumeQueue消费队列的概念：针对每一条消息，都会按topic和queueId进行分类。Consumer进行拉取消息时，Br
RocketMQ架构篇 - 读写队列与生产者如何选择队列
The Secret
03-06 2909
本文解析RocketMQ的读写队列与生产者如何选择队列。
【RocketMQ】RocketMq之ConsumeQueue深入研究
gorgor在码农
02-08 1258
RocketMQ的存储文件分为CommitLog、ConsumerQueue和IndexFile。ConsumeQueue记录消息在CommitLog中的索引，每个条目20字节，包含CommitLog Offset、Message Length和Tag HashCode。写入时，消息先写入CommitLog，再由ReputMessageService异步构建到ConsumeQueue。查询时，消费者通过逻辑偏移量查询ConsumeQueue，获取物理偏移量后从CommitLog读取消息。
RocketMQ详解
m0_48811221的博客
04-01 3252
RocketMQ 简介 如图所示为RocketMQ基本的部署结构，主要分为NameServer集群、Broker集群、Producer集群和Consumer集群四个部分。 大致流程： Broker在启动的时候会去向NameServer注册并且定时发送心跳，Producer在启动的时候会到NameServer上去拉取Topic所属的Broker具体地址，然后向具体的Broker发送消息 为了消除单点故障，增加可靠性或增大吞吐量，可以在多台机器上部署多个nameserver和broker，并且为每个broke
RocketMQ ConsumeQueue 消费队列文件
金甲虫的博客
03-01 3158
1. 概述 1.1 ConsumeQueue 是什么 ConsumeQueue，又称作消费队列，是 RocketMQ 存储系统的一部分，保存在磁盘中。 该文件可以看作 CommitLog 关于消息消费的“索引”文件。 ConsumeQueue 是一个 MappedFileQueue，即每个文件大小相同的内存映射文件队列。每个文件由大小和格式相同的索引项构成。 每一个 Topic 的 Queue，都对应一个 ConsumeQueue。 1.2 ConsumeQueue 的作用 引入 ConsumeQueue
RocketMQ源码分析之构建consumequeue及index
不爱学习的小妞博客
12-29 850
在《RocketMQ源码分析之消息写入》中提到RocketMQ中引入consumequeue和index的原因，本篇文章将围绕consumequeue和index中记录了什么信息以及如何构建consumequeue和index文件来展开。 首先我们先回顾下为什么要在RocketMQ中引入consumequeue和index。RocketMQ中所有topic的消息都存储在同一个文件中，这样虽然提高了消息发送及写入的性能及吞吐量，但是在RocketMQ中消息消费是基于topic消息订阅机制，这样便会给consu
RocketMQ存储之ConsumeQueue
feijianke666的博客
08-03 1107
一、功能概述 ConsumeQueue作为RocketMQ存储实现的重要部分，它提供了每个Topic下每个Queue中消息存储的索引功能。也就是说，每个Topic下的每个Queue都会有一个ConsumeQueue保存该Queue下消息存储在CommitLog的位置。 ConsumeQueue和CommitLog一样，都是基于MappedFileQueue实现的。所以ConsumeQueue和CommitLog的实现有很多相似的地方。本篇我们只会分析ConsumeQueue的一些比较核心的功能实现，其他内容
rocketmq中重试源码分析_RocketMQ源码分析之ConsumeQueue
weixin_31304499的博客
02-06 296
一：前言上周末写了两篇文章讲到服务端Broker在收到消息后是如何存储消息的：《RocketMQ源码分析之消息存储》《RocketMQ源码分析之消息刷盘》但是除了负责存储消息之外，Broker还要负责创建消费队列。关于消费队列，其实在讲消息发送的时候《RocketMQ源码分析之消息发送》，我就画过一张简单的图。每个 Topic 在Broker 端都会有多个消费队列，Producer每次都会选择一个...
【RocketMQ 存储】CommitLogDispatcherBuildConsumeQueue 构建 ConsumeQueue 索引
Jwasx的博客
02-16 970
【RocketMQ 存储】- RocketMQ存储类 MappedFile【RocketMQ 存储】- 一文总结 RocketMQ 的存储结构-基础【RocketMQ 存储】- broker 端存储单条消息的逻辑【RocketMQ 存储】- broker 端存储批量消息的逻辑【RocketMQ 存储】- 同步刷盘和异步刷盘【RocketMQ 存储】- 同步刷盘服务 GroupCommitService【RocketMQ 存储】- 异步刷盘服务 FlushRealTimeService。
RocketMQ 源码分析 08 根据commitLog转发consumequeue和indexFile
郭传志的博客
10-02 801
RocketMQ 存储机制回顾 本文主要从源码的角度分析 Rocketmq 消费队列 ConsumeQueue 物理文件的构建与存储结构，同时分析 RocketMQ 索引文件IndexFile 文件的存储原理、存储格式以及检索方式。RocketMQ 的存储机制是所有的主题消息都存储在 CommitLog 文件中，也就是消息发送是完全的顺序 IO 操作，加上利用内存文件映射机制，极大的提供的 IO...
【RocketMQ | 源码分析】ConsumeQueue与IndexFile更新
MarcoLin
05-01 383
前面我们介绍了消息是如何存储的，消息是如何刷盘的，讲的都是CommitLog是如何存储和刷盘的。虽然CommitLog顺序存储着所有消息，但是CommitLog中的消息并没有区分topic、keys等，如果需要消费某个topic的消息或者查找某一条消息只能遍历CommitLog文件去查找，性能相当低下，因此有了ConsumeLog和IndexFile两个文件类型，这两个文件的作用主要是提升消息消费和查询的性能。
rocketmq核心源码分析第十四篇一消息处理第八部分一commitlog以及consumequeue数据格式
小麒麟的博客
02-02 1189
文章目录源码分析一AppendMessageCallback.doAppendcommitlog消息体格式commitlog_consumequeue一图解![在这里插入图片描述](https://img-blog.csdnimg.cn/e315675e459e4566a4162f064b5a5a6c.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5bKB5pyI5Lq6,size_20,color_
RocketMQ源码分析----ConsumeQueue介绍和其构建过程
菜鸟一名
04-06 1165
废话 很久没写过看过RocketMQ源码了，就刚开始用MQ的时候，顺便看了下源码，由于当时水平较差，写了几篇文章，现在感觉真JB乱….有种想重新写的冲动(￣▽￣) 所以从这篇文章开始估计会有好些内容是重复的 正文 了解过RocketMQ的原理或者看过我第一篇RocketMQ文章的应该知道ConsumeQueue是CommitLog的一个索引，查找消息的时候会先去ConsumeQueue获取o...
RocketMQ源码分析 broker启动，commitlog、consumequeue、indexfile、MappedFileQueue、MappedFile之间的关系以及位置说明
https://www.cnblogs.com/zhangyjblogs/
11-14 1510
1.MappedFile类属性说明 dubbo的核心是spi，看懂了spi那么duboo基本上也懂了，对于rmq来说，它的核心是broker，而broker的核心是commitlog、consumequeue、indexfile，而这些文件对应的最终都是MappedFile，那么搞明白了这个类，那么对于broker的存储这块也就很容易明白了 1.1.MappedFile类属性如下 OS_PA...
8. 源码分析之ConsumeQueue
努力学习
11-30 623
源码分析之ConsumeQueue 消息发送时数据在ConsumeQueue的落地 ​ 连续发送5条消息，消息是不定长，首先所有信息先放入 Commitlog中，每一条消息放入Commitlog的时候都需要上锁，确保顺序的写入。 ​ 当Commitlog写成功了之后。数据再同步到ConsunmeQueue中。 ​ 并且数据一条条分发，这个是一个典型的轮询。 ​ Queue Offset 代表一个Queue中的第几条消息 ​ Logic Offset就是Queue Offset*20 因为每一条Consum
RocketMQ 源码分析 —— Message 存储
油墨香^-^的博客
12-09 1062
RocketMQ存储架构采用"分而治之"设计理念，通过CommitLog、ConsumeQueue和IndexFile三类文件实现高性能消息存储。核心流程包括：消息顺序写入CommitLog文件，异步构建ConsumeQueue索引，以及按需构建IndexFile。关键技术点包括内存映射(MappedFile)、读写分离、异步刷盘机制(同步/异步两种模式)和异常恢复机制。存储设计充分考虑了高性能(顺序写)、高可靠(刷盘与主从复制)、高吞吐和低延迟等目标，通过分层架构实现消息的快速写入与高
从源码分析RocketMQ系列-RocketMQ消息持久化源码详解
初学者
04-08 7227
导语   上次对于Producer发送消息，追踪到了org.apache.rocketmq.remoting.netty.NettyRemotingClient类中的invokeAsync()方法，并没有继续深入的去深究这个方法的具体实现以及后续的逻辑，这篇博客就来分析一下后续的逻辑。   在之前的时候提到过一个类org.apache.rocketmq.client.impl.MQClient...
03 RocketMQ - Broker 源码分析
刘元雄
09-02 977
03 RocketMQ - Broker 源码分析
RocketMQ 存储原理：CommitLog 与 ConsumeQueue 设计
最新发布
m0_57877510的博客
04-04 429
基于源码深度解析，RocketMQ 存储原理：CommitLog 与 ConsumeQueue 设计
详解RocketMQ消息存储原理
热门推荐
听得到微笑的博客
10-15 1万+
RocketMQ存储的文件主要包括CommitLog文件、ConsumeQueue文件、Index文件。RocketMQ将所有topic的消息存储在同一个文件中，确保消息发送时按顺序写文件，尽最大的能力确保消息发送的高性能与高吞吐量。因为消息中间件一般是基于消息主题的订阅机制，所以给按照消息主题检索消息带来了极大的不便。为了提高消息消费的效率，RocketMQ引入了ConsumeQueue消息消费队列文件，每个topic包含多个消息消
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值