定西市网站建设企业,架设网站的目的,最新传奇手游开服网站,网店推广软文范例问题: 使用RocketMQ消息队列#xff0c;生产者将数据发送出去了#xff0c;但是生产者一致没接收到#xff08;或者是间隔好几分钟#xff0c;突然接收到一条数据#xff09;怎么办#xff1f;并且通过rocket web控制台查看消息的状态为NOT_ONELINE或者NOT_CONSUME#…问题: 使用RocketMQ消息队列生产者将数据发送出去了但是生产者一致没接收到或者是间隔好几分钟突然接收到一条数据怎么办并且通过rocket web控制台查看消息的状态为NOT_ONELINE或者NOT_CONSUME(如下图) 这种诡异现象该怎么解决
1. 先说解决方案
这种情况99%是由于订阅关系不一致导致的可以排查下程序看看是否有多个消费者使用了同一个group并且订阅了不同的主题。逻辑图展示如下 这种情况只需要将不同的消费者的group区分一下即可, 逻辑关系图变成如下这种
到此为止是不是惊奇的发现问题解决了
2. 注意事项订阅关系一致性
看下Rocket MQ官方文档给出的说明 定义 消费者分组是 Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。 和消费者不同消费者分组并不是运行实体而是一个逻辑资源。在 Apache RocketMQ 中通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。 这里面只描述出了Tag的一致事实上下面这种订阅关系也是错误的同一个group中的两个消费者分别订阅了不同的主题, 违背了定义中的消费行为一致原则
//Consumer c1
Consumer c1 ConsumerBuilder.build(groupA);
c1.subscribe(topicA);
//Consumer c2Consumer
c2 ConsumerBuilder.build(groupA);
c2.subscribe(topicB);3. 剖析源码实现分析原因
从GitHub下载rocketmq源码通过idea打开之后从官方提供的example进来 进入到DefaultMQPushConsumer构造方法中可以发现初始化了一个DefaultMQPushConsumerImpl类 public DefaultMQPushConsumer(final String namespace, final String consumerGroup, RPCHook rpcHook,AllocateMessageQueueStrategy allocateMessageQueueStrategy) {this.consumerGroup consumerGroup;this.namespace namespace;this.allocateMessageQueueStrategy allocateMessageQueueStrategy;// 这里初始化一个默认的push类型的Consumer实现类defaultMQPushConsumerImpl new DefaultMQPushConsumerImpl(this, rpcHook);}然后继续进入到DefaultMQPushConsumerImpl类中, 可以看见有一个成员变量MQClientInstance mQClientFactory, 在DefaultMQPushConsumerImpl类的start()(启动消费者)方法中会通过MQClientManager初始化MQClientInstance类. 接着跳转到MQClientInstance构造方法中, 会发现有这样一行代码, 初始化了一个rebalanceService. 这个rebalanceService就是RocketMQ隔一段时间进行rebalance的核心实现. 继续剖析RebalanceService类, 发现其实现了Runnable接口, 话不多说, 直接看其 run()方法中做了什么事.
呀! 原来是隔一段时间调用一次上述咱们提到的DefaultMQPushConsumerImpl类中的doRebalance()方法, 搞了半天又绕回来了. … … … … … …
直接进入到这里面, 看看rebalance的逻辑: 集群部署模式下, 会进行rebalance操作, 根据topic名称和group名称获取到所有的consumer列表.
case CLUSTERING: {SetMessageQueue mqSet this.topicSubscribeInfoTable.get(topic);// 这里根据topic名称和Group进行获取到所有的consumerListString cidAll this.mQClientFactory.findConsumerIdList(topic, consumerGroup);if (null mqSet) {if (!topic.startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {this.messageQueueChanged(topic, Collections.MessageQueueemptySet(), Collections.MessageQueueemptySet());log.warn(doRebalance, {}, but the topic[{}] not exist., consumerGroup, topic);}}但是进去这行代码里面发现, topic名称仅仅用来获取Broker的网络地址, 真正获取到所有Consumer列表的是通过Group名称获取的, 看到这里相信大家基本上能够恍然大悟. 回归到上面的问题: 如果一个一个Group中的多个消费者分别订阅了不同的主题, 即: 消费行为不一致, 无论这个属于当前Group中的消费者是否订阅了这个主题, 都会参与rebalance. 画图解释一下, 假设在同一个Group下, 两个Consumer都分别订阅了Topic1和Topic2, 这种情况订阅关系一致, 假设消费者1消费Topic2的速度比较快, 经过一次rebalance之后, Consumer订阅的队列逻辑有可能成为这样的: 此时由于订阅关系的一致性, 整体系统并不会出现问题. 接下来看一种情况, 同一个消费组中的Consumer1 订阅了Topic1, Consumer2订阅了Topic2, 初始情况逻辑关系是这样: 由于进行rebalance是通过Group获取对应的消费者客户端ID, 因此rebalance之后可能出现Consumer1 指向了Topic2中的某一个队列, 同理, Consumer2指向了Topic1中的队列. 但是这与Consumer中设定的topic不一致, 因此会出现RocketMQ中消息状态为为NOT_COMSUME_YET
(个人通过对源码的简单梳理总结的文章, 如有错误欢迎指正)
