消息存储机制-索引文件及页缓存

对于生产者来说,将消息写到commit log文件里面。这里会有消息的逻辑队列,逻辑队列里面保存了消息的偏移量。

除了consumerquenue之外,它还会将数据分发到另外一个文件叫indexfile索引文件里面。

这个索引文件可以保存消息的一些信息,比如物理的偏移量,消息的键,消息的头。然后还可以通过hash找到消息的位置。

这里面有个非常关键点叫做时间戳。在timestamp时间戳里面,之前在聊kafka的时候说过,kafka也可以根据某个时间点来找到某个消息的偏移量,Rocketmq也具备这种能力。

可以根据某个时间点来找到这个偏移量,在另外一个索引文件IndexFile里面提供了可以搜索数据的地方。

IndexFile

IndexFile(索引⽂件)提供了⼀种可以通过key或时间区间来查询消息的⽅法。
Index⽂件的存储位置是:HOME \\store\\index{fileName},⽂件名fileName是以创建时的时间戳命名的,固定的单个IndexFile⽂件⼤⼩约为400M,⼀个IndexFile可以保存 2000W个索引,IndexFile的底层存储设计为在⽂件系统中实现HashMap结构, 故rocketmq的索引⽂件其底层实现为hash索引。
在上⾯的RocketMQ的消息存储整体架构图中可以看出,RocketMQ采⽤的是混合型的存储结构,即为Broker单个实例下所有的队列共⽤⼀个⽇志数据⽂件(即为 CommitLog)来存储。
RocketMQ的混合型存储结构(多个Topic的消息实体内容都存储于⼀个CommitLog中)针对Producer和Consumer分别采⽤了数据和索引部分相分离的存储结构,Producer发送消息⾄Broker端,然后Broker端使⽤同步或者异步的⽅式对消息刷盘持久化,保存⾄CommitLog中。只要消息被刷盘持久化⾄磁盘⽂件 CommitLog中,那么Producer发送的消息就不会丢失。
正因为如此,Consumer也就肯定有机会去消费这条消息。当⽆法拉取到消息后,可以等下⼀次消息拉取,同时服务端也⽀持⻓轮询模式,如果⼀个消息拉取请求未拉取到消息,Broker允许等待
30s的时间,只要这段时间内有新消息到达,将直接返回给消费端。
这⾥, RocketMQ的具体做法是,使⽤Broker端的后台服务线程---ReputMessageService不停地分发请求并异步构建ConsumeQueue(逻辑消费队列)和IndexFile(索引⽂件) 数据。

真正的数据是保存在commit log里面

复制代码
#commitLog存储路径
storePathCommitLog=/usr/local/rocketmq/broker-a-master/store/commitlog

[root@localhost commitlog]# ls
00000000000000000000

如果所有的操作都在访问00000000000000000000这样的数据文件,它的性能会有一些影响。

为了解决这个问题Rocketmq做了一些提升。虽然这部分是磁盘文件,但是Rocketmq使用了顺序的读写使用了页缓存的概念,使用了0拷贝相关的技术让Rocketmq在读这个文件的性能上面也可以做到非常快。

页缓存与内存映射

如果所有的数据都在访问磁盘文件,在访问磁盘文件的时候会存在用户态到内核态的转换。
在用户态要读取和写入文件,这个是磁盘上面的文件。所以要转化为内核态。去读取磁盘上的文件。
为了解决这样一个问题,rocketmq提供了页缓存,操作系统使用页缓存的机制,在读取缓存的时候,它们之间会创建映射的关系。用内存当中的缓存映射出磁盘的数据。

⻚缓存(PageCache)是OS对⽂件的缓存,⽤于加速对⽂件的读写。⼀般来说,程序
对⽂件进⾏顺序读写的速度⼏乎接近于内存的读写速度,主要原因就是由于OS使⽤
PageCache机制对读写访问操作进⾏了性能优化,将⼀部分的内存⽤作PageCache。
对于数据的写⼊,OS会先写⼊⾄Cache内,随后通过异步的⽅式由pdflush内核线程
将Cache内的数据刷盘⾄物理磁盘上。
对于数据的读取,如果⼀次读取⽂件时出现未命中PageCache的情况,OS从物理磁盘上访问读取⽂件的同时,会顺序对其他相邻块的数据⽂件进⾏预读取。

那在读写的时候要比直接读取磁盘要快的多,这个做的性能优化。
除了这样一个性能优化还做了一个事情叫做顺序的读写,OS从物理磁盘上访问读取⽂件的同时,会顺序对其他相邻块的数据⽂件进⾏预读取。这样的话也能够将速度有个很大的提升。顺序读写和随机读写性能是相差很大的。
比如还有0拷贝这块
store里面还会有一些文件

复制代码
[root@localhost store]# ls  -l
total 8
-rw-r--r--. 1 root root    0 Sep 18  2024 abort
-rw-r--r--. 1 root root 4096 Aug 17 15:49 checkpoint
drwxr-xr-x. 2 root root   34 Sep 27  2024 commitlog
drwxr-xr-x. 2 root root  246 Aug 17 15:50 config
drwxr-xr-x. 3 root root   23 Sep 22  2024 consumequeue
drwxr-xr-x. 2 root root   31 Nov 24  2024 index
-rw-r--r--. 1 root root    4 Nov 24  2024 lock

abort文件,这个abort文件大小是0,当broker启动的时候会去创建这个abort文件。当broker在正常关闭的时候,abort文件会被删除掉。

当broker在启动的时候发现在store里面有这个abort文件,那么意味着上一次是非正常关闭,所以会配有相应的机制去做一些偏移量,配置的检查。所以这是abort文件的一些作用。

config文件下面的json文件,比如topic的信息会被保存到topics文件里面。比如topics是用来保存topic的一些信息。

在控制台展示的数据其实也是从这些json文件里面读取到的。

相关推荐
云闲不收2 天前
RocketMQ基础以及和 Kafka 有什么区别
分布式·kafka·rocketmq
无名客02 天前
RocketMQ相对于RabbitMQ 的优势
分布式·rabbitmq·rocketmq
用户9446814013502 天前
【RocketMQ长文 从入门到精通(中)】工作原理
消息队列·rocketmq
用户9446814013502 天前
【RocketMQ长文 从入门到精通(上)】基础概念
rocketmq
若水不如远方5 天前
RocketMQ消费流程深度解析:从原理到实践
后端·rocketmq
Apache_RocketMQ7 天前
Apache RocketMQ 打破锁性能瓶颈之道
云原生·消息队列·rocketmq
阿里云云原生10 天前
海量接入、毫秒响应:易易互联携手阿里云构筑高可用物联网消息中枢
rocketmq
gtGsl_10 天前
深入解析 Apache RocketMQ架构组成与核心组件作用
架构·rocketmq·java-rocketmq
鼠鼠我捏,要死了捏11 天前
RocketMQ 高可用集群原理深度解析与性能优化实践指南
性能优化·消息队列·rocketmq
java1234_小锋14 天前
RocketMQ的集群架构是怎样的?
架构·rocketmq·java-rocketmq