一、核心概念

RocketMQ 是阿里巴巴开源的分布式消息中间件，采用了生产者-消费者模型，核心架构由四大组件构成：

  • NameServer：轻量级的服务注册中心，提供路由信息
  • Broker：消息存储核心，负责消息的接收、存储和转发
  • Producer：消息生产者，负责发送消息
  • Consumer：消息消费者，负责消费消息

二、架构原理与关键设计

1. NameServer（名称服务）

职责：

  • 存储 Broker 的路由信息（Topic 和 Broker 的映射关系）
  • 接收 Broker 的心跳注册（每30秒）
  • 提供路由发现服务给 Producer 和 Consumer

特点：

  • 各 NameServer 节点互不通信，无状态设计
  • Broker 需向所有 NameServer 节点注册
  • 客户端可连接任意 NameServer 获取完整路由信息
  • 120秒未收到心跳则剔除 Broker

2. Broker（消息服务器）

核心组件：

  • CommitLog：所有消息顺序写入的物理文件（单文件1GB）
  • ConsumeQueue：消息消费的逻辑队列（索引文件，存储 offset、size、tag hash）
  • IndexFile：消息索引文件，支持按 Key 和时间区间查询

架构模式：

  • Master-Slave 模式：
    • 主从同步复制（SYNC_MASTER）或异步复制（ASYNC_MASTER）
    • Slave 可提供读服务，分担 Master 压力
    • Master 宕机后，Slave 可继续提供读服务，但不能写入（4.5.0后支持DLedger自动主从切换）

存储设计：

Broker 存储结构：
├── CommitLog (顺序写)
│   ├── 00000000000000000000
│   └── 00000000001073741824
├── ConsumeQueue (Topic/Queue维度)
│   ├── TopicA
│   │   ├── 0 (队列0)
│   │   └── 1 (队列1)
└── IndexFile (按Key索引)

3. Producer（生产者）

核心机制：

  • 从 NameServer 获取 Topic 路由信息
  • 选择目标 Queue 发送消息（轮询、随机、Hash等策略）
  • 同步/异步/单向发送三种模式
  • 失败自动重试（默认重试2次）

4. Consumer（消费者）

消费模式：

  • 集群模式（Clustering）：同一 Consumer Group 内的消费者负载均衡消费
  • 广播模式（Broadcasting）：每个消费者都消费全部消息

拉取机制：

  • 采用长轮询（Long Polling）方式拉取消息
  • 支持顺序消费和并发消费
  • Offset 存储：集群模式存 Broker，广播模式存本地

三、消息流转过程 

发送流程：
1. Producer 启动时从 NameServer 获取路由信息
2. Producer 根据负载均衡策略选择 MessageQueue
3. 消息顺序写入 Broker 的 CommitLog
4. 异步线程构建 ConsumeQueue 和 IndexFile

消费流程：
1. Consumer 从 NameServer 获取路由信息
2. Consumer 向 Broker 发起长轮询请求
3. Broker 从 ConsumeQueue 查询消息位置
4. 根据位置从 CommitLog 读取消息内容
5. 返回给 Consumer 消费

四、分布式场景考量

1. 高可用保障

  • NameServer 集群：任意节点宕机不影响服务
  • Broker 主从：Master 宕机时 Slave 继续提供读服务
  • DLedger 模式：基于 Raft 协议实现自动主从切换（4.5.0+）

2. 高性能设计

  • 顺序写 CommitLog：磁盘顺序写性能远高于随机写
  • PageCache：利用操作系统页缓存加速读写
  • 零拷贝：使用 mmap + sendfile 减少数据拷贝
  • 异步刷盘：可选同步刷盘（可靠）或异步刷盘（高性能）

3. 可扩展性

  • Broker 分片：Topic 的多个 Queue 可分布在不同 Broker
  • 水平扩展：增加 Broker 节点即可扩容
  • NameServer 无状态：可随意增减节点

五、核心优势总结

特性 说明
性能 单机可达10万+ TPS，延迟毫秒级
可靠性 同步刷盘+同步复制可实现消息零丢失
可用性 主从架构+DLedger自动切换
功能 支持顺序消息、事务消息、延迟消息、消息过滤
运维 轻量级NameServer，无Zookeeper依赖

六、面试要点

  1. 架构组成：四大组件及职责
  2. NameServer 设计：无状态、AP模型、路由发现
  3. Broker 存储：CommitLog顺序写 + ConsumeQueue索引
  4. 主从同步：同步/异步复制、DLedger自动切换
  5. 高性能手段：顺序写、PageCache、零拷贝、异步刷盘

延伸问题：

  • RocketMQ 和 Kafka 的架构有什么区别？
  • CommitLog 和 ConsumeQueue 的设计有什么优势？
  • DLedger 模式是如何实现自动主从切换的？