RocketMQ源码分析之消费队列、Index索引文件存储结构与存储机制-上篇_logic queue order maybe wrong,expectlogicoffset-CSDN博客

本文链接：https://blog.csdn.net/qq_33291299/article/details/129325884

本文深入分析RocketMQ的消费队列与Index索引文件的存储结构和机制。首先介绍了CommitLogDispatcherBuildConsumeQueue的流程，包括判断ConsumeQueue的可写性及写入逻辑。接着详细讲解了CommitLogDispatcherBuildIndex，特别是IndexFile的核心属性和IndexService的构造方法。内容涵盖ConsumeQueue条目的组成、存储路径以及默认大小，以及IndexFile的存储路径和相关属性。

摘要由CSDN通过智能技术生成

代码@1，根据 offset 从 commitlog 找到一条消息，如果找不到，退出此次循环，doReput方法跳出，此处从 commitlog 文件中取出消息的逻辑，在下文会重点分析，故在此暂时跳过。

先浏览一下 SelectMappedBufferResult

代码@2：尝试构建转发请求对象 DispatchRequest ，我大概浏览了一下 commitLog.checkMessageAndReturnSize，主要是从Nio ByteBuffer中，根据 commitlog 消息存储格式，解析出消息的核心属性：

// 消息主题
private final String topic; 
// 消息队列
private final int queueId; 
// commitlog中的偏移量
private final long commitLogOffset;
// 消息大小
private final int msgSize; 
 // tagsCode
private final long tagsCode;
// 消息存储时间
private final long storeTimestamp; 
//消息在消费队列的offset
private final long consumeQueueOffset; 
// 存放在消息属性中的keys: PROPERTY_KEYS = "KEYS"
private final String keys; 
// 是否成功
private final boolean success; 
// 消息唯一键 "UNIQ_KEY"
private final String uniqKey; 
// 系统标志
private final int sysFlag;
// 事务pre消息偏移量
private final long preparedTransactionOffset; 
// 属性
private final Map<String, String> propertiesMap;

代码@3：转发DistpachRequest。

根据实现类，consumequeue,index 分别对应 CommitLogDispatcherBuildConsumeQueue 与 CommitlogDispatcherBuildIndex。

2.1 CommitLogDispatcherBuildConsumeQueue

核心处理方法：

public void putMessagePositionInfoWrapper(DispatchRequest request) {
        final int maxRetries = 30;
        boolean canWrite = this.defaultMessageStore.getRunningFlags().isCQWriteable();      // @1
        for (int i = 0; i < maxRetries && canWrite; i++) {
            long tagsCode = request.getTagsCode();
            if (isExtWriteEnable()) {
                C