RocketMQ Consumer如何获取并维护消费进度？

最新推荐文章于 2023-10-30 19:36:30 发布

GAMELOFT9

最新推荐文章于 2023-10-30 19:36:30 发布

阅读量3.5k

点赞数 3

分类专栏： RocketMQ的秘密 RocketMQ

本文链接：https://blog.csdn.net/GAMEloft9/article/details/103999826

版权

RocketMQ的秘密同时被 2 个专栏收录

13 篇文章 7 订阅

订阅专栏

RocketMQ

13 篇文章 4 订阅

订阅专栏

背景

Cosumer消息消费流程比较复杂，比较重要的有下面几个模块：维护消费进度，查找消息，消息过滤，负载均衡，消息处理，回发确认等。限于篇幅，这篇文章主要介绍Consumer是如何获取并维护消费进度。由于以上几个步骤都是紧密相连的，可能会出现互相穿插的情况。

消费进度文件

我们之前的文章RocketMQ 如何构建ConsumerQueue的？中讲过，通过一个服务线程异步的从CommitLog中获取已经写入的消息，然后将消息位置，大小，tagsCode等关键信息保存至选好的ConsumerQueue中。ConsumerQueue是一个索引文件，保存了某个topic下面的消息在CommitLog中的位置等信息。我们消费消息，先从这个ConsumerQueue中读取消息位置，然后再去CommitLog中取消息，这是典型的空间换时间的做法。与此同时，我们需要记录下我们读取到哪里了，下次读取的时候就从上次结束的地方继续往前读，所以我们还需要一个保存消费进度的文件。在RocketMQ中这个文件就是ConsumserOffset.json，在store/config目录下，如下所示：
在这里插入图片描述
consumerOffset.json中的内容类似于这样：

其中test_url@sub_localtest是主键，规则是topic@consumerGroup，内容就是每个ConsumerQueue的消费进度。例如0号Queue下个应该消费2599，1号Queue下个应该消费2602，6号Queue下个应该消费102。这个进度是按1累加的，对应于ConsumerQueue的固定的20个字节。
现在我们做个实验，首先通过Producer发送一条消息(代码很简单，就不贴了)，发送结果如下所示：

SendResult [sendStatus=SEND_OK, msgId=C0A84D05091058644D4664E1427C0000, offsetMsgId=C0A84D0000002A9F00000000001ED9BA, messageQueue=MessageQueue [topic=test_url, brokerName=broker-a, queueId=6], queueOffset=102]

从结果中可以看到，消息保存在了broker-a的MesssageQueue-6中的102号位置。然后我们启动Consumer，消费这条消息：

2020-01-20 14:08:04.230 INFO  [MessageThread_3] c.c.r.example.simplest.Consumer - 收到消息:topic=test_url,msgId=C0A84D05091058644D4664E1427C0000

消息成功被消费了，然后我们再去看看ConsumerOffset.json文件内容：
在这里插入图片描述
看到没？上次截图中，6号Queue的消费进度是102，这次变成了103，已经成功消费了一条消息。

现在我们就要开始深究了：在Consumer消费消息时，这个消费进度是如何获取并维护的呢？

从何处开始消费？

Consumer在通过调用

consumer.start();

启动的时候，会加载消费进度，如下所示：

//DefaultMQPushConsumerImpl.start()方法
if (this.defaultMQPushConsumer.getOffsetStore() != null) {
     this.offsetStore = this.defaultMQPushConsumer.getOffsetStore(); // 如果本地有直接加载
} else {
	switch (this.defaultMQPushConsumer.getMessageModel()) {
                        case BROADCASTING:
                            this.offsetStore = new LocalFileOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup());
                            break;
                        case CLUSTERING:
                            this.offsetStore = new RemoteBrokerOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup()); // 集群模式下生成一个RemoteBrokerOffsetSotre，消费进度就保存在broker端
                            break;
                        default:
                            break;
                    }
                    this.defaultMQPushConsumer.setOffsetStore(this.offsetStore);
                }
                this.offsetStore.load(); // 加载本地进度

上面提到了offsetStore对象，这是一个接口，如下所示：

public interface OffsetStore {
    void load() throws MQClientException;
    void updateOffset(final MessageQueue mq, final long offset, final boolean increaseOnly);
    long readOffset(final MessageQueue mq, final ReadOffsetType type);
    void persistAll(final Set<MessageQueue> mqs);
    void persist(final MessageQueue mq);
    void removeOffset(MessageQueue mq);
    Map<MessageQueue, Long> cloneOffsetTable(String topic);
    void updateConsumeOffsetToBroker(MessageQueue mq, long offset, boolean isOneway) throws RemotingException,
        MQBrokerException, InterruptedException, MQClientException;
}

OffsetStore提供了操作消费进度的方法，例如：加载消费进度，读取消费进度，更新消费进度等等。在集群消费模式下，消费进度并没有持久化在Consumer端，而是保存在了远程Broker端，例如上面使用的是RemoteBrokerOffsetStore类：

public class RemoteBrokerOffsetStore implements OffsetStore {
    private final static InternalLogger log = ClientLogger.getLog();
    private final MQClientInstance mQClientFactory; // 客户端实例
    private final String groupName; // 集群名称
    private ConcurrentMap<MessageQueue, AtomicLong> offsetTable =
        new ConcurrentHashMap<MessageQueue, AtomicLong>(); // 每个Queue的消费进度
}

因为消费进度保存在broker端，用于加载本地消费进度的load方法在RemoteBrokerOffsetStore中是空的，不做任何事，真正读取消费进度是通过readOffset方法实现的。
目前为止我们知道了，消费进度是存在broker端的一个consumerOffset.json文件中的，通过readOffset方法读取这个文件就知道了从哪里开始消费。

负载均衡简单介绍

在深入了解读取消费进度的readOffset方法前，需要简单了解何时会调用这个方法。
我们文章开头提到Consumer消费消息时的模块，其中包括了负载均衡这个模块。一个topic有多个消费队列，而同一组group下面也可能有多个Consumer订阅了这个topic，于是这些队列需要按照一定策略分配给同一个组下面的Consumer消费，例如下面的平均分配：
在这里插入图片描述
在上图中，TOPIC_A有5个队列，有2个Consumer订阅了，如果按照平均分配的话，那就是Consumer1消费其中3个队列，Consumer2消费其中2个队列。这个就是负载均衡。
一个Consumer分配到了几个消息队列，就会相应的创建几个消息处理队列（ProcessQueue，消费消息时会用到），并且此时会生成一个拉取消息的请求（PullRequest，请求消息时会用到），这个请求不是真正的发往broker端的获取消息的请求，而是保存在一个阻塞队列里面，然后由专门的拉取消息的服务线程读取它并组装获取消息请求，发送给broker端（这么做当然是为了获得异步的好处）。这个请求PullRequest里面就临时保存着下个消费进度，如下所示：
在这里插入图片描述
只有这里才会生成一个PullRequest，后续该consumerGroup下该Queue的所有拉取消息都是重复使用该PullRequest，只是更新了其中的nextOffset等参数。PullRequest类如下所示：

public class PullRequest {
    private String consumerGroup; // 消费分组
    private MessageQueue messageQueue; // 消费队列
    private ProcessQueue processQueue; // 消息处理队列
    private long nextOffset; // 消费进度
    private boolean lockedFirst = false; // 是否锁住
}

计算消费进度

在生成PullRequest时，就会计算从何处开始消费（computPullFromWhere）。RocketMQ默认的消费起始点是CONSUME_FROM_LAST_OFFSET（从上个offset开始消费），因此在computPullFromWhere方法中，走到的是这个case:

 case CONSUME_FROM_LAST_OFFSET: {
                long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);// 读取偏移
                if (lastOffset >= 0) { // 正常偏移
                    result = lastOffset;
                }
                // First start,no offset
                else if (-1 == lastOffset) { // 初次启动，broker没有偏移，readOffset返回-1
                    if (mq.getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
                        result = 0L; // 消息重试
                    } else {
                        try {
                            result = this.mQClientFactory.getMQAdminImpl().maxOffset(mq);// 获取该消息队列消费的最大偏移
                        } catch (MQClientException e) {
                            result = -1;
                        }
                    }
                } else {
                    result = -1; // 异常情况readOffset返回-2，这里再返-1
                }
                break;
            }

这里就走到了我们上面提到的readOffset方法了！

readOffset

readOffse方法t的入参是当前分配到的messageQueue和固定的ReadOffsetType.READ_FROM_STORE，意思就从远程Broker读取该MessageQueue的消费进度。因此走到的是READ_FROM_STORE这个分支，如下所示：

case READ_FROM_STORE: {
                    try {
                        long brokerOffset = this.fetchConsumeOffsetFromBroker(mq);// 从broker获取消费进度
                        AtomicLong offset = new AtomicLong(brokerOffset);
                        this.updateOffset(mq, offset.get(), false); // 更新消费进度，更新的是RemoteBrokerOffsetStore.offsetTable这个表
                        return brokerOffset;
                    }
                    // No offset in broker
                    catch (MQBrokerException e) {
                        return -1;
                    }
                    //Other exceptions
                    catch (Exception e) {
                        log.warn("fetchConsumeOffsetFromBroker exception, " + mq, e);
                        return -2;
                    }
                }

fetchConsumerOffsetFromBroker就是往该MessageQueue所在的broker发送获取消费进度的请求了，底层通讯之前的文章已经讲过了，这里就不在赘述了。在Broker端，消费进度保存在ConsumerOffsetManager里面：
在这里插入图片描述
key是Topic@ConsumerGroup，value存的是queueId和offset的映射关系。查找消费进度的代码如下：

long offset =
            this.brokerController.getConsumerOffsetManager().queryOffset(
                requestHeader.getConsumerGroup(), requestHeader.getTopic(), requestHeader.getQueueId());

从key来看，topic的消费进度是按照ConsumerGroup来区分的，不同的ConsumerGroup下该MessageQueue的消费进度互不影响，这一点也很好理解。

消息获取与更新消费进度

到目前为止，我们知道了每个MessageQueue的消费进度存在对应的Broker端，在负载均衡服务对每个Topic做负载均衡的时候，创建了PullRequest，并读取了消费进度offset。然后将PullRequest放入了一个阻塞队列中(pullRequestQueue)，供专门的拉取消息线程服务(PullMessageService)读取，然后发起真正的拉取消息请求。这里更新消费进度与获取消息密切相关，因此会涉及一些获取消息的内容。

PullMessageSevice是一个服务线程，专门用于拉取消息，其run方法如下所示：

@Override
    public void run() {
        log.info(this.getServiceName() + " service started");

        while (!this.isStopped()) {
            try {
                PullRequest pullRequest = this.pullRequestQueue.take(); // 从阻塞队列中获取一个PullsRequest
                this.pullMessage(pullRequest); // 拉取消息
            } catch (InterruptedException ignored) {
            } catch (Exception e) {
                log.error("Pull Message Service Run Method exception", e);
            }
        }

        log.info(this.getServiceName() + " service end");
    }

首先从阻塞队列pullRequestQueue中取出PullRequest，然后就是开始调用pullMessage方法获取消息了。调用最终会走到DefaultMQPushConsumerImpl的pullMessage方法中来，代码很多并且如何拉取消息不是本次重点内容，我们这里只贴最后的发送请求部分，理解的其中的参数，也就明白了消息获取请求。

try {
            this.pullAPIWrapper.pullKernelImpl(
                pullRequest.getMessageQueue(), //消息队列
                subExpression,// 订阅表达式，例如"TAG_A"
                subscriptionData.getExpressionType(), // 表达式类型，例如"TAG"
                subscriptionData.getSubVersion(), // 版本号
                pullRequest.getNextOffset(), // 下个消息进度
                this.defaultMQPushConsumer.getPullBatchSize(), // 一次性拉取多少条，默认32
                sysFlag,// 一些标志位集合，暂时不关心
                commitOffsetValue, //
                BROKER_SUSPEND_MAX_TIME_MILLIS,// 长轮询时被hold住时间，默认15秒
                CONSUMER_TIMEOUT_MILLIS_WHEN_SUSPEND,// 调用超时时间，默认30秒
                CommunicationMode.ASYNC, // 异步通讯
                pullCallback// 回调
            );
        } catch (Exception e) {
            log.error("pullKernelImpl exception", e);
            this.executePullRequestLater(pullRequest, PULL_TIME_DELAY_MILLS_WHEN_EXCEPTION);
        }

Consumer端更新消费进度

由于发送消息获取请求是异步操作，返回处理在pullCallback里面，因此我们可以大胆猜测，Consumer端消费进度的更新也肯定在这里面。确实，在pullCallback里面会将PullRequest的nextOffset更新：
在这里插入图片描述

broker端更新消费进度

由于消息处理不是本次重点内容，所以Broker端对获取消息的处理，我们不打算深入，仅仅需要知道Broker端获取消息后，会计算出一个nextBeginOffset，它就是下个消费进度，然后会返回到Consumer端去供Consumer端更新进度，如下所示：

nextBeginOffset = offset + (i / ConsumeQueue.CQ_STORE_UNIT_SIZE);

其次，获取完消息后，broker端也会更新消费进度，如下所示：

boolean storeOffsetEnable = brokerAllowSuspend; // brokerAllowSuspend默认是true，如果没有消息就会hold住请求
        storeOffsetEnable = storeOffsetEnable && hasCommitOffsetFlag; // 拉取消息时如果允许提交消费进度，commitOffsetFlag就有
        storeOffsetEnable = storeOffsetEnable 
            && this.brokerController.getMessageStoreConfig().getBrokerRole() != BrokerRole.SLAVE;// 所以Broker master节点默认情况下这个是true
        if (storeOffsetEnable) {
            this.brokerController.getConsumerOffsetManager().commitOffset(RemotingHelper.parseChannelRemoteAddr(channel),
                requestHeader.getConsumerGroup(), requestHeader.getTopic(), requestHeader.getQueueId(), requestHeader.getCommitOffset()); // 保存消费进度，写入offsetTable
        }

消费进度持久化

Broker更新消费进度，仅仅是更新了offsetTable这个表，并没有涉及到ConsumerOffset.json这个文件。其实，在Broker初始化时，会启动一项定时任务，定期保存tableOffset到ConsumerOffset.json文件中，如下所示：

this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
                @Override
                public void run() {
                    try {
                        BrokerController.this.consumerOffsetManager.persist(); // 保存文件
                    } catch (Throwable e) {
                        log.error("schedule persist consumerOffset error.", e);
                    }
                }
            }, 1000 * 10, this.brokerConfig.getFlushConsumerOffsetInterval(), TimeUnit.MILLISECONDS);

flushConsumerOffsetIntervval默认是5s，也就是每隔5保存一次消费进度到文件中。保存的过程是先将原来的文件存到ConsumerOffset.json.bak文件中，然后将新的内容存入ConsumerOffset.json文件。
至此，ConsumerQueue的消费进度维护就算完成了。

小结

RocketMQ每个Topic的消息，在各自的ConsumerGroup下，每个MessageQueue的消费进度是存在broker端的一个consumerOffset.json文件中。Consumer端启动时，会创建PullRequest请求，此时会向Broker发送获取下个消费进度的请求，Broker读取下个消费进度并返回给Consumer端。然后Consumer通过单独的服务线程读取PullRequest并据此拉取消息，Broker端获取到消息后，会及时更新消费进度。此外还有一个单独的定时任务定期保存消费进度到文件，并备份原文件。

GAMELOFT9

关注

3
点赞
踩
13

收藏

觉得还不错? 一键收藏
0
评论
RocketMQ Consumer如何获取并维护消费进度？

背景Cosumer消费消息，一般是如下几个步骤：发送获取消息请求，查找消息，消息过滤，负载均衡，消息处理，回发确认。限于篇幅，这篇文章主要介绍Consumer是如何发送获取消息请求的，以及RocketMQ基于长轮询的推模式实现。由于以上几个步骤都是紧密相连的，可能会出现互相穿插。从何处开始消费？...
复制链接

扫一扫