RocketMQ 消息存储

消息存储

  主要的存储文件:

  1、消息文件(commitLog)

  2、消息消费队列文件(consumeQueue)

  3、Hash索引文件(IndexFile)

  4、检测点文件(checkpoint)

  5、关闭异常文件(abort)

文件刷盘机制

  RocketMQ的存储与读写是基于JDK NIO的内存映射机制(MappedByteBuffer)的,消息存储时首先将消息追加到内存,再根据配置的刷盘策略在不同时间进行刷写磁盘。

  同步刷写:消息追加到内存后,立即将内存消息刷写到磁盘,再对客户端进行应答。

  异步刷写:消息追加到内存后,先应答客户端,再使用线程按照设定的频率将内存刷写到磁盘上。(默认的刷写机制)

过期文件删除机制

  因:所有的写操作都在最后一个文件(CommitLog,ConsumeQueue)上,之前的文件在下一个文件创建完成后将不会再被更新。

  果:清除文件的方法是:如果非当前文件在一定时间间隔内没有再次被更新,则认为是过期文件,可以被删除。

待补充:消息的消费具体工作方式。

原文地址:https://www.cnblogs.com/chen--biao/p/10166546.html

时间: 2024-10-13 08:24:54

RocketMQ 消息存储的相关文章

再说rocketmq消息存储

rocketmq通过netty获取到消息请求后,直接掉处理模块,比如:SendMessageProcessor 这个处理类主要负责处理客户端发送消息的请求. 这个类实现了com.alibaba.rocketmq.remoting.netty.NettyRequestProcessor接口.这个接口下一共两个方法: RemotingCommand processRequest(ChannelHandlerContext ctx, RemotingCommand request) throws Ex

RocketMQ高性能原理(pushConsumer,CommitLog,ZeroCopy)

1. Rocketmq消费模型(实时性) 常见的数据同步方式有这几种: push:producer发送消息后,broker马上把消息投递给consumer.这种方式好在实时性比较高,但是会增加broker的负载:而且消费端能力不同,如果push推送过快,消费端会出现很多问题. pull:producer发送消息后,broker什么也不做,等着consumer自己来读取.它的优点在于主动权在消费者端,可控性好:但是间隔时间不好设置,间隔太短浪费资源,间隔太长又会消费不及时. 长轮询:当consum

Java和操作系统交互细节

结合 CPU 理解一行 Java 代码是怎么执行的根据冯·诺依曼思想,计算机采用二进制作为数制基础,必须包含:运算器.控制器.存储设备,以及输入输出设备,如下图所示.我们先来分析 CPU 的工作原理,现代 CPU 芯片中大都集成了,控制单元,运算单元,存储单元.控制单元是 CPU 的控制中心, CPU 需要通过它才知道下一步做什么,也就是执行什么指令,控制单元又包含:指令寄存器(IR ),指令译码器( ID )和操作控制器( OC ). 当程序被加载进内存后,指令就在内存中了,这个时候说的内存是

你需要知道的RoketMQ

1.概述 本篇文章会尽力全面的介绍RocketMQ和Kafka各个关键点的比较,希望大家读完能有所收获. RocketMQ前身叫做MetaQ, 在MeataQ发布3.0版本的时候改名为RocketMQ,其本质上的设计思路和Kafka类似,但是和Kafka不同的是其使用Java进行开发,由于在国内的Java受众群体远远多于Scala,所以RocketMQ是很多以Java语言为主的公司的首选.同样的RocketMQ和Kafka都是Apache基金会中的顶级项目,他们社区的活跃度都非常高,项目更新迭代

RocketMQ源码学习--消息存储篇

1.序言 今天来和大家探讨一下RocketMQ在消息存储方面所作出的努力,在介绍RocketMQ的存储模型之前,可以先探讨一下MQ的存储模型选择. 2.MQ的存储模型选择 个人看来,从MQ的类型来看,存储模型分两种: 需要持久化(ActiveMQ,RabbitMQ,Kafka,RocketMQ) 不需要持久化(ZeroMQ) 本篇文章主要讨论持久化MQ的存储模型,因为现在大多数的MQ都是支持持久化存储,而且业务上也大多需要MQ有持久存储的能力,能大大增加系统的高可用性,下面几种存储方式: 分布式

(转)RocketMQ源码学习--消息存储篇

http://www.tuicool.com/articles/umQfMzA 1.序言 今天来和大家探讨一下RocketMQ在消息存储方面所作出的努力,在介绍RocketMQ的存储模型之前,可以先探讨一下MQ的存储模型选择. 2.MQ的存储模型选择 个人看来,从MQ的类型来看,存储模型分两种: 需要持久化(ActiveMQ,RabbitMQ,Kafka,RocketMQ) 不需要持久化(ZeroMQ) 本篇文章主要讨论持久化MQ的存储模型,因为现在大多数的MQ都是支持持久化存储,而且业务上也大

深入理解RocketMQ(四)--消息存储

一.MQ存储分类 文件系统:RocketMQ/Kafka/RabbitMQ 关系型数据库DB:ActiveMQ(默认采用的KahaDB做消息存储)可选用JDBC的方式来做消息持久化 分布式KV存储:ZeroMQ 对比: 存储效率, 文件系统>分布式KV存储>关系型数据库DB 易于实现和快速集成,关系型数据库DB>分布式KV存储>文件系统,但是性能会下降很多 二.RocketMQ存储概要 (一)存储文件 rocketmq |--store |-commitlog |      |-0

分布式开放消息系统(RocketMQ)的原理与实践

分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性以及其实现原理 一.顺序消息 消息有序指的是可以按照消息的发送顺序来消费.例如:一笔订单产生了 3 条消息,分别是订单创建.订单付款.订单完成.消费时,要按照顺序依次消费才有意

RocketMQ与Kafka对比(18项差异)

转自:https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafka 淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件,使用Mysql作为消息存储媒介,可完全水平扩容,为了进一步降低成本,我们认为存储部分可以进一步优化,2011年初,Linkin开源了Kafka这个优秀的消息中间件,淘宝中间件团队在对Kafka做过充分Review之后,Kafka无限消息堆积,高效的持久化速度吸引了我们,但是同时发现这个消息系统主要定位于日志传输,对于使用在