首先来一张网上的rocketMq架构图，让大家直观感受下：
下面我们就这张架构图上的几个主要角色进行介绍：
namesrv集群：namesrv顾名思义，提供的是名字服务，也就是根据某个名字可以查询到对应的路由信息，在rocketMq中，路由信息是broker注册到namesrv上的，并且最终是给producer和consumer用的，producer可以根据topic查出可以往哪些地方发消息，consumer可以根据topic/GID查出应该从哪里拉取消息
namesrv集群由一个或者多个namesrv节点组成，节点之间相互独立，不产生任何通信，broker会向每个namesrv上注册路由信息，所以每个namesrv上都会有完整的路由信息，producer/consumer只会从一个namesrv上查询路由信息，当这台namesrv挂掉后，就换一台
broker集群：负责topic的创建，向namesrv注册路由信息，消息存储，消息查询，消息消费
1).broker集群由一台或者多台master broker和slave borker组成，master broker之间无通信，多个master broker属于数据分片架构，每个topic下的消息会被分配到不同master broker上，生产者在发送指定topic的消息时，会从所有可写queue列表中轮询进行消息发送，这里的queue列表对应于broker向namesrv注册的路由信息中的写队列数，不同能力的master broker机器可以配置不同数量的可写队列数，可以实现消息的权重分配，比如brokerA配置好，配置为10，brokerB配置差点，配置为5，那生产者生产的消息落在AB的比例就为2:1
2).slave broker用于对master broker进行消息同步备份，对外只提供消息读取，不提供消息发送
producer与consumer：生产者与消费者，其实都属于rocketMq的客户端，一个应用程序中往往都是生产者与消费者都有的
1).在namesrv以及broker都启动后，生产者就可以进行启动以及消息发送了，消费者也可以进行启动以及消息订阅了。注意，生产者与消费者也需要一个启动过程才能正常工作，无论是namesrv、broker、生产者或者消费者，都需要在启动时完成一定的准备工作，为后续的工作做准备
topic：主题，一类消息的标识
1).在消息生产与订阅时，都需要指定topic，表示生产哪种消息，以及对哪种消息感兴趣，我们可以通过rocketMq的控制台进行topic的维护
tag：用于topic下的消息过滤
1).如果将topic看做消息的种类，那么tag就是topic下更细粒度的分类，在消息生产与订阅时，除了要指定topic外，tag也同样需要指定
2).关于topic和tag的用法，官网有最佳实践，读者可以参考https://help.aliyun.com/document_detail/95837.html?spm=a2c4g.11174283.6.659.69a0449c3DwW4U。
组：包括生产者组合消费者组，我们主要关注消费者组
1).消费者组指一类Consumer，消费者初始化时需要指定所属的消费者组(groupId)，注意：这类Consumer 要求消费同一类(topic和tag一样)消息，且消息订阅的逻辑一致。可以这样理解：你的项目中有一个消费者，指定的组为group_s，然后你的项目被集群部署在多台机器上，那么这些不同机器上的相同消费者，就属于一个消费者组group_s。
2).rocketMq中消费者组是一个很重要的概念，在集群消费模式下(集群消费下面有介绍)，同一个组内的所有消费者默认会均摊topic下的消息，好处很明显，消费者的消费能力可以横向扩展。
集群消费：rocketMq中一种最常用的消费模式
1).一条消息只能被同一个groupId下的一个Consumer消费(这个很好理解，你的项目集群部署，一条消息你肯定希望只会被消费一次)
2).一个groupId下的所有 Consumer 平均分摊消息。例如你的应用中启动了一个消费者，topic=T1，groupId=GID1 ，你将你的应用部署在三台机器上，那GID1这个消费者组下共三个消费者，如果生产者往T1中发了9条消息，那么每个consumer只会消费到其中的 3 条消息。至于该机制如何实现的，后面会有文章专门叙述
总结：本文为大家讲解了rocketMq中几个角色的分工以及名词介绍，后面会为大家详细展开rocketMq的工作原理