rocketmq 组监听_rocketmq：订阅组和消费组的关系。

之前在没看过源码之前对于 订阅组和消费组没有一个清楚的认知。

今天就来分析下两者的关系。

订阅组：订阅组的创建是依赖于消费组的创建。从订阅组的创建运维命令可以发现。有3个参数是必填(cluster和broker选填一个，最佳实践肯定是选择把cluster给填了)， -n和-c或者-b肯定不用说的，nameserver地址和cluster名称或者broker地址肯定是要填上的，因为在cluster填上的情况下，我们必须借助namerserver去找到对应的cluster下面的所有broker地址才能发送请求给所有的broker去创建对应的订阅组。 接下来就要讲另外一个很关键的参数-g了-----订阅组名。 这个订阅组名设置为必输入选项。那么这个订阅组名要输入什么呢。 答案就是消费组的名字。所以说订阅组的创建是依赖于消费组创建的从这个运维命令行都能够得到答案。

那么究竟订阅组和消费组到底有什么关系呢。且听下面分析。

先来看一看broker的配置参数autoCreateSubscriptionGroup，这个参数是控制是否自动创建订阅组的，默认情况下是开启的。

那么这个参数是在什么地方用的呢？在方法findSubscriptionGroupConfig里用到，那么我们就需要研究下这个方法。

1.首先这个方法是在broker端的。

2.其次这个方法主要是用在处理消费者拉取消息时会用到，client(生产者，消费者的载体)发送心跳会用到，消息消费失败的重试consumerSendMsgBack这三个地方。

那么上述所讲的三地方，如果没开启autoCreateSubscriptionGroup且没有在对应的broker集群(cluster)通过命令行创建对应的订阅组(以消费组的么名称命名)，那么将会导致消费组不能消费在这个broker集群里面创建的topic的相关信息。会被拦截掉。

这边直接返回 而不会走下面的逻辑，这个代码段在处理消费者拉取消息时和消息消费失败的重试consumerSendMsgBack都是在方法体的前面校验部分，校验不通过直接返回。

那么现在应该能清晰的指导订阅组和消费组的关系了。如果某个broker集群没开启autoCreateSubscriptionGroup，某个消费组刚好想消费这个集群上的某个topic信息，那么将会致使无法消费。需要显示通过运维命令行创建对应的消费组的订阅组。

之前在起初学习rocketmq的时候，看到网上有些博客写到autoCreateSubscriptionGroup开启将会导致负载均衡失败，这个应该是有问题的。所以在学习编程的道路上还是应该要知之为知之，将疑惑从源码上解决。 会造成负载均衡失败的应该是设置了自动创建topic为true的情况 详见我上篇博客rocketmq 自动创建topic的过程分析。