对于生产者来说，将消息写到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文件的一些作用。