RocketMQ 基础模型

RocketMQ 基础模型

基础消息模型 Pub/Sub

Producer 生产者： 生产消息，发送消息到 Broker 对应主题

Topic 主题：位于 Broker 是一类消息的集合，每条消息只能属于一个主题，Topic 是 RocketMQ 订阅的的基本单位

Consumer 消费者： 消费主题中的消息

Broker 中间件：控制消息收发存储，即 RocketMQ

拓展后的消息模型

• 为了消息写入能力的水平扩展，RocketMQ 对 Topic进行了分区，这种操作被称为队列（MessageQueue）。
• 为了消费能力的水平扩展，ConsumerGroup的概念应运而生。

• 相同的ConsumerGroup下的消费者主要有两种负载均衡模式，即广播模式，和集群模式（图中是最常用的集群模式）。
• 在集群模式下，同一个 ConsumerGroup 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅 TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue 1的消息，Consumer2是消费的是MessageQueue2的消息。
• 在广播模式下，同一个 ConsumerGroup 中的每个 Consumer 实例都处理全部的队列。需要注意的是，广播模式下因为每个 Consumer 实例都需要处理全部的消息，因此这种模式仅推荐在通知推送、配置同步类小流量场景使用。

简单说：

一个 Topic 可以分出多个消息队列 MessageQueue ， 生产者可以配置不同的发送策略将消息分散发送到一个 Topic 的不同 MessageQueue 中。

同名的消费者同属于一个组，在集群模式下，RocketMQ 认为同一条消息只需要被一个 Comsumer 消费即可，这个为扩容消费者服务以提升消费能力提供了条件，但这个扩容也不是无限增长的，当消费者多于 MessageQueue 后，消费者服务扩容将不能带来性能提升。

部署模型

实际部署时，为了服务的高可用，基本采用的都是集群的模式。同时增加了服务发现，这个 RocketMQ 自己实现了 NameServer 名字服务，来管理 Broker

NameServer

NameServer是一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。每个 NameServer 都会保存全量的 Broker 信息以及相关路由信息，并与 Broker 建立心跳验证保活。

多实例之间互不通讯，生产者消费者可以从任意一个 NameServer 服务获取完整路由信息。

Broker

在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

• 每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
• Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
• Consumer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。