共计 784 个字符，预计需要花费 2 分钟才能阅读完成。
消费者在发送音讯的时候，有一个分组的概念。也就是说，有一个或者多个消费者的名称，是同一个，这些名称一样的消费者，组成了一个生产组。
比方下图中，两个 group_a 是一个生产组，两个 group_b 是一个生产组。
当 broker 有音讯 a 进来的时候，那这个音讯都会同时被这两个生产组所生产。
咱们也看到了每个生产组是有多个消费者的，如果音讯被 group_a 生产的时候，两个消费者是怎么生产的呢？
这里就波及到了集群模式与播送模式两种生产模式。
在集群模式下，这个音讯只能被生产组内一个消费者进行生产。比方 group_a 是集群模式，那此时只能一个消费者进行生产。
在播送模式下，这个音讯会被生产组下的每一个消费者进行生产比方 group_b 是播送模式，那此时两个消费者都进行生产。
生产组和生产模式这么重要，所以消费者启动的时候，就须要去校验生产组和生产模式。
构建 Topic 订阅信息，比方这个消费者须要订阅 TopicTest 的音讯，就是在这里构建的。这个步骤中，Topic 订阅信息是一个 map，所以会存在多个的。
根底信息筹备好了，就开始初始化 MQClientInstance、RebalanceImple（音讯从新负载实现类）。
初始化音讯进度，这里依据生产模式会有两种状况：
一个是集群模式，因为生产组的几个消费者只能一个进行生产，如果这个消费者挂了，那另外一个消费者须要从之前的地位开始生产，所以这个进度不能保留在本地，须要保留在 broker 中，最终从 broker 拉取生产进度。
另外一个是集群模式，消费者的音讯本人保护本人的进度，所以这个进度保留在本人的本地，最终从本地拉取生产进度。
如果音讯是程序生产的，那创立一个程序音讯生产服务，如果不是，则创立并发音讯生产服务，这两个前面来讲细节。
创立好后启动相应的音讯生产服务。
启动消费者客户端，这里的启动跟生产者是一样的，包含音讯从新负载的启动等。
