1、核心组件

1. NameServer (命名服务器)
• 角色：轻量级的服务发现与路由中心。你可以把它想象成整个 RocketMQ 的“通讯录”或“注册中心”。
• 功能：
• 服务注册：Broker 在启动时向所有 NameServer 注册自己的信息（主题路由、Broker地址等）。
• 路由管理：为生产者和消费者提供最新的主题（Topic）到 Broker 的映射关系，即“某个Topic的消息存储在哪些Broker上”。
• 特点：
• 无状态：NameServer 节点之间互不通信，每个节点都保存有全量的路由信息。
• 高可用：通常以集群方式部署，但单个节点宕机不会影响整体服务，因为客户端（Producer/Consumer）会连接多个 NameServer。

2. Broker (代理服务器)
• 角色：消息中转站，是消息存储和传递的核心。负责接收生产者发送的消息、存储消息，并为消费者拉取消息提供服务。
• 功能：
• 消息存储：将消息持久化到磁盘（CommitLog）。
• 服务端过滤：根据消费者订阅的标签（Tag）进行消息过滤。
• 高可用保证：通过主从架构（Master-Slave）实现数据冗余，支持同步/异步复制。
• 容错恢复：在Master宕机后，Consumer可以从Slave节点读取消息。

3. Producer (生产者)
• 角色：消息的发送方。业务系统通过调用 Producer 的 API 将消息发送到 Broker。
• 功能：
• 从 NameServer 获取目标 Topic 的路由信息（即知道要发给哪个 Broker）。
• 支持多种发送模式：同步发送、异步发送、单向发送（oneway）。
• 支持将消息发送到特定的 Message Queue（队列），以实现顺序消息。
• 支持事务消息。

4. Consumer (消费者)
• 角色：消息的接收方。从 Broker 拉取消息并将其消费给业务应用程序。
• 功能：
• 从 NameServer 获取目标 Topic 的路由信息（即知道从哪个 Broker 拉取消息）。
• 支持两种消费模式：集群消费（Clustering） 和 广播消费（Broadcasting）。
• Pull 模式：消费者主动从 Broker 拉取消息（RocketMQ 的主要方式）。
• Push 模式：基于 Pull 模式的一种封装，实现一种“长轮询”机制，让用户感觉消息是“推”过来的。
• 支持顺序消费和并发消费。
• 提供消费位点（Offset） 管理，记录消费进度。

1.1 NameServer

• 优点：集群搭建简单。

• 缺点：对于 Broker，必须明确指出所有 NameServer 地址。否则未指出的将不会去注册。也正因为如此，NameServer并不能随便扩容。因为，若 Broker 不重新配置，新增的 NameServer 对于 Broker 来说是不可见的，其不会向这个NameServer 进行注册。

• 服务注册：在Broker节点启动时，轮询NameServer列表，与每个NameServer节点建立长连接，发起注册请求。在NameServer内部维护着⼀个Broker列表，用来动态存储Broker的信息。

• 路由剔除：由于Broker关机、宕机或网络抖动等原因，NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除。NameServer中有⼀个定时任务，每隔10秒就会扫描⼀次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker失效，然后将其从Broker列表中剔除。

• 路由发现：RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由。

1.2 Broker

• Remoting Module：处理客户端的网络请求。

• Client Manager：管理客户端（Producer/Consumer）连接，管理客户端元数据（例如维护 Consumer 的 Topic 订阅信息）

• Store Module：提供消息的物理存储和查询API。

• HA Service：提供主从数据同步功能。

• Index Service：为消息建立索引，支持按 Message Key 或时间区间查询消息。

2、核心概念

1. Topic (主题)
• 消息的逻辑分类，生产者向指定 Topic 发送消息，消费者订阅指定 Topic 来接收消息。

2. Message Queue (消息队列)
• 同一个业务逻辑消息的容器，相当于消息的一级分类
• Topic 的组成部分，是消息存储和传输的实际容器。一个 Topic 可以包含多个 Queue，Queue 是 并行生产和消费的最小单位，也是实现水平扩展和负载均衡的关键。
• 消息通过一定的负载均衡策略被发送到 Topic 下的各个 Queue 中。
• Consumer 的消费线程也是从一个或多个 Queue 中拉取消息。

3. Message (消息)
• 传输的实体。除了消息体（Body），还包含一些属性，如所属 Topic、标签（Tag）、键（Key）等。

4. Consumer Group (消费者组)
• 一组具有相同 Group ID 的 Consumer 实例。消费进度以 Consumer Group 为粒度，一个 Consumer Group 对一个 Topic 进行消费。
• 一个 Consumer Group 可以包括多个 Consumer，一个 Consumer Group 可以订阅多个 Topic。
• 集群消费模式下，同一条消息只会被同一个 Consumer Group 下的一个 Consumer 消费（负载均衡）。
• 这是实现消息广播或集群负载的基础。

5. Producer Group (生产者组)
• 一组具有相同 Group ID 的 Producer 实例。通常用于事务消息场景，在 Broker 端回查事务状态时，可以找到同一组的任何一个 Producer。

6. Tag (标签)
• 相当于消息的二级分类，用于更精细地过滤消息。消费者可以只订阅某个 Topic 下带有指定 Tag 的消息。

7. Offset (消费位点)
• 记录每个 Consumer Group 对每个 Message Queue 的消费进度。RocketMQ 支持客户端管理和 Broker 管理两种方式。客户端管理是以文本文件的形式存储在客户端，而 Broker 管理是将数据保存到 Broker 端。
• 默认情况下，当消费模式为广播模式时，Offset 使用客户端管理，因为每条消息会被所有的消费者消费，每个消费者管理自己的消费进度，各个消费者之间不存在消费进度的交集；当消费模式为集群消费时，Offset 则使用Broker 管理，消息会被多个消费者消费，不同的是每个消费者只负责消费其中部分消费队列

3、整体架构图

3.1 整体工作流

1. 启动：
• NameServer 启动，开始监听端口（默认 9876），等待 Broker、Producer、Consumer连接。
• Broker 启动，和 NameServer 集群中的所有 NameServer 建立并保持长连接，注册自己的路由信息，并保持定时心跳。
• Producer 和 Consumer 启动，和 NameServer 集群中的其中一个（随机） NameServer 建立长连接， 拉取路由信息，并定时更新。

2. 发送消息：
• Producer 根据从 NameServer 获取的路由信息，知道要发送的 Topic 消息应该存储在哪个 Broker 上。
• Producer 通过负载均衡策略（如轮询）选择该 Topic 下的一个 Message Queue，将消息发送到对应的 Broker。

3. 存储消息：
• Broker 接收到消息，将其持久化到磁盘的 CommitLog 中。
• 如果是主从模式，Master Broker 会将消息异步或同步地复制到 Slave Broker。

4. 消费消息：
• Consumer 从 NameServer 获取路由信息，知道要消费的 Topic 消息存储在哪些 Broker 上。
• Consumer 通过负载均衡策略，分配自己应该从哪些 Message Queue 拉取消息（集群模式下，一个Queue同一时间只能被一个Consumer消费）。
• Consumer 连接到对应的 Broker（Master或Slave）拉取消息进行消费，并提交消费位点（Offset）。

3.2 各组件的连接关系

• Broker 与 Name Server 的关系
• 连接：每个 Broker 与 Name Server 集群中的所有节点建立长连接
• 心跳：Broker 定时(每隔30s)注册 Topic 信息到所有 Name Server。
• 心跳超时：Name Server 定时（每隔10s）扫描所有存活 Broker 的连接，如果 Name Server 超过 2 分钟没有收到心跳，则 Name Server 断开与 Broker 的连接。一旦连接断开，会更新 Topic 与队列的对应关系，但不会通知生产者和消费者。

• Produder 与 NameServer 的关系
• 连接：Producer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接。
• 心跳：无心跳
• 轮询：Producer 每隔 30s 从 Name Server 获取所有 Topic 队列的最新情况，这意味着如果 Broker 不可用，Producer 最多 30s 能够感知，在此期间内发往 Broker 的所有消息都会失败。

• Produder 与 Broker 的关系
• 连接：与提供 Topic 服务的 Broker Master 建立长连接。
• 心跳：Producer 每隔 30s（由 ClientConfig中heartbeatBrokerInterval决定）向所有关联的 Broker 发送心跳，Broker 每隔 10s 中扫描所有存活的连接，如果 Broker 在 2 分钟内没有收到心跳数据，则关闭与 Producer 的连接。

• Consumer 与 NameServer 的关系
• 连接：Consumer 与 Name Serve r集群中的其中一个节点（随机选择）建立长连接。
• 心跳：无心跳
• 轮询：Consumer 每隔 30s 从 Name Server 获取 Topic 的最新队列情况，这意味着 Broker 不可用时，Consumer 最多最需要 30s 才能感知。

• Consumer 与 Broker 的关系
• 连接：与提供 Topic 服务的 Broker Master 和 Broker Slave 建立长连接。Consumer 既可以从 Master 订阅消息，也可以从 Slave 订阅消息，订阅规则由 Broker 配置决定。
• 心跳：Consumer 每隔30s（由 ClientConfig中heartbeatBrokerInterval 决定）向所有关联的 Broker 发送心跳，Broke r每隔 10s 扫描所有存活的连接，若某个连接 2 分钟内没有发送心跳数据，则关闭连接；并向该 Consumer Group 的所有 Consumer 发出通知，Group 内的 Consumer 重新分配队列，然后继续消费。

• 防火墙设置：为确保通信，需要在防火墙或安全组中放行上述相关端口。NameServer (9876) 和 Broker (如 10911、 10909) 的端口必须开放。Dashboard (8080)、Proxy (8081) 等则根据实际访问和管理需求决定。

• 关于 Broker 的 10909 和 10911 端口：
• 10911 是 Broker 的 主监听端口，负责处理所有类型的客户端请求，包括生产者发送消息和消费者拉取消息。
• 10909 是 Broker 的 FastRemotingServer 端口，主要用于提升生产者发送消息的响应速度，通常不处理消费者拉取消息的请求。它默认是主监听端口减2（如 10911 - 2 = 10909）。
• 此外，Broker 主从同步（HA）默认使用 10912 端口（即 listenPort + 1）。

4、核心特性在架构中的体现

1. 高可用 (High Availability)
• NameServer：多节点部署，单个节点宕机无影响。
• Broker：采用主从（Master-Slave）架构。Master 宕机后，Consumer 可以自动切换到 Slave 读取，保证消息可读（但可能短暂不可写）。支持 Dledger 模式实现自动主从切换（Raft协议）。

2. 高可靠 (High Reliability)
• 消息持久化：所有消息都会刷盘持久化（支持同步刷盘和异步刷盘模式）。
• 数据复制：主从节点间进行数据复制（支持同步复制和异步复制模式），防止单点故障导致数据丢失。

3. 可伸缩性 (Scalability)
• Broker 水平扩展：一个 Topic 的消息可以分布在多个 Broker 的多个 Queue 上。当容量不足时，可以通过增加 Broker 并为主题增加 Queue 数量来实现水平扩容。
• Consumer 水平扩展：由于 Queue 是消费的最小单位，可以通过增加 Consumer 实例数量来提高消费能力（Consumer数量不应超过订阅Topic的Queue总数）。