RocketMQ一个新的消费组初次启动时从何处开始消费呢？

JVM虚拟机资料

于 2024-03-19 16:58:10 发布

阅读量485

点赞数 3

分类专栏： Java程序员文章标签： java-rocketmq rocketmq java

本文链接：https://blog.csdn.net/m0_57540801/article/details/136848204

版权

Java程序员专栏收录该内容

9 篇文章 0 订阅

订阅专栏

}

} else {

result = -1;

}

break;

}

代码@1：使用offsetStore从消息消费进度文件中读取消费消费进度，本文将以集群模式为例展开。稍后详细分析。

代码@2：如果返回的偏移量大于等于0，则直接使用该offset，这个也能理解，大于等于0，表示查询到有效的消息消费进度，从该有效进度开始消费，但我们要特别留意lastOffset为0是什么场景，因为返回0，并不会执行CONSUME_FROM_LAST_OFFSET(语义)。

代码@3：如果lastOffset为-1,表示当前并未存储其有效偏移量，可以理解为第一次消费，如果是消费组重试主题，从重试队列偏移量为0开始消费；如果是普通主题，则从队列当前的最大的有效偏移量开始消费，即CONSUME_FROM_LAST_OFFSET语义的实现。

代码@4：如果从远程服务拉取最大偏移量拉取异常或其他情况，则使用-1作为第一次拉取偏移量。

分析，上述执行的现象，虽然设置的是CONSUME_FROM_LAST_OFFSET，但现象是从队列的第一条消息开始消费，根据上述源码的分析，只有从消费组消费进度存储文件中取到的消息偏移量为0时，才会从第一条消息开始消费，故接下来重点分析消息消费进度存储器(OffsetStore)在什么情况下会返回0。

接下来我们将以集群模式来查看一下消息消费进度的查询逻辑，集群模式的消息进度存储管理器实现为：

RemoteBrokerOffsetStore,最终Broker端的命令处理类为：ConsumerManageProcessor。

ConsumerManageProcessor#queryConsumerOffset

private RemotingCommand queryConsumerOffset(ChannelHandlerContext ctx, RemotingCommand request) throws RemotingCommandException {

final RemotingCommand response =

RemotingCommand.createResponseCommand(QueryConsumerOffsetResponseHeader.class);

final QueryConsumerOffsetResponseHeader responseHeader =

(QueryConsumerOffsetResponseHeader) response.readCustomHeader();

final QueryConsumerOffsetRequestHeader requestHeader =

(QueryConsumerOffsetRequestHeader) request

.decodeCommandCustomHeader(QueryConsumerOffsetRequestHeader.class);

long offset =

this.brokerController.getConsumerOffsetManager().queryOffset(

requestHeader.getConsumerGroup(), requestHeader.getTopic(), requestHeader.getQueueId()); // @1

if (offset >= 0) { // @2

responseHeader.setOffset(offset);

response.setCode(ResponseCode.SUCCESS);

response.setRemark(null);

} else { // @3

long minOffset =

this.brokerController.getMessageStore().getMinOffsetInQueue(requestHeader.getTopic(),

requestHeader.getQueueId()); // @4

if (minOffset <= 0

&& !this.brokerController.getMessageStore().checkInDiskByConsumeOffset( // @5

requestHeader.getTopic(), requestHeader.getQueueId(), 0)) {

responseHeader.setOffset(0L);

response.setCode(ResponseCode.SUCCESS);

response.setRemark(null);

} else { // @6

response.setCode(ResponseCode.QUERY_NOT_FOUND);

response.setRemark(“Not found, V3_0_6_SNAPSHOT maybe this group consumer boot first”);

}

return response;

}

代码@1：从消费消息进度文件中查询消息消费进度。

代码@2：如果消息消费进度文件中存储该队列的消息进度，其返回的offset必然会大于等于0，则直接返回该偏移量该客户端，客户端从该偏移量开始消费。

代码@3：如果未从消息消费进度文件中查询到其进度，offset为-1。则首先获取该主题、消息队列当前在Broker服务器中的最小偏移量(@4)。如果小于等于0(返回0则表示该队列的文件还未曾删除过)并且其最小偏移量对应的消息存储在内存中而不是存在磁盘中，则返回偏移量0，这就意味着ConsumeFromWhere中定义的三种枚举类型都不会生效，直接从0开始消费，到这里就能解开其谜团了(@5)。

代码@6：如果偏移量小于等于0，但其消息已经存储在磁盘中，此时返回未找到，最终RebalancePushImpl#computePullFromWhere中得到的偏移量为-1。

看到这里，大家应该能回答文章开头处提到的问题了吧？

看到这里，大家应该明白了，为什么设置的CONSUME_FROM_LAST_OFFSET，但消费组是从消息队列的开始处消费了吧，原因就是消息消费进度文件中并没有找到其消息消费进度，并且该队列在Broker端的最小偏移量为0，说的更直白点，consumequeue/topicName/queueNum的第一个消息消费队列文件为00000000000000000000,并且消息其对应的消息缓存在Broker端的内存中(pageCache)，其返回给消费端的偏移量为0，故会从0开始消费，而不是从队列的最大偏移量处开始消费。

为了知识体系的完备性，我们顺便来看一下其他两种策略的计算逻辑。

2.2 CONSUME_FROM_FIRST_OFFSET

case CONSUME_FROM_FIRST_OFFSET: {

long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE); // @1

if (lastOffset >= 0) { // @2

result = lastOffset;

} else if (-1 == lastOffset) { // @3

result = 0L;

} else {

result = -1; // @4

}

break;

}

从队列的开始偏移量开始消费，其计算逻辑如下：

代码@1：首先通过偏移量存储器查询消费队列的消费进度。

代码@2：如果大于等于0，则从当前该偏移量开始消费。

代码@3：如果远程返回-1，表示并没有存储该队列的消息消费进度，从0开始。

代码@4：否则从-1开始消费。

2.4 CONSUME_FROM_TIMESTAMP

从指定时戳后的消息开始消费。

case CONSUME_FROM_TIMESTAMP: {

ong lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE); // @1

if (lastOffset >= 0) { // @2

result = lastOffset;

} else if (-1 == lastOffset) { // @3

if (mq.getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {

try {

result = this.mQClientFactory.getMQAdminImpl().maxOffset(mq);

} catch (MQClientException e) {

result = -1;

}

} else {

try {

long timestamp = UtilAll.parseDate(this.defaultMQPushConsumerImpl.getDefaultMQPushConsumer().getConsumeTimestamp(),

UtilAll.YYYYMMDDHHMMSS).getTime();

result = this.mQClientFactory.getMQAdminImpl().searchOffset(mq, timestamp);

} catch (MQClientException e) {

result = -1;

}

} else {

result = -1;

}

break;

}

其基本套路与CONSUME_FROM_LAST_OFFSET一样：

代码@1：首先通过偏移量存储器查询消费队列的消费进度。

代码@2：如果大于等于0，则从当前该偏移量开始消费。

代码@3：如果远程返回-1，表示并没有存储该队列的消息消费进度，如果是重试主题，则从当前队列的最大偏移量开始消费，如果是普通主题，则根据时间戳去Broker端查询，根据查询到的偏移量开始消费。

原理就介绍到这里，下面根据上述理论对其进行验证。

3、猜想与验证

根据上述理论分析我们得知设置CONSUME_FROM_LAST_OFFSET但并不是从消息队列的最大偏移量开始消费的“罪魁祸首”是因为消息消费队列的最小偏移量为0，如果不为0，则就会符合预期，我们来验证一下这个猜想。

首先我们删除commitlog目录下的文件，如图所示：

在这里插入图片描述

其消费队列截图如下：

在这里插入图片描述

消费端的验证代码如下：

public static void main(String[] args) throws InterruptedException, MQClientException {

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(“my_consumer_02”);

consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET);

consumer.subscribe(“TopicTest”, “*”);

consumer.setNamesrvAddr(“127.0.0.1:9876”);

consumer.registerMessageListener(new MessageListenerConcurrently() {

@Override

public ConsumeConcurrentlyStatus consumeMessage(List msgs,

ConsumeConcurrentlyContext context) {

System.out.printf(“%s Receive New Messages: %s %n”, Thread.currentThread().getName(), msgs);

return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;

}

});

consumer.start();

System.out.printf(“Consumer Started.%n”);

}

运行结果如下：

在这里插入图片描述

并没有消息存在的消息，符合预期。

4、解决方案

如果在生产环境下，一个新的消费组订阅一个已经存在比较久的topic，设置CONSUME_FROM_MAX_OFFSET是符合预期的，即该主题的consumequeue/{queueNum}/fileName，fileName通常不会是00000000000000000000，如是是上面文件名，想要实现从队列的最后开始消费，该如何做呢？那就走自动创建消费组的路子，执行如下命令：

./mqadmin updateSubGroup -n 127.0.0.1:9876 -c DefaultCluster -g my_consumer_05

//克隆一个订阅了该topic的消费组消费进度

./mqadmin cloneGroupOffset -n 127.0.0.1:9876 -s my_consumer_01 -d my_consumer_05 -t TopicTest

//重置消费进度到当前队列的最大值

./mqadmin resetOffsetByTime -n 127.0.0.1:9876 -g my_consumer_05 -t TopicTest -s -1

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-ZDWgxzRg-1710838679314)]
[外链图片转存中…(img-18aOSOdK-1710838679314)]
[外链图片转存中…(img-Mmk70yC0-1710838679315)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-ecNEQXq4-1710838679315)]

JVM虚拟机资料

关注

3
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
RocketMQ一个新的消费组初次启动时从何处开始消费呢？

代码@1：使用offsetStore从消息消费进度文件中读取消费消费进度，本文将以集群模式为例展开。稍后详细分析。代码@2：如果返回的偏移量大于等于0，则直接使用该offset，这个也能理解，大于等于0，表示查询到有效的消息消费进度，从该有效进度开始消费，但我们要特别留意lastOffset为0是什么场景，因为返回0，并不会执行CONSUME_FROM_LAST_OFFSET(语义)。
复制链接

扫一扫