0. 引言
接触rocketmq之后，大家首当其冲的就会发现需要安装3个组件：namesrv, broker, dashboard，其中dashboard也叫console，为选装。而这几个组件之前的关系是什么呢，消息发送和接收的过程是如何传递的呢，这是我们要详细了解的。
1. rocketmq组件架构
rocketmq实际上一共由4个部分组成：namesrv, broker, 生产者, 消费者
而dashboard则是作为单独的管理端存在，目前是为了方便管理、查看队列、topic、集群的情况。所以我们重点放在namesrv, broker的理解上。
1.1 namesrv的作用
namesrv 实际上的一个核心作用就是充当一个注册中心，相当于zookeeper的作用，但是比zookeeper更加轻量，负责broker、路由信息的管理。
namesrv可以部署集群模式，但每个节点都相互独立，并不进行通信，所以也就意味着namesrv每个节点都会存储全量的路由数据，而broker也会向每个namesrv发送注册信息。
broker会每30s向namesrv发送一次心跳包，用于注册和更新自己的路由信息，同时namesrv会与broker保持长连接，每10s发送一次心跳检测，检测broker是否还存活，如果超120s没有响应，则会将该节点剔除。
1.2 broker的作用
broker实际上才是rocketmq的业务处理者，主要负责消息的存储、传递、查询、高可用等。
broker中主要包含以下几个核心模块：
-
Remoting Moudle 远程控制模块：整个 Broker 的实体，负责处理来自客户端的请求
-
Client Manager 客户端管理器：负责管理客户端（生产者、消费者）和维护消费者的主题订阅信息
-
Store Service：提供 API 接口，用以处理消息存储到物理硬盘和查询功能
-
HA Service：高可用服务，提供 Master Broker 和 Slave Broker 之间的数据同步功能
-
Index Service：根据特定的 Message Key 对投递到 Broker 的消息进行索引服务，以提供消息的快速查询
------该段内容引用于：rocektmq核心知识
2. 消息发送流程
2.1 三种发送模式
RocketMQ支持3种消息发送模式：同步 (sync)、异步(async)、单向(oneway)
- 同步发送：
指生产者发送消息后，需要等到broker收到消息后才会返回确认结果给生产者的模式。这种模式中生产者会等到broker返回确认结果后才认定发送结束，如果超时未收到结果则认为发送失败。
所以该种模式，更加适合对可靠性要求更高的场景，且顺序消费就需要通过同步发送实现
- 异步发送：
指生产者发送消息后，不会阻塞等等待broker的确认结果返回了，而是直接返回一个future对象给调用方，生产者会开启一个后台线程异步等待确认结果，最后通过回调函数处理发送结果
这种模式比较明显的好处就是不用阻塞等待，适合对响应时间有要求的场景，同时消息发送的可靠性就降低了，可能会发送失败，这就需要在回调函数中做好补偿操作
- 单向发送：
单向发送更加简单粗暴，即发送完成后就不管后续的结果了，无论发送成功和失败，只要发出则工作就结束。
因此其发送速度是最快速的，同时也是最不可靠的，适合于边缘日志记录、广播通知等场景
其他消息发送拓展
当然rocketmq也支持发送顺序消息、事务消息、延迟消息、批量发送消息等，这些我们将在后续的文章里介绍
2.2 消息发送流程
消息发送的流程主要分成3步：
1、生产者从本地缓存获取指定topic的路由信息（ip、端口等信息）
2、如果本地缓存没有的话，再访问namesrv，更新路由信息到本地缓存，并返回给生产者
3、生产者根据topic的路由信息发送到指定brocker的对应topic，则完成了消息发送
后续消费者再从topic消费消息即可
所以这里再次强调，namesrv本身是不参与消息发送的实际工作的，它的作用就是管理broker、topic的路由信息，为消息发送者发送时提供目标地址
3. 消息消费流程
3.1 两种消费模式
rocketmq 支持两种消费模式：集群消费模式和广播消费模式
- 集群模式：
集群消费模式指的是一条消息仅被同一个消费者组（Consumer Group）中的一个消费者消费（在使用消费者时需要指定一个消费者组名，一个消费者组可以订阅多个Topic），同时所有的消息会被平均分配给每个消费者均匀消费，只是每一次一条消息只会被一个消费者消费。就像我们部署的集群节点，一次请求在负载均衡的作用下，只会交给其中一个节点处理。
该模式适用于对可用性要求较高，则可部署多个消费者，同时要求消息的唯一性，则只能被一个消费者消费的场景
- 广播模式：
广播模式指一条消息能被同一消费者组下的所有消费者消费，就像广播一些，只要播出，所有人都能听到。
该模式适用于订阅服务等需要全体通知的场景。
3.2 两种消费形式
rocketmq 还提供了两种消息形式：pull 拉取和 push推送
- pull 拉取形式：
在pull模式中，消费者主动向Broker拉取消息，主动控制什么时候拉取以及每次拉取的数量。
该模式更适用于需要消费者主动控制的场景
- push 推送形式：
在push模式中，broker主动将消息推送给消费者，消费者不需要再去主动关注消息获取。有消息发送过来后，broker就会将消息推送给消费者。
实际上，rocketmq中并不直接支持push模式，而是通过消费者实时监听topic的形式来实现的。所以实际上也是pull的形式，只不过是通过监听实现不停的pull以此模拟push效果。
该形式更加适合对消费实时性要求较高的场景
3.3 消息消费流程
我们上面说明过rocketmq的push模式实际上也是pull封装实现的，所以其消费流程，我们重点理解pull形式即可。
1、默认情况下，消费者会和一个namesrv保持长连接，如果该namesrv宕机，则自动连接到下一个namesrv，每30s查询topic配置信息并保存到本地缓存，当消费消息时，就会通过本地缓存中的路由信息连接broker。同时消费者每隔30秒会向所有broker发送心跳包，broker以此维护消费者的路由表，该表将作为后续broker做消费者端的负载均衡的依据。
2、消费者启动或者数量发生变化时，会触发消费者端的负载均衡，会根据预设的负载均衡算法来选择队列，然后向broker注册队列绑定，一个topic下会有多个队列，而broker会通过加锁操作来保证一个队列只能被一个消费者绑定。因为广播模式所有的消费者都会收到消息，所以广播模式下没有负载均衡可言，这里的负载均衡主要针对集群模式。
这里需要注意的是：rocketmq的负载均衡实际是通过生产者的负载均衡和消费者的负载均衡共同实现的，生产者负载均衡选择将消息发送到topic下的哪个队列，消费者的负载均衡决定每个消费者绑定消费哪个队列。
3、进行消息消费时，消费者先从本地缓存获取获取topic路由信息，如果本地缓存没有则从namesrv更新一份
4、从本地缓存获取消费进度（即偏移量 offset），本地缓存没有则从broker更新进度到本地缓存
5、根据消费进度拉取最新的消息
6、消费者处理拉取到的消息，处理完成后，向broker发送ACK确认消息已消费
7、消费成功后，消费者会更新自己在broker上的消费进度，以方便下一次消费
4. dashboard的作用
dashboard 是 RocketMQ 的一款开源控制台管理工具，原为rocketmq仓库下的console模块，后独立出来并重命名为dashboard，它提供了一个可视化的界面来管理和监控 RocketMQ 集群。通过 Dashboard，我们可以更方便地查看集群状态、topic信息、生产者和消费者的运行情况，以及进行消息的查询和操作
总而言之，其是用于rocketmq的监控管理可视化平台，在实际生产中极为重要，可以很大程度简化我们的排查、运维工作。
5. 总结
到这里我们就了解了rocektmq中的4个组成：消费者、namesrv、broker、生产者以及他们的作用，以及核心的消息生产、发送流程。下一节，我们再针对rocektmq中的group、topic、tag、queue等概念进行讲解，并梳理清楚他们之间的关系，让大家从基础上理解得更加清晰。