RocketMQ存储篇：CommitLog与MapedFile操作解析

"RocketMQ源码分析 - Polygon Mesh Processing in Message Retrieval" 在RocketMQ系统中，消息处理涉及多个关键步骤，其中包括对polygon mesh的处理。本文主要关注的是从磁盘和内存中读取数据的过程，以及消息过滤和存储的相关机制。 在开始执行polygon mesh处理时，首先要检查数据是在磁盘上还是在内存中。这通过比较最大物理偏移量(maxOffsetPy)与当前读取到的物理偏移量(offsetPy)的差值来实现。如果差值大于可用内存大小，说明数据存储在磁盘上；否则，数据可能在内存中可以直接获取。 接着，会调用`DefaultMessageStore.isTheBatchFull`方法来检查此次读取的数据量是否超过了预设的阀值。这个检查有两个标准：一是针对磁盘读取，一次拉取消息的字节数不能超过1024 * 64，消息个数不能超过8；二是针对内存读取，字节数不超过1024 * 256，消息个数不超过25。如果超过这些限制，读取过程将会停止。 在数据过滤阶段，RocketMQ会根据`SubscriptionData`对象和数据块中的tagsCode调用`DefaultMessageFilter.isMessageMatched`进行匹配。匹配成功的条件包括：`SubscriptionData`对象为空、`classFilterMode`为true、`subString`等于'*'，或者`codeSet`集合包含tagsCode值。如果没有任何匹配，且获取的数据总大小为零，则设置状态为`NO_MATCHED_MESSAGE`。 获取数据的关键步骤是调用`CommitLog.getMessage`，传入offsetPy和sizePy作为参数，从commitlog中获取指定偏移量和大小的消息。如果未能获取到数据，且总大小为零，系统会将状态设置为`MESSAGE_WAS_REMOVING`，并利用`CommitLog.rollNextFile`找到offsetPy所在文件的下一个commitlog文件的起始偏移量，以应对被删除的commitlog文件。 如果成功获取到commitlog数据，即`SelectMapedBufferResult`不为null， RocketMQ会进一步处理。它会调用`GetMessageResult.AddMessage`方法，将`SelectMapedBufferResult`添加到`messageMapedList`和`messageBufferList`中，并累加`bufferTotalSize`的值。 在RocketMQ的存储篇中，我们了解到MapedFile是大文件在磁盘上的操作基础。MapedFile支持顺序写操作、消息刷盘、随机读取等操作，并通过MapedFileQueue提供对commitlog和consumequeue文件的访问服务。MapedFileQueue提供了一系列的方法，如根据时间点获取文件、清理文件、获取最小和最大Offset等，以确保高效和准确的消息处理。 整个RocketMQ的消息处理流程涉及到多个层次的检查、过滤和存储操作，确保了消息的可靠性和系统的稳定性。深入理解这些细节对于优化RocketMQ性能和解决问题至关重要。