首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >RocketMQ CommitLog 文件规则

RocketMQ CommitLog 文件规则

作者头像
java404
发布于 2018-12-28 07:34:29
发布于 2018-12-28 07:34:29
2.8K00
代码可运行
举报
文章被收录于专栏:java 成神之路java 成神之路
运行总次数:0
代码可运行

1、CommitLog 文件生成规则

偏移量:每个 CommitLog 文件的大小为 1G,一般情况下第一个 CommitLog 的起始偏移量为 0,第二个 CommitLog 的起始偏移量为 1073741824 (1G = 1073741824byte)。

2、怎么知道消息存储在哪个 CommitLog 文件上?

假设 1073742827 为物理偏移量(物理偏移量也即全局偏移量),则其对应的相对偏移量为 1003(1003 = 1073742827 - 1073741824),并且该偏移量位于第二个 CommitLog。

index 和 ComsumerQueue 中都有消息对应的物理偏移量,通过物理偏移量就可以计算出该消息位于哪个 CommitLog 文件上。

3、CommitLog 文件命名规则

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public MappedFile getLastMappedFile(final long startOffset, boolean needCreate) {
    long createOffset = -1;
    MappedFile mappedFileLast = getLastMappedFile();
    // 1、如果 mappedFileLast 为空或者已满,则计算新文件的物理偏移量
    if (mappedFileLast == null) {
        createOffset = startOffset - (startOffset % this.mappedFileSize);
    }

    if (mappedFileLast != null && mappedFileLast.isFull()) {
        createOffset = mappedFileLast.getFileFromOffset() + this.mappedFileSize;
    }

    if (createOffset != -1 && needCreate) {
        // 2、通过物理偏移量获得文件名
        String nextFilePath = this.storePath + File.separator + UtilAll.offset2FileName(createOffset);
        String nextNextFilePath = this.storePath + File.separator
            + UtilAll.offset2FileName(createOffset + this.mappedFileSize);
        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);
            }
        }
        // 省略代码
        ......
}

新创建的 mappedFile 物理偏移量计算

  • 1、如果 mappedFileLast 为空,那么肯定是第一次启动 MQ,那么物理偏移量为0。
  • 2、如果 mappedFileLast 已满,则获取上一个 mappedFile 的起始物理偏移量 + 文件大小。

文件名通过调用UtilAll.offset2FileName(createOffset) 进行获取。

获取文件名
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public static String offset2FileName(final long offset) {
    final NumberFormat nf = NumberFormat.getInstance();
    nf.setMinimumIntegerDigits(20);
    nf.setMaximumFractionDigits(0);
    nf.setGroupingUsed(false);
    return nf.format(offset);
}

可以看出就是根据上一步传入 createOffset 转化成20位的数字字符串。不够20位前面补零。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018.12.26 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
10 张图告诉你 RocketMQ 是怎样保存消息的
首先,在 RocketMQ 集群中创建一个 Topic,叫做 MyTestTopic,配置如下图:
jinjunzhu
2022/12/20
9340
10 张图告诉你 RocketMQ 是怎样保存消息的
从源码剖析RocketMQ如何高效且持久化处理消息
RocketMQ作为消息队列的典型代表,其在高并发状况下处理消息又很不错的性能,同时又能够通过将消息持久化到磁盘确保消息不会丢失,本文旨在从RocketMQ的源码剖析为何它能够高效处理消息,并且又如何高效组织消息并写入磁盘
潋湄
2025/01/09
2550
从源码剖析RocketMQ如何高效且持久化处理消息
RocketMQ 源码分析 —— Message 存储
本文接《RocketMQ 源码分析 —— Message 发送与接收》。主要解析 CommitLog 存储消息部分。
芋道源码
2020/04/28
7280
消息队列中间件 RocketMQ 源码分析 —— Message 存储
1、概述 2、CommitLog 结构 3、CommitLog 存储消息 MappedFile#落盘 FlushRealTimeService CommitRealTimeService GroupCommitService CommitLog#putMessage(...) MappedFileQueue#getLastMappedFile(...) MappedFile#appendMessage(...) DefaultAppendMessageCallback#doAppend(...) Flus
芋道源码
2018/03/02
1.1K0
消息队列中间件 RocketMQ 源码分析 —— Message 存储
源码分析 RocketMQ DLedger(多副本) 之日志追加流程
上一篇我们详细分析了 源码分析RocketMQ多副本之Leader选主,本文将详细分析日志复制的实现。
丁威
2019/09/17
5910
源码分析 RocketMQ DLedger(多副本) 之日志追加流程
RocketMQ 整合 DLedger(多副本)即主从切换实现平滑升级的设计技巧
源码分析 RocketMQ DLedger 多副本即主从切换系列已经进行到第8篇了,前面的章节主要是介绍了基于 raft 协议的选主与日志复制,从本篇开始将开始关注如何将 DLedger 应用到 RocketMQ中。
丁威
2019/10/08
1.1K0
RocketMQ 整合 DLedger(多副本)即主从切换实现平滑升级的设计技巧
消息中间件—RocketMQ消息存储(二)一、RocketMQ存储整体设计架构回顾二、RocketMQ存储关键技术—再谈Mmap与PageCache三、RocketMQ存储优化技术四、RocketMQ
文章摘要:上篇中主要介绍了RocketMQ存储部分的整体架构设计,本篇将深入分析RocketMQ存储部分的细节内容 在本篇文章中,小编将继续深入分析与介绍RocketMQ消息存储部分中的关键技术—Mmap与PageCache、几种RocketMQ存储优化技术(包括预先创建分配MappedFile、文件预热和mlock系统调用)、RocketMQ内部封装类—CommitLog/MappedFile/MappedFileQueue/ConsumeQueue的简析。然后,再简要介绍下RocketMQ消息刷盘两种主要方式。在读完本篇幅后,希望读者能够对RocketMQ消息存储部分有一个更为深刻和全面的认识。
用户2991389
2018/10/10
5.1K3
RocketMQ 存储机制源码解析
producer 发送消息后,broker端开始存储消息,会调用 store 模块的 DefaultMessageStore.putMessage 进行存储消息。
java404
2018/12/28
1.8K0
3分钟白话RocketMQ系列—— 如何存储消息
RocketMQ使用了一种基于日志的存储方式,将消息以顺序写入的方式追加到文件中,从而实现高性能的消息存储和读取。
阿丸笔记
2023/10/22
6190
3分钟白话RocketMQ系列—— 如何存储消息
RocketMQ(三):面对高并发请求,如何高效持久化消息?
上篇文章我们分析完RocketMQ发送消息的原理,得到结果客户端会通过RPC组件向Broker进行通信
菜菜的后端私房菜
2024/09/18
1.3K0
消息的存储-RocketMQ知识体系3
上一篇了解了RocketMQ消息发送,本文开始聊聊消息发送到Broker端后,消息存储相关的逻辑。
DougWang
2021/07/21
5850
RocketMQ存储--日志文件创建与映射流程【源码笔记】
日志目录(可配置)/data/rocketmq/store/commitlog会有20位长度的日志文件。 1.日志文件什么时候创建的? 2.日志文件创建流程是什么? 3.日志文件和内存映射是怎么样的?
瓜农老梁
2019/08/08
1.7K0
RocketMQ存储--日志文件创建与映射流程【源码笔记】
rocketmq原理与实战解析_rocketmq底层原理
Namesrv接收Broker注册的topic信息, namesrv只存内存,但是broker有任务定时推送
全栈程序员站长
2022/09/19
6960
rocketmq原理与实战解析_rocketmq底层原理
RocketMQ
系统的耦合性越高,容错性就越低。以电商应用为例,用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障或者因为升级等原因暂时不可用,都会造成下单操作异常,影响用户使用体验。
JokerDJ
2023/11/27
1.8K0
RocketMQ
深入剖析 RocketMQ 源码 - 消息存储模块
RocketMQ 是阿里巴巴开源的分布式消息中间件,它借鉴了 Kafka 实现,支持消息订阅与发布、顺序消息、事务消息、定时消息、消息回溯、死信队列等功能。RocketMQ 架构上主要分为四部分,如下图所示:
2020labs小助手
2021/11/09
1.5K0
RocketMQ存储--消息追加【源码笔记】
commitLog内存(ByteBuffer)写入位点,标记消息写到哪了,下次从该位置开始写。
瓜农老梁
2019/08/20
1K0
RocketMQ存储--消息追加【源码笔记】
RocketMQ--ConsumeQueue文件与Index文件【源码笔记】
消息消费时先从ConsumeQueue中获取物理偏移量,再根据物理偏移量从commitLog中获取具体消息;消息检索时会用到索引文件,其中值得思考的问题: 1.ConsumeQueue构建流程是怎样的? 2.ConsumeQueue数据结构是怎样的? 3.Index索引文件构建流程怎样的? 4.Index数据结构时怎么样的?
瓜农老梁
2019/08/18
1.5K0
深度解析 RocketMQ 核心组件:ConsumeQueue 的设计与实现
在分布式消息队列 RocketMQ 中,ConsumeQueue(消费队列) 是消息消费的核心组件之一。它作为  CommitLog 的索引机制,帮助消费者快速定位并拉取消息。如果没有 ConsumeQueue,消费者将无法高效地从海量消息中筛选出自己订阅的数据。
腾讯云中间件团队
2025/06/09
970
深度解析 RocketMQ 核心组件:ConsumeQueue 的设计与实现
RocketMQ给broker发送消息确定Commitlog的写入的位置
有一个疑问,当client给broker发送消息的时候,怎么知道在commitlog的第几个字节开始写呢?
CBeann
2023/12/25
2150
RocketMQ给broker发送消息确定Commitlog的写入的位置
云原生中间件RocketMQ-核心原理之消息存储结构解析
从主流的几种MQ消息队列采用的存储方式来看,主要会有三种 分布式KV存储:这种存储方式对于消息读写能力要求不高的情况可以使用,比如ActiveMQ中采用的levelDB。 文件系统存储:这种方案适合对于有高吞吐量要求的消息中间件,因为消息刷盘是一种高效率,高可靠、高性能的持久化方式,除非磁盘出现故障,否则一般是不会出现无法持久化的问题。常见的比如kafka、RocketMQ、RabbitMQ都是采用消息刷盘到所部署的机器上的文件系统来做持久化。 关系型数据库:关系型数据库在单表数据量达到千万级的情况下IO性能会出现瓶颈,比如ActiveMQ可以采用mysql作为消息存储,所以ActiveMQ并不适合于高吞吐量的消息队列场景。 总的来说,对于存储效率,文件系统要优于分布式KV存储,分布式KV存储要优于关系型数据库。
共饮一杯无
2022/11/28
4100
云原生中间件RocketMQ-核心原理之消息存储结构解析
推荐阅读
相关推荐
10 张图告诉你 RocketMQ 是怎样保存消息的
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验