1、发布订阅模型
几乎所有主流MQ产品，都是发布订阅模型（Pub/Sub模型），是生产者和消费者进行基于主题Topic的消息传送
在这个模型的基础上，RocketMQ又做了扩展，以下为两个生产者、两个topic、两个消费者组、两个Broker节点的示意图：
- 生产者Producer发送消息
- 发送到Topic A的消息，又进行了分区，比如上面分到了三个队列Queue0、Queue01、Queue02上
- 消息存储在Broker节点的队列上
- 同一个消费者组ConsumeGroup下，可以有多个消费者实例，以扩展对消息的消费能力
- 同一个ConsumeGroup的实例，可选广播模式和集群模式来消费消息
集群模式，即上图中的模式，ConsumeGroup A订阅了Topic A，Topic A又对应了三个队列，而Group
A下的实例Consume 1消费了Queue 0和Queue 1中的消息，Consume 2 则消费的是Queue2中的消息
广播模式，则是一个ConsumeGroup下的每个实例，都要处理一遍全部的队列
可以看到，广播模式下，每个消费者实例，都需要处理全部的消息
2、角色
以4.x版本为例，主要包括以下角色：
- 生产者Producer：生产者从Nameserver获取Topic路由信息，把消息发送到对应的Broker节点
- 消费者组ConsumerGroup：包含多个消费者实例，有push和pull两种模式获取消息，有广播和集群两种方式消费消息
- 代理服务器Broker：翻译，经纪人，干活儿的，负责消息的存储、投递、查询
- 如果Broker有多个节点，或者部署在多台服务器上时，它们之间如何互相知道对方的存在 ⇒ NameServer
- 命名服务器NameServer：接受Broker路由信息topic-queue-broker的注册，供生产者和消费者进行消息投递和消费，并通过Broker发送的心跳检测Broker是否存活
3、工作流程
1）NameServer启动
启动NS，NS启动后监听对应端口，等待Broker、Producer、Consumer来连接
2）Broker启动
Broker启动后，与所有的NS节点保持长连接，定时发送心跳包，心跳包中就有Broker自身信息 + 其上Topic的信息
3）生产者发送消息
生产者实例启动后，发消息时，需要知道它消息的这个topic要往哪个broker发，因此，先跟NS集群的其中一个节点建立长连接，并获取消息要发的topic都分布在哪些Broker节点上，选择一个后，与对应的Broker建立长连接，将消息直接发送到对应的Broker
4）消费者接收消息
消费者实例启动后，跟NS集群的其中一个节点建立长连接，并获取订阅的topic都分布在哪些Broker节点上，根据消费配置，与对应的Broker建立长连接后消费消息
补充：
- NameServer无状态，集群部署时，各个NameServer实例之间不需进行通信和数据同步，。Broker是向每一台Nameserver注册自己的路由信息，即每个NameServer实例上都有一份完整的路由信息，因此，即使某个NS实例挂了，也不影响生产者或者消费者获取broker路由信息
- Broker向NameServer注册的Topic路由信息，是Topic- queue- broker三部分，即主题信息、每个topic下的队列的属性信息（比如队列数量）、broker的IP信息
- Broker主从架构集群部署时，Mater节点和Slave节点，通过相同的BrokerName来关联起来，且BrokerId等于0的是Master节点，BrokerId非0的是Slave节点
4、RocketMQ的架构
4.1 RocketMQ4.x版本
| 组件或数据流 | 说明 |
|---|---|
| Namesrver | 无状态服务，负责保存Topic路由信息 Topic路由信息=topic-queue-broker |
| Broker | 有状态服务，处理计算和存储 计算 = 处理生产者请求，消费者请求，管理请求，Broker系统服务（比如索引构建服务，消息过期服务） 存储 = 消息存储，索引存储 |
| Broker -> Namesrver | Broker定期把Broker信息+当前Broker中的Topic信息上报Namesrver |
| 生产者 | 生产消息 |
| 生产者<-> Namesrver | 生产者从Namesrver获取Topic路由信息，包含Broker IP |
| 生产者<-> Broker | 生产者通过Topic路由信息，把消息直接发送给对应的Broker实例 生产者定期和Broker心跳，上报当前生产者实例信息 |
| 消费者 | 消费消息 |
| 消费者<-> Namesrver | 消费者从Namesrver获取Topic路由信息， 包含Broker IP |
| 消费者 <-> Broker | 消费者通过Topic路由信息，从指定Broker中拉取消息消费 消费者定期和Broker心跳，上报当前消费者实例信息 |
4.2 RocketMQ5.0版本
相比4.x，5.0版本：
- 引入了Controller 组件，负责Broker的故障转移（Master选举）
- 引入了Proxy组件，无状态服务，充当了客户端与 Broker 之间的中介，处理客户端请求并转发到相应的 Broker
| 组件或数据流 | 说明 |
|---|---|
| Namesrver | 无状态服务，负责保存Topic路由信息 Topic路由信息=topic-queue-broker 在5.0.0时，Nameserver进程中可以嵌入Controller模块，若设置enableControllerInNamesrv=true，在Nameserver进程中嵌入启动一个Controller实例 |
| Broker | 有状态服务，处理计算和存储 计算 = 处理生产者请求，消费者请求，管理请求，Broker系统服务（比如索引构建服务，消息过期服务） 存储 = 消息存储，索引存储 在5.0.0时， Broker支持主从切换，Broker的角色包含：master，slave，learner 若设置asyncLearner=true，则Broker为learner，只同步数据， 不参与选举master |
| Broker -> Namesrver | Broker定期把Broker信息+当前Broker中的Topic信息上报Namesrver |
| TCP生产者 | 生产消息 |
| TCP生产者<-> Namesrver | 生产者从Namesrver获取Topic路由信息，包含Broker IP |
| TCP生产者<-> Broker | 生产者通过Topic路由信息，把消息直接发送给对应的Broker实例 生产者定期和Broker心跳，上报当前生产者实例信息 |
| TCP消费者 | 消费消息 |
| TCP消费者<-> Namesrver | 消费者从Namesrver获取Topic路由信息， 包含Broker IP |
| TCP消费者 <-> Broker | 消费者通过Topic路由信息，从指定Broker中拉取消息消费 消费者定期和Broker心跳，上报当前消费者实例信息 |
| Controller(控制器) | 5.0.0新增，负责Broker Master的选举并将结果通知Broker |
| Broker <-> Controller | Broker定期把Broker信息上报Controller Controller选举新的Broker Master后，通知全部Broker |
| Proxy | 5.0.0新增，无状态服务，新客户端通过Grpc接口访问Proxy进行收发消息 Proxy中支持嵌入Broker 若设置proxyMode=LOCAL，则会在Proxy进程中启动一个Broker实例 |
| Proxy <-> Broker | 5.0.0新增，Proxy通过Remoting协议和Broker通信，可以把Proxy当作一个Remoting的Client |
| Proxy <-> Namesrver | Proxy 通过 NameServer 获取 Broker 的元数据信息，将请求路由到适当的 Broker |
| 新Client | 5.0.0新增，新客户端，目前支持Grpc协议 |
| 新Client <-> Proxy | 新客户端访问Proxy进行收发消息 |
相比4.x，5.0增加了新协议和组件，是一次扩充，更加云原生。5.x版本有两种部署模式：
- 在 Local 模式下，Broker 和 Proxy 是同进程部署，只是在原有 Broker 的配置基础上新增 Proxy 的简易配置就可以运行，Local模式下 Broker 和 Proxy之间的通信属于进程间通信，性能比较好，响应时间比较短
- 在 Cluster 模式下，Broker 和 Proxy 分别部署，即在原有的集群基础上，额外再部署 Proxy 即可