先考虑一个问题:在一个JVM进程中,启动多个消费者/生产者,有没有限制?使用的netty client是同一个还是多个?

以DefaultMQPushConsumer为例,start---this.defaultMQPushConsumerImpl.start()---mQClientFactory.start()----this.mQClientAPIImpl.start()-----this.remotingClient.start(),消费者和生产者中保存间接指向remotingClient的引用,所有的请求都通过这个remotingClient来进行。而在mQClientFactory生成的时候,以消费者启动为例,getOrCreateMQClientInstance方法中,看到有一个以clientId为key 的缓存factoryTable,clientId的生成是ip+当前进程id+自定义的unitName,先不考虑unitName,那么同一个springboot项目中,所有消费者的clientId都是相同的,那么MQClientInstance也就是mQClientFactory都是同一个,那么remotingClient也是同一个。那么在mQClientFactory.registerConsumer方法中,如果同一个进程中同一个consumerGroup下面有多个消费者,是注册不成功的。

也就是说:不考虑unitName情况下,同一个进程下remotingClient是同一个,而且同一个进程同一个consumerGroup下只能有一个consumer。那么如果是两个不同的进程中的consumer,属于同一个consumerGroup,但是messageModel或者topic、tag这些细节并不一样,会发生什么事情?

一个consumer/producer在启动的时候,引用的那个唯一的MQClientInstance会在定时任务中向所有的broker发出心跳(下一个consumer/producer启动的时候有serviceState做标记),心跳发出的信息中用prepareHeartbeatData方法把所有的consumer和producer的信息发送到broker,到了broker这边,有updateChannel和updateSubscription,前者主要是看channel是不是新注册的(先不管),后者是看当前group下有没有保存所有的这次注册的属于这个group的topic,如果不是,那么updated为true,r2为true,会发出通知,让所有consumer重新负载均衡。

如果同一group下两个consumer(只能在两个不同的服务中)的topic不同,那么就直接进入if (null == prev) ,updated为true。

如果同一个group下两个consumer的topic相同,但是messageModel不同,我们知道广播模式是没有重试的,但是集群模式是有的,所以集群模式会比广播模式多一个retry的topic,如果广播订阅了一个A topic,那么集群就会有retry和A两个,如果当前subscriptionTable只有之前广播模式的那个consumer注册的A topic信息,集群模式的heartbeat过来的时候,会发现retry没有,一样进入if (null == prev) 。反之如果是A topic过来遇到存的是A 和 retry,遇到retry的时候下面的sub.getTopic().equals(oldTopic)就是false,existed为false,一样updated为true。

这样导致的结果就是,任何一个consumer的heartbeat都会导致重新负载均衡,这是效率是很低的。

所以结论就是,同一个group下面的所有consumer,messageModel要一样,所订阅的topic也要一样,至于tag则可以不一样,这样可以使得不同的consumer收到不同的信息,比如手机端的消费者