rocketmq问题汇总-一个consumerGroup只对应一个topic

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/a417930422/article/details/50663639

1 同一个订阅组内不同Consumer实例订阅不同topic消费混乱问题调查

图1:


背景说明:

如图1左半部分,假设目前的关系如下:

broker: 两个,broker_a和broker_b

topic:两个,topic1和topic2,每个topic在每个broker上分为4个queue

consumer:两个,consumer1和consumer2,都属于group1,分属于不同的jvm运行。

默认情况下,topic和queue的对应关系是:

topic1 <-> broker_a q0~q3,

topic1 <-> broker_b q0~q3,

topic2 <-> broker_a q0~q3,

topic2 <-> broker_b q0~q3

rebalance流程开始:

假设consumer1先启动,consumer1最终通过rebalance对应关系如下:

topic1 <-> broker_a q0~q3,

topic1 <-> broker_b q0~q3

 

接着consumer2启动,consumer2具体rebalance流程如下:


关键点在5.2,会把consumer1也抓下来,接着根据分配策略会导致consumer2只消费broker_b上topic2对应的q0~q3。

同样,consumer1也会进行rebalance,进而使其只消费broker_a的topic1对应的q0~q3,最终导致其关系变为图1中右图所示。

consumer端警告日志:

rebalance完成之后,consumer端间断打印如下异常:

14:22:04.005 [NettyClientPublicExecutor_3] WARN RocketmqClient - execute the pull request exception
com.alibaba.rocketmq.client.exception.MQBrokerException: CODE: 24 DESC: the consumer's subscription not exist
See https://github.com/alibaba/RocketMQ/issues/46 for further details.
at com.alibaba.rocketmq.client.impl.MQClientAPIImpl.processPullResponse(MQClientAPIImpl.java:500) ~[rocketmq-client-3.2.6.jar:na]
at com.alibaba.rocketmq.client.impl.MQClientAPIImpl.access$100(MQClientAPIImpl.java:78) ~[rocketmq-client-3.2.6.jar:na]
at com.alibaba.rocketmq.client.impl.MQClientAPIImpl$2.operationComplete(MQClientAPIImpl.java:455) ~[rocketmq-client-3.2.6.jar:na]
at com.alibaba.rocketmq.remoting.netty.ResponseFuture.executeInvokeCallback(ResponseFuture.java:62) [rocketmq-remoting-3.2.6.jar:na]
at com.alibaba.rocketmq.remoting.netty.NettyRemotingAbstract$2.run(NettyRemotingAbstract.java:262) [rocketmq-remoting-3.2.6.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]

broker端也发现相应日志:

2015-07-31 16:38:08 WARN ClientManageThread_4 - subscription changed, group: consumerTestGroup remove topic vrs-topic-test SubscriptionData [classFilterMode=false, topic=vrs-topic-test, subString=*, tagsSet=[], codeSet=[], subVersion=1438331853269]

2015-07-31 16:38:22 WARN PullMessageThread_29 - the consumer's subscription not exist, group: consumerTestGroup

consumer&broker异常日志原因:

consumer会定时与所有broker进行心跳通信,代码详见:MQClientInstance.startScheduledTask,默认每30秒心跳一次。

心跳主要作用:

会将HeartbeatData对象发送到broker端,携带consumer group和topic信息

对应到图1中,consumer1会发送类似group1,topic1

consumer2会发送group1,topic2

 

经过走查broker端代码发现如下代码:


重点在步骤4和5.1和5.2,现在只针对一个broker做一下分析:

假设consumer1先启动,对于broker_a一开始关系是group1->topic1

当consumer2启动并rebalance完成后,consumer2发送group1->topic2,

在步骤4,会根据group1将原先的group1->topic1取出。

在步骤5.1,添加topic2

在步骤5.2,移除topic1。

 

而consumer1在rebalance之后同样会进行如上步骤,导致topic1&topic2反复被remove掉,

最终导致了consumer端和broker端的异常日志不停打印。

 

最终结论:是rebalance导致consumer只消费一部分topic,但是显然rocketmq在broker端做了处理,从而不停打印警告信息。

该调查由如何扩容consumer引出

展开阅读全文

没有更多推荐了,返回首页