在公司的技术分享中，就有聊到rocketmq的消费模式，特此总结一下。
广播消费
在说消费之前，这里先说一下rocketmq中group的概念吧，一个group代表的是逻辑相同的一组实例，最可以表达这个概念的是我们将一个项目部署多个实例，那么这个项目的集群就可以称之为一个group。
说完group，再来说说广播消费，在这种模式下，rocketmq会将消息发送给group中的每一个消费者，如果这种模式在公司的项目中，会造成消息重复消费的问题，理论上会有N-1次重复消费，那么rocketmq为什么还会保留这种消费模式呢？存在必有它的道理，比方说，如果需要动态更细一些配置，我们需要在不重启服务的情况下，将新的配置推送给group中的每一个消费者，这时候广播消费就发挥它的独到之处了。
集群消费
集群消费是用的最广泛的一种消费模式，在集群消费模式下，同一条消息，只能被group中的任意一个消费者消费，这个概念很重要，这是与广播消费的最明显区别。
在集群消费模式下，我们的消息只能被消费一次（实际上消息也会重复消费，因为存在网络不稳定因素），rocketmq是怎么实现的呢？
这里我要说一下rocketmq中的队列，在默认情况下，rocketmq会为每个topic在Broker节点上分配若干个队列，查rocketmq手册可知，默认的队列数量是4 （defaultTopicQueueNums: 4），客户端使用长轮询发起请求，和服务端连接上，主动从broker上拉取消息，而每个队列只能由一个消费者监听消费，这样就做到了消息的实时性得到保障，同时保证了消息只有由一个消费者监听消费，这时候问题又来了，消费者是随机拉取消息的吗？
消费者它会随机从broker上拉取消息，且平均分摊消费消息，比方说该topic下有8条消息，其中一个group有2个消费者，那么每个实例只消费其中的4条。
如果用队列来举例，也是成立的，比方说该topic下有4个队列，只有两个消费者，那么第一个消费者消费3条队列，第二个消费者消费2条队列，rocketmq也因此实现了订阅消息的负载均衡特性。rocketmq可以横向扩展消费者数量来提高集群的消费能力，但由于一条队列只能由一个消费者监听消费，多余的消费者将不能消费，所以我们扩展消费者数量的时候，需要注意队列的数量是否大于消费者数量。
我发现rocketmq的源码有必要阅读，我后面会有很多关于rocketmq的一些源码分析，敬请期待。
下面是我自己手画的概念图，很难看，将就着看吧：
