一、基础概念

1 消息服务器（Broker Server）

消息中转角色，负责存储消息、转发消息。
Broker 在 RocketMQ 中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。
Broker 也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。

Broker包含了以下几个重要子模块：

diff 复制代码

- Remoting Module：整个 Broker 的实体，负责处理来自 Client 端的请求。
- Client Manager：负责管理客户端(Producer/Consumer)和维护 Consumer 的Topic订阅信息。
- Store Service：提供方便简单的API接口处理消息存储到物理硬盘和查询功能。
- HA Service：高可用服务，提供 Master Broker 和 Slave Broker 之间的数据同步功能。
- Index Service：根据特定的 Message key 对投递到Broker的消息进行索引服务，以提供消息的快速查

2 消息生产者（Producer）

负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到 Broker 服务器。
RocketMQ 提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要 Broker 返回确认信息，单向发送不需要。

3 消息消费者（Consumer）

负责消费消息，一般是后台系统负责异步消费。
一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。提供了两种消费形式：拉取式消费、推动式消费。

(1) 拉取式消费（Pull Consumer）

消费消息的应用通常主动调用 Consumer 的拉消息方法从 Broker 服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费逻辑进行消息处理。

(2) 推动式消费（Push Consumer）

消费消息的应用不需要主动调用 Consumer 的拉消息方法，在 RocketMQ 底层已经封装了拉取的调用逻辑，在用户层面看来是 Broker 把消息推送过来的，其实底层还是 Consumer 去 Broker 主动拉取消息。

4 主题（Topic）

表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是 RocketMQ 进行消息订阅的基本单位。

5 名字服务（Name Server）

NameServer 是一个非常简单的 Topic 路由注册中心，其角色类似 Dubbo 中的 zookeeper，支持 Broker 的动态注册与发现。主要包括两个功能：

Broker 管理，NameServer 接受 Broker 集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活。
路由信息管理，每个 NameServer 将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。然后Producer 和 Consumer 通过 NameServer 就可以知道整个 Broker 集群的路由信息，从而进行消息的投递和消费。

NameServer 通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker 是向每一台 NameServer 注册自己的路由信息，所以每一个 NameServer 实例上面都保存一份完整的路由信息。当某个 NameServer 因某种原因下线了，Broker 仍然可以向其它 NameServer 同步其路由信息，Producer 和 Consumer 仍然可以动态感知 Broker 的路由的信息。

二、其他概念

1 分组（Group）

(1) 生产者组（Producer Group）

标识发送同一类消息的Producer，通常发送逻辑一致。发送普通消息的时候，仅标识使用，并无特别用处。
主要作用用于事务消息：事务消息中如果某条发送某条消息的 Producer-A 宕机，使得事务消息一直处于PREPARED 状态并超时，则 Broker 会回查同一个 Group 的其它 Producer，确认这条消息应该 commit 还是 rollback。

(2) 消费者组（Consumer Group）

标识一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。同一个 Consumer Group 下的各个实例将共同消费 topic 的消息，起到负载均衡的作用。
消费进度以 Consumer Group 为粒度管理，不同 Consumer Group 之间消费进度彼此不受影响，即消息A被 Consumer Group1 消费过，也会再给 Consumer Group2 消费。
RocketMQ 支持两种消息消费模式：集群消费（Clustering） 和 广播消费（Broadcasting）。
- 集群消费（Clustering）
RocketMQ 认为任意一条消息只需要被消费组内的任意一个消费者处理即可。集群消费模式适用于每条消息只需要被处理一次的场景，也就是说整个消费组会收到 Topic 的全量的消息，而消费组内的消费分担消费这些消息，因此可以通过扩缩消费者数量，来提升或降低消费能力，具体示例如下图所示，是最常见的消费方式。
- 广播消费（Broadcasting）
广播消费模式适用于每条消息需要被消费组的每个消费者处理 的场景，也就是说消费组内的每个消费者都会收到订阅Topic的全量消息，因此即使扩缩消费者数量也无法提升或降低消费能力，具体示例如下图所示。

二、RocketMQ 的集群架构

集群工作流程：

启动 NameServer，等待 Broker、Producer、Consumer 连接，相当于一个路由控制中心。
Broker 启动，跟所有的 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息(IP+端口等)以及存储所有 Topic 信息。注册成功后，NameServer 集群中就有 Topic 跟 Broker 的映射关系。
收发消息前，先创建 Topic，创建 Topic 时需要指定该 Topic 要存储在哪些 Broker 上，也可以在发送消息时自动创建 Topic。
Producer 发送消息，启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic 存在哪些 Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker 建立长连接从而向 Broker 发消息。
Consumer 跟 Producer 类似，跟其中一台 NameServer 建立长连接，获取当前订阅 Topic 存在哪些Broker 上，然后直接跟 Broker 建立连接通道，开始消费消息。

RocketMQ基本概念