RocketMQ学习笔记：消息存储模型，持久化文件，过期文件删除

这是本人学习的总结，主要学习资料如下

1、消息存储结构

消息在消息队列中的存储结构如下所示。这三个模块都是文件。默认放在${user.home}/store之下。

首先是左边的CommitLog，不管是什么topic，所有的消息都是放到这个集合之中。存储着消息的topic，message等消息的元数据。
右上角的是Comsummequeue，是逻辑消息队列，代表着一个topic底下的一个queue。里面顺序存放着属于这个queue的所有消息。不过这是存放消息的地址和偏移量，消息的其他信息还需要到CommitLog中读取。
Index则是记录着所有消息的索引。RocketMQ提供通过id或Key来快速查询到一个msg。因为id是由brokerId+offset构成的，所以自然能从commitLog中读取消息。Index中则记录key和offset的映射，所以可以通过key快速找到一个msg。

CommitLog采访者消息的所有元信息。每个CommitLog都被本机上的所有queue共享，与消息的topic等无关。

消息的存储结构和Redis的压缩列表类似。每个消息的前面存放一些元数据，后面放消息的具体内容。这样每个消息的长度是不固定的。
请添加图片描述

每个CommitLog文件默认是1G。如果消息塞满了一个文件则会生成一个新的，并且令其初始偏移量在上一个文件的基础上加1073741824（1G = 1073741824byte）。

在写消息时，尽管有多个生产者会同时发送消息，但永远是一个一个地往CommitLog中写消息。

CommitLog 顺序写，可以大大提高写入效率。
实际上，磁盘有时候会比你想象的快很多，有时候也比你想象的慢很多，关键在如何使用，使用得当，磁盘的速度完全可以匹配上网络的数据传输速度。目前的高性能磁盘，顺序写速度可以达到600MB/s ，超过了一般网卡的传输速度，这是磁盘比想象的快的地方但是磁盘随机写的速度只有大概lOOKB/s,和顺序写的性能相差 6000 倍。
虽然是随机读，但是利用操作系统的 pagecache 机制，可以批量地从磁盘读取，作为 cache 存到内存中，加速后续的读取速度。
为了保证完全的顺序写，需要ConsumeQueue这个中间结构，因为ConsumeQueue 里只存偏移量信息，所以尺寸是有限的，在实际情况中，大部分的 ConsumeQueue能够被全部读入内存，所以这个中间结构的操作速度很快，可以认为是内存读取的速度。此外为了保证 CommitLog和ConsumeQueue的一致性， CommitLog 里存储了 Consume Queues、Message Key、 Tag 等所有信息，即使 ConsumeQueue 丢失，也可以通过CommitLog 完全恢复出来。

ComsumeQueue是一个逻辑队列，代表了一个topic下的一个queue。它里面只存储消息的索引，不存具体的信息，具体的消息信息要到CommitLog中寻找。

下面是具体存储结构。
在这里插入图片描述

RocketMQ提供通过id或Key来快速查询到一个msg。因为id是由brokerId+offset构成的，所以自然能从commitLog中读取消息。Index中则记录key和offset的映射，所以可以通过key快速找到一个msg。

RocketMQ的持久化文件默认会放到${user.home}/store目录下，也可以在broker.conf中配置storePathRootDir修改路径。

一般有下面这几个文件。
请添加图片描述

RocketMQ的持久化文件不会永远存在，每隔一段时间就会清理掉一部分。主要是删除CommitLog和ConsumeQueue这两个文件。

在RocketMQ中，一段时间内没更新的文件就被视为过期文件，不管里面的消息是不是全都被消费了。

默认是42小时没有更新就删除，默认时间根据版本的不同而不同，这个也是可以在broker.config中配置的，fileReserveTime。

删除文件是由定时任务做的，默认10s扫描一次。

判断是否要删除过期文件的机制总共和下面这几个个参数有关

fileReserveTime：单位小时，超过这个时间没更新的文件就是过期文件。
destroyMapedFileIntervalForcibly：当清理线程准备删除一个文件时，如果这个文件还被其他线程引用，取消这次删除操作并记录当前时间。destroyMapedFileIntervalForcibly表示在一段时间内（单位是ms），会一直保留这个文件。超过这个时间以后，每次清理线程发现这个文件就会减少1000个对该文件的引用，直到引用数变成0，删除该文件。