【RocketMQ】二、架构与核心概念

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 即可