浅浅的记录一个线上曾发生的问题和排查方向
曾经遇到过一个需求,上线后MQ消息突然呈几何备注递增,随后把整个CPU直接吃满,后来我排查的时候发现,一个新的消费者,订阅一个已存在的topic的时候,使用了默认的策略。
rocketMQ 的消费者组决定她从何处开始i消费,从最大偏移量还是 从头开始还是怎么的,是由DefaultMQPushConsumer的setConsumeFromWhere(ConsumeFromWhere consumeFromWhere)决定的。
这个api参数有三种策略
- CONSUME_FROM_MAX_OFFSET 从消费队列最大的偏移量开始消费。
- CONSUME_FROM_FIRST_OFFSET 从消费队列最小偏移量开始消费。
- CONSUME_FROM_TIMESTAMP
从指定的时间戳开始消费,默认为消费者启动之前的30分钟处开始消费。可以通过DefaultMQPushConsumer#setConsumeTimestamp。
来看一下第一个策略,这也是导致线上出问题的罪魁祸手
我们知道对于一个新的消费组,无论是集群模式还是广播模式都不会存储该消费组的消费进度,可以理解偏移量为-1,此时就需要根据DefaultMQPushConsumer#consumeFromWhere属性来决定其从何处开始消费,首先我们需要找到其对应的处理入口。我们知道,消息消费者从Broker服务器拉取消息时,需要进行消费队列的负载,即RebalanceImpl。
1public long computePullFromWhere(MessageQueue mq) {
2 long result = -1; // @1
3 final ConsumeFromWhere consumeFromWhere = this.defaultMQPushConsumerImpl.getDefaultMQPushConsumer().getConsumeFromWhere();
4 final OffsetStore offsetStore = this.defaultMQPushConsumerImpl.getOffsetStore();
5 switch (consumeFromWhere) {
6 case CONSUME_FROM_LAST_OFFSET_AND_FROM_MIN_WHEN_BOOT_FIRST:
7 case CONSUME_FROM_MIN_OFFSET:
8 case CONSUME_FROM_MAX_OFFSET:
9 case CONSUME_FROM_LAST_OFFSET: { // @2
10 // 省略部分代码
11 break;
12 }
13 case CONSUME_FROM_FIRST_OFFSET: { // @3
14 // 省略部分代码
15 break;
16 }
17 case CONSUME_FROM_TIMESTAMP: { //@4
18 // 省略部分代码
19 break;
20 }
21 default:
22 break;
23 }
24 return result; // @5
25 }
CONSUME_FROM_LAST_OFFSET的偏移量计算逻辑
1case CONSUME_FROM_LAST_OFFSET: {
2 long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE); // @1
3 if (lastOffset >= 0) { // @2
4 result = lastOffset;
5 }
6 // First start,no offset
7 else if (-1 == lastOffset) { // @3
8 if (mq.getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
9 result = 0L;
10 } else {
11 try {
12 result = this.mQClientFactory.getMQAdminImpl().maxOffset(mq);
13 } catch (MQClientException e) { // @4
14 result = -1;
15 }
16 }
17 } else {
18 result = -1;
19 }
20 break;
21}
代码@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。
1ConsumerManageProcessor#queryConsumerOffset
2private RemotingCommand queryConsumerOffset(ChannelHandlerContext ctx, RemotingCommand request) throws RemotingCommandException {
3 final RemotingCommand response =
4 RemotingCommand.createResponseCommand(QueryConsumerOffsetResponseHeader.class);
5 final QueryConsumerOffsetResponseHeader responseHeader =
6 (QueryConsumerOffsetResponseHeader) response.readCustomHeader();
7 final QueryConsumerOffsetRequestHeader requestHeader =
8 (QueryConsumerOffsetRequestHeader) request
9 .decodeCommandCustomHeader(QueryConsumerOffsetRequestHeader.class);
10
11 long offset =
12 this.brokerController.getConsumerOffsetManager().queryOffset(
13 requestHeader.getConsumerGroup(), requestHeader.getTopic(), requestHeader.getQueueId()); // @1
14
15 if (offset >= 0) { // @2
16 responseHeader.setOffset(offset);
17 response.setCode(ResponseCode.SUCCESS);
18 response.setRemark(null);
19 } else { // @3
20 long minOffset =
21 this.brokerController.getMessageStore().getMinOffsetInQueue(requestHeader.getTopic(),
22 requestHeader.getQueueId()); // @4
23 if (minOffset <= 0
24 && !this.brokerController.getMessageStore().checkInDiskByConsumeOffset( // @5
25 requestHeader.getTopic(), requestHeader.getQueueId(), 0)) {
26 responseHeader.setOffset(0L);
27 response.setCode(ResponseCode.SUCCESS);
28 response.setRemark(null);
29 } else { // @6
30 response.setCode(ResponseCode.QUERY_NOT_FOUND);
31 response.setRemark(“Not found, V3_0_6_SNAPSHOT maybe this group consumer boot first”);
32 }
33 }
34 return response;
35}
代码@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开始消费,而不是从队列的最大偏移量处开始消费。
当线上一个新的消费者去订阅已经存在比较久的topic,但是其在这个服务中从未有过消费的,她从0000000000000000开始,即他的偏移量是从0开始的,所以,当你不设置其策略的时候,她就从头开始消费消息