javaroad

Appearance

RocketMQ核心组件 ​

rocketMQ架构.pngrocketMQ存储结构.png

一、NameServer：服务发现与路由中枢 ​

NameServer 是 RocketMQ 的**“导航系统”，负责维护整个集群的服务注册和路由信息**，是连接 Producer、Consumer 和 Broker 的桥梁。

核心作用： ​

  1. 服务注册与心跳维护：
    Broker 启动时，会向所有 NameServer 注册自身信息（如 IP、端口、Topic 列表），并定期发送心跳（默认 30s）。NameServer 若超过 120s 未收到心跳，会将该 Broker 标记为“不可用”，并更新路由表。

  2. 路由查询：
    Producer/Consumer 启动时，会从 NameServer 获取Topic 的路由信息（即该 Topic 分布在哪些 Broker 的哪些 Message Queue 中）。后续发送/消费消息时，直接根据缓存的路由信息与 Broker 交互（无需每次查询 NameServer）。

关键设计： ​

  • 无状态：NameServer 节点间不通信、不同步数据，每个节点独立维护全量路由信息（由 Broker 主动注册保证一致性）。
  • 轻量易扩展：无需共识算法（如 ZooKeeper 的 Paxos），新增节点只需配置 Producer/Consumer 连接即可，故障不影响现有链路（Producer/Consumer 会自动切换到其他 NameServer）。

二、Broker：消息存储与转发核心 ​

Broker 是 RocketMQ 的**“数据节点”，负责消息的接收、存储、持久化、转发**，是整个系统的“心脏”。

核心角色与作用： ​

Broker 分为 Master（可读写）和 Slave（只读，同步/异步复制 Master 数据），多 Master 多 Slave 架构是 RocketMQ 高可用的基础。

  1. 消息存储：
    消息落地到磁盘的三层存储结构（优化读写性能）：

    • CommitLog：全局唯一的顺序写日志文件（所有 Topic 的消息都写入同一 CommitLog），顺序写性能远高于随机写（避免磁盘寻道）。
    • ConsumeQueue：逻辑队列，是 CommitLog 的索引文件（记录消息在 CommitLog 中的位置、Topic、Queue ID 等）。Consumer 拉取消息时，先查 ConsumeQueue 再定位 CommitLog，避免扫描全量日志。
    • IndexFile：可选的索引文件，用于根据消息 Key/UniqueId 快速查询消息（如“根据订单号查消息”）。

  2. 消息转发：

    • 接收 Producer 的消息并写入 CommitLog；
    • 处理 Consumer 的拉取请求（默认 Pull 模式，Push 是封装了 Pull 的“伪 Push”）；
    • 实现 Master 到 Slave 的数据复制（同步复制：Master 等待 Slave 确认后再返回 Producer；异步复制：Master 直接返回，性能更高但可能丢数据）。

  3. 高可用与容灾：

    • 传统 Master/Slave 需手动切换（Master 故障时，将 Slave 升级为 Master）；
    • RocketMQ 4.5+ 支持 DLedger 协议（基于 Raft），实现 Broker 的自动主从切换（DLedger Group 内的节点通过选举产生 Master，故障时 10s 内完成切换）。

  4. 消息生命周期管理：

    • 消息过期自动删除（默认保留 72 小时，可配置）；
    • 清理过期的 CommitLog、ConsumeQueue 文件（避免磁盘撑满）。

三、Producer：消息生产者 ​

Producer 是消息的发送方（如电商系统的“订单服务”），负责将业务消息发送到指定 Topic。

核心能力： ​

  1. 发送方式：

    • 同步发送：等待 Broker 确认后返回（可靠性最高，适合关键消息如“订单创建”）；
    • 异步发送：发送后立即返回，通过回调通知结果（高吞吐量，适合非关键消息如“日志采集”）；
    • 单向发送：不等待任何确认（性能最高，但可能丢消息，适合日志类不敏感消息）。

  2. 负载均衡：
    Producer 会根据 NameServer 返回的路由信息，轮询/随机选择 Topic 的 Message Queue（默认轮询），将消息分散到不同 Broker/Queue，避免单点压力。

  3. 事务消息：
    支持两阶段提交的事务消息（解决“业务操作与消息发送的原子性”问题）：

    • 第一阶段：发送“半消息”（Broker 标记为“待确认”）；
    • 第二阶段：业务操作成功后，发送“确认”指令（Broker 提交消息）；若业务失败，发送“回滚”指令（Broker 删除半消息）。

四、Consumer：消息消费者 ​

Consumer 是消息的接收方（如电商系统的“库存服务”），负责从 Broker 拉取消息并处理业务逻辑。

核心概念与能力： ​

  1. 消费模式：

    • Push 模式（常用）：Consumer 注册监听器，Broker 有新消息时通知 Consumer 拉取（底层是“长轮询”，即 Consumer 向 Broker 发送 Pull 请求，Broker 若没有消息则 hold 住请求，直到有消息或超时）。
    • Pull 模式：Consumer 主动轮询 Broker 拉取消息（更灵活，但需自己处理流控和重试）。

  2. 消费方式：

    • 集群消费（默认）：同一 Consumer Group 的多个 Consumer 分摊消费 Topic 的 Message Queue（每个 Queue 仅被一个 Consumer 消费），消息仅处理一次（适合“订单扣库存”等幂等场景）。
    • 广播消费：每个 Consumer 都消费 Topic 的所有消息（消息被多次处理，适合“通知所有节点更新配置”场景）。

  3. Rebalance 机制：
    Consumer Group 内的 Consumer 会自动分配 Queue（如平均分配、环形分配），当 Consumer 加入/离开时（如扩容、宕机），触发 Rebalance 重新分配 Queue，保证负载均衡。

  4. Offset 管理：

    • 集群消费：消费进度（Offset，即已消费到 Queue 的哪个位置）存储在 Broker 的 ConsumerOffsetManager 中（持久化到磁盘），确保 Consumer 重启后能继续消费。
    • 广播消费：Offset 存储在 Consumer 本地（如文件），因为每个 Consumer 都需要独立记录自己的进度。

五、Topic & Message Queue：消息的逻辑与物理分区 ​

1. Topic（主题）： ​

  • 消息的逻辑分类（如“order_topic”代表订单消息、“log_topic”代表日志消息），是 Producer 发送和 Consumer 订阅的最小单元。
  • 作用：将不同业务的消息隔离，避免混淆。

2. Message Queue（消息队列，简称 Queue）： ​

  • Topic 的物理分区，每个 Topic 可以配置多个 Queue（默认 4 个），分布在不同 Broker 上。
  • 核心作用：
    • 并行处理：多个 Queue 可同时被 Producer 发送或 Consumer 消费，提升吞吐量（如 4 个 Queue 可支持 4 倍并发）；
    • 顺序保证：同一 Queue 内的消息严格 FIFO（全局有序需将 Topic 配置为 1 个 Queue）；
    • 负载均衡：Queue 分布在多个 Broker 上，分散存储和消费压力。

核心组件关系图 ​

Producer → NameServer（查路由）→ Broker（写消息）
Consumer → NameServer（查路由）→ Broker（拉消息）
Broker → NameServer（注册/心跳）

总结：各组件的定位 ​

组件定位核心职责
NameServer导航系统服务发现、路由管理
Broker数据节点消息存储、转发、高可用
Producer消息发送方发送消息、负载均衡、事务支持
Consumer消息接收方拉取消息、消费模式、Rebalance、Offset管理
Topic消息逻辑分类业务隔离
Message QueueTopic的物理分区并行处理、顺序保证、负载均衡

这些组件的设计，共同支撑了 RocketMQ 高吞吐量（百万级 TPS）、低延迟（毫秒级）、高可用（99.99%） 的特性，是其成为阿里、京东等互联网公司核心中间件的关键。