RocketMQ源码解读——同一消费组下不同消费者订阅关系不同时

本文探讨了RocketMQ中同一消费组内不同消费者订阅关系不一致时引发的问题。当消费者订阅不同主题时,由于心跳机制导致订阅信息相互覆盖,从而影响消息消费。通过源码分析揭示了问题的根本原因,即消费组内的订阅信息按组存储,不同消费者心跳更新导致订阅关系混乱。
摘要由CSDN通过智能技术生成

RocketMQ源码解读——同一消费组下不同消费者订阅关系不同时

@(rocketmq源码解读)


先解释一下题目,我们假设有一个Producer和两个ConsumerProducerTOPICATOPICB发送消息,两个Consumer分别订阅两个topic。我们看下这时候会出现的问题,以及根据源码分析一下为什么出现问题。

现象

现象其实还是比较隐蔽的,broker上会打印:the consumer's subscription not exist,group ...的日志(Consumer端也会打印类似的日志)。

还会有一些subscription changed, group: ...类似的日志,并且如果仔细的话还会发现,其中一个消费者消费消息时,另外一个就不会消费。

源码分析

我们看一下为什么会导致这样的问题,一开始生看或者debug都是很难下手,这时候可能就需要使用必杀技(一般不外传那种)——

问天问地,谷歌百度必应。我直接问了一个大神——芋艿。大神说这种情况会出问题,具体原因他也记不清了,导致这种现象的问题应该是消费关系不停地相互覆盖

好了,听到这句话我们就有入口了,至少知道应该从Broker上找起。

顺藤摸瓜找到了原因,下面一起看一下源码。

首先我们知道,消费者的两种实现(推和拉)中都维护一个MQClientInstance,这个类非常重要,在启动消费者的时候,都会去启动这个类,我们看下启动的代码,其中有这么一部分:

// Start various schedule tasks
this.startScheduledTask();
复制代码

这里启动了好多定时任务,我们追进去看一下:

this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {

    @Override
    public void run() {
        try {
            MQClientInstance.this.cleanOfflineBroker();
            //定时发送心跳
            MQClientInstance.this
  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值