RocketMQ 消息模型跟其他的消息队列一样 都是 producer - > topic->consumer

producer 生产消息 也就是发送者

topic 消息主题 按 topic 发送消息 以后消息的存储 分片等都是基于 topic 做业务处理的

consumer 消息消费者 也是基于 topic 来进行消息的消费 支持推和拉模式(其实内部都是 pull 模式的变种)。

扩展集群消息模型

为了支持高并发、提高可扩展性、提高消息堆积能力。

一个 topic 可以有多个队列 而且还可以在不同的物理机器，这就为高吞吐、水平扩展支持打了基础。

在消费端 consumer 支持组(group)概念。一组 consumer 里面有多个消费者实例，一组 consumer 来消费某个 topic 这样消费能力就得到了水平扩展

consumer 组支持 集群消费模式 、 广播消费模式

• 集群消费下同组 consumer 实例会去拉取对应 topic 的不同队列上数据进行消费。‘

• 广播模式是每个消费者都会拉取对应 topic 中所有队列的消息来消费。

架构设计

RocketMQ 总体最组件分为 NameServer Broker Porducer Consumer

NameServer 名称服务

NameServer 类似于 Zookeeper 这种角色 负责管理集群组件，简单来说 NameServer 可以查询到 Broker 有哪些、Topic 在哪些 Broker 机器上 队列是如何分布的，它就像一颗大脑 管理者 收集者。相当于是一个 topic 路由管理中心，NameServer 可以多实例分别独立部署、相互之间不产出数据交换，每个 Broker 在启动的时候会向所有的 NameServer 上报信息，所以他们之间可以相互独立，完全无状态。就算挂掉 1 个也不影响集群。

Broker 消息存储代理服务

Broker 才是真正托管消费存储、投递查询的服务，这个是非常核心的服务，大部分的性能优化都是针对这个服务进行。Broker 分为 master slave 角色 在配置文件中 brokerId=0 表示 Master 不为 0 表示 slave。

broker 启动后和 NameServer 建立了长连接 定期向 NameServer 上报 Topic 信息自身信息。

producer 生产者

生产/发送消息服务，一般是程序自己编写的业务发送消息端，启动后首先会和 NameServer 建立连接，定时从 NameServer 获取 Topic 路由信息，定时查询 Broker 服务信息 同时会和 Broker master 角色建立长连接。producer 也是无状态的。

consumer 消费者

消费者服务 一般是由自己业务程序编写实现。启动后和 NameServer 建立连接 定时从 NameServer 获取 topic 信息和 Broker 信息，获取到 Broker 的信息后会和 broker 中的 master salve 角色也建立长连接 所有 consumer 中可以订阅 master 和 slave。

只有非常懂 IO 的人 才能写得出来这么优秀的框架 里面有太多值的学习和借鉴的设计和思想 后面再慢慢精研。