rocketmq中重试源码分析_RocketMQ源码分析之ConsumeQueue

一：前言

上周末写了两篇文章讲到服务端Broker在收到消息后是如何存储消息的：

《RocketMQ源码分析之消息存储》

《RocketMQ源码分析之消息刷盘》

但是除了负责存储消息之外，Broker还要负责创建消费队列。关于消费队列，其实在讲消息发送的时候《RocketMQ源码分析之消息发送》，我就画过一张简单的图。

每个 Topic 在Broker 端都会有多个消费队列，Producer每次都会选择一个ComsumeQueue发送消息，Consumer同样也会每次都选择一个ComsumeQueue拉取消息进行消费。

那么这些ConsumeQueue究竟是什么？有什么作用？又是何时创建的呢？本篇文章我们就一起来分析下吧。

二：ConsumeQueue介绍

每个ConsumeQueue都有一个id，id 的值为0到TopicConfig配置的队列数量。比如某个Topic的消费队列数量为4，那么四个ConsumeQueue的id就分别为0、1、2、3。

ConsumeQueue是不负责存储消息的，只是负责记录它所属Topic的消息在CommitLog中的偏移量，这样当消费者从Broker拉取消息的时候，就可以快速根据偏移量定位到消息。

ConsumeQueue本身同样是利用MappedFileQueue进行记录偏移量信息的，可见MappedFileQueue的设计多么美妙，它没有与消息进行耦合，而是设计成一个通用的存储功能。

ConsumeQueue更新消息偏移量的整体过程大概如下图所示，其中涉及了几个概念。

• ReputMessageService
• CommitLogDispatcherBuildConsumeQueue

上面这个图比较粗糙，画的很随意，具体的源码分析还请大家接着往下看。

三：ReputMessageService服务

之前在讲到消息存储的时候，提到每个Broker在初始化的时候都会初始化一个MessageStore负责存储消息，而MessageStore在初始化的时候，同样会启动一个ReputMessageService，ReputMessageService就是用来更新ConsumeQueue中消息偏移的。

ReputMessageSe