RocketMQ 架构设计：NameServer/Broker/Producer/Consumer 角色
提出问题
RocketMQ 是阿里巴巴开源的分布式消息中间件，在金融、电商、IoT 等场景广泛应用。面试官问"RocketMQ 架构组件"时，表面上考你会不会背组件名称，实际上在考察三个层次：第一层——是否清楚每个组件在整体链路中的具体职责和数据流动；第二层——是否理解 NameServer 这种"去中心化注册中心"的设计哲学（和 ZK/Etcd 有什么区别）；第三层——架构设计是否触碰过真实生产问题，比如 NameServer 宕机后 Broker 是否还能收发消息、CommitLog 和 ConsumeQueue 的双写设计解决了什么问题。
生产上最典型的场景是：新接手一套 RocketMQ 集群，发现 Consumer 频繁触发 Rebalance，排查下来是 NameServer 路由信息不一致导致的——Consumer 获取到的 Queue 分配方案在多个 NameServer 之间不一致，触发了不必要的重平衡。这时候如果对架构理解不透彻，排查方向就完全跑偏。
分析问题
NameServer：轻量级路由注册中心
RocketMQ 没有选择 ZooKeeper 或 Etcd 作为注册中心，而是自研了 NameServer 组件。NameServer 的设计理念是 "牺牲一致性，换取可用性和简单性"。
架构数据流：
Producer/Consumer ──轮询──→ NameServer[0] ──(内存路由表)──→ Broker Master
├──→ NameServer[1] ──(内存路由表)──→ Broker Slave
└──→ NameServer[...]
↑
│ (每30s心跳)
BrokerNameServer 节点之间不互相通信，不存在选举、数据同步等复杂逻辑。Broker 启动时向所有配置的 NameServer 注册自身信息，随后每隔 30 秒发送一次心跳。NameServer 如果 120 秒内未收到某个 Broker 的心跳，则认为该 Broker 已宕机，将其从路由表中剔除。
为什么不用 ZK/Etcd？
| 特性 | ZooKeeper | Etcd | NameServer |
|---|---|---|---|
| 一致性 | 强一致性（ZAB） | 强一致性（Raft） | 最终一致性 |
| 节点通信 | 选举、Leader 选举 | 选举、Raft 日志复制 | 无 |
| 部署要求 | 奇数节点（3/5/7） | 奇数节点（3/5/7） | 2 台即可 |
| 故障恢复 | 重新选举（秒级） | 重新选举（秒级） | 无需选举，立即可用 |
| 运维复杂度 | 高（需要 ZooKeeper 专家） | 中 | 低（几乎无需运维） |
RocketMQ 的设计师认为：消息队列的路由信息不需要强一致性。Topic 路由信息短暂不一致（最长 30 秒）不会导致数据丢失，Producer 最多发错一次 Broker 地址，重试即可。但用 ZK 的代价是引入了一个复杂的分布式系统，部署、运维、故障排查成本都大幅上升。
NameServer 的有状态重启问题：NameServer 重启后内存路由信息丢失，直到 Broker 下一次心跳上报（最长 30 秒）才恢复。这段时间内新启动的 Producer 拿不到路由，消息发送失败。解决方案：NameServer 至少部署 2 台，客户端配置多个 NameServer 地址做兜底，同时 Broker 配置 heartbeatInterval=10000 缩短心跳间隔。
// Producer 初始化时配置多个 NameServer 地址
DefaultMQProducer producer = new DefaultMQProducer("producer_group");
producer.setNamesrvAddr("192.168.1.1:9876;192.168.1.2:9876");
producer.start();
// 底层 NameServer 选择逻辑（简化）
public class NamesrvAddrChooser {
private final String[] addrList;
private final AtomicInteger index = new AtomicInteger(0);
public String pickOne() {
// 轮询选择，如果第一个连不上会自动切换
return addrList[index.getAndIncrement() % addrList.length];
}
}NameServer 的四个核心接口（面试可能追问）：
updateTopicRouteInfoFromNameServer()— 客户端定时（默认 30s）从 NameServer 拉取路由更新registerBroker()— Broker 向 NameServer 注册自己unregisterBroker()— Broker 优雅关闭时注销getRouteInfoByTopic()— 客户端根据 Topic 获取 Broker 地址列表
Broker：消息存储与主从架构
Broker 是 RocketMQ 的核心节点，负责消息的存储、投递、高可用。每个 Broker 节点分为 Master 和 Slave 两种角色。Master 负责读写，Slave 负责从 Master 同步数据并提供读服务。
消息存储双写流程：
Producer 发送消息
│
▼
Broker Master 接收
│
├──→ 1. 写入 CommitLog（顺序追加，单文件）
│ CommitLog 文件结构：
│ ┌─────────────────────────────────────┐
│ │ Msg1: Topic=order, Body=xxx, tags=...│
│ │ Msg2: Topic=pay, Body=yyy, tags=...│
│ │ Msg3: Topic=order, Body=zzz, tags=...│
│ │ ...（所有 Topic 混在一起顺序写） │
│ └─────────────────────────────────────┘
│
├──→ 2. 异步线程构建 ConsumeQueue（每个 Topic 每个 Queue 独立文件）
│ ConsumeQueue(order-queue-0):
│ ┌──────────────────────────────────┐
│ │ Offset: 0, Size: 200, TagCode: xx│
│ │ Offset: 800, Size: 150, TagCode: xx│
│ └──────────────────────────────────┘
│
└──→ 3. 主从同步（ASYNC_MASTER 或 SYNC_MASTER）
└──→ Slave 写入自己的 CommitLog所有消息顺序写入 CommitLog 文件——一个单文件，所有 Topic 的消息混在一起写。这种设计保证了磁盘顺序写的高吞吐（机械盘也能达到 600MB/s 以上，SSD 可达 2GB/s 以上）。同时，异步线程从 CommitLog 中解析出消息，构建 ConsumeQueue——每个 Topic 的每个 Queue 对应一个 ConsumeQueue 文件，记录消息在 CommitLog 中的偏移量和大小。这种双写设计解决了"既要高性能写入，又要对不同 Topic 独立消费"的矛盾。
为什么 CommitLog 不按 Topic 分文件？ 如果每个 Topic 写独立文件，随机写会严重降低磁盘性能。按 Topic 混合写 CommitLog 保证了顺序写，异步构建 ConsumeQueue 实现按 Topic 消费。这是典型的"写时不分，读时分"设计。
CommitLog 文件滚动机制：CommitLog 单个文件默认 1GB（mapedFileSizeCommitLog=1073741824），写满后自动创建新文件。文件名以起始偏移量命名，例如 00000000000000000000、0000000000001073741824。这种命名方式的好处是：可以根据偏移量快速定位消息所在的文件，不需要维护额外的索引。RocketMQ 默认保留 72 小时的 CommitLog（fileReservedTime=72），到期后自动删除。生产上遇到过磁盘写满事故——业务方突增消息量导致 CommitLog 写入速度翻倍，72 小时的保留策略下磁盘空间不够。解决方案：根据写入量反算保留时间，例如 fileReservedTime=24 只保留 24 小时，或者加大磁盘到 2TB。
三种刷盘策略对比：
| 策略 | 写入确认时机 | 吞吐量 | 断电丢数据 | 适用场景 |
|---|---|---|---|---|
| 同步刷盘（SYNC_FLUSH） | 写入磁盘后才返回 | 低（约 1-2 万 TPS） | 不丢 | 金融交易、对账 |
| 异步刷盘+同步复制（默认推荐） | 写入 Page Cache 后返回，Master 同步到 Slave 后确认 | 中（约 5-10 万 TPS） | 不丢（Broker 宕机有 Slave 兜底） | 大多数生产场景 |
| 异步刷盘+异步复制 | 写入 Page Cache 后立即返回 | 高（约 10-20 万 TPS） | 可能丢（Page Cache 未刷盘 + Master 宕机） | 日志、监控等可丢数据 |
# Broker 配置示例
brokerClusterName = DefaultCluster
brokerName = broker-a
brokerId = 0 # 0 = Master, >0 = Slave
flushDiskType = ASYNC_FLUSH # 异步刷盘，选 SYNC_FLUSH 则同步
# 主从同步方式
brokerRole = ASYNC_MASTER # 异步复制，选 SYNC_MASTER 则为同步双写主从切换的坑：brokerRole=ASYNC_MASTER 时，Master 宕机后 Slave 不会自动升为 Master。需要手动执行 mqadmin updateBrokerConfig 或通过运维脚本切换。生产上遇到过凌晨 2 点 Master 挂了，值班同学不知道这个机制，等了 10 分钟服务没恢复才发现问题。建议生产环境用 SYNC_MASTER 配合至少 2 个 Slave，或者用 RocketMQ 5.x 的 Controller 模式实现自动切换。
Producer：发送策略与可靠性
Producer 从 NameServer 获取 Topic 的路由信息后，根据负载均衡策略选择目标 Broker 和 Queue 发送消息。RocketMQ 支持三种发送模式，每种模式有明确的性能指标：
// 三种发送方式的代码示例
DefaultMQProducer producer = new DefaultMQProducer("pg");
producer.setNamesrvAddr("192.168.1.1:9876");
producer.start();
// 1. 同步发送（TPS 约 1-3 万，单条延迟 5-50ms）
SendResult syncResult = producer.send(new Message("topic", "sync".getBytes()));
System.out.println("Send status: " + syncResult.getSendStatus());
// 2. 异步发送（TPS 约 5-10 万，单条延迟 1-5ms）
producer.send(new Message("topic", "async".getBytes()),
new SendCallback() {
@Override
public void onSuccess(SendResult result) {
System.out.println("Async send OK: " + result.getMsgId());
}
@Override
public void onException(Throwable e) {
System.out.println("Async send failed: " + e.getMessage());
}
});
// 3. Oneway 发送（TPS 约 10-20 万，无返回值）
producer.sendOneway(new Message("topic", "oneway".getBytes()));发送重试机制：默认重试 2 次（共尝试 3 次），每次重试切换到不同的 Broker。如果所有 Broker 都失败，抛出 MQClientException。send 方法有个隐参 timeout（默认 3 秒），超时也会触发重试。生产上遇到过 3 秒不够的情况——消息体 1MB 以上，网络延迟高，超时导致重复发送。解决方案：producer.setSendMsgTimeout(5000)，根据消息体大小调整。
10 万 QPS 压测实战：某次双 11 压测，目标 10 万 TPS 写入，8 个 Broker（4 Master + 4 Slave），每个 Master 对应 8 个 Queue。压测过程中发现 5 万 TPS 时 Producer 端就开始大量超时。排查过程：
- 先用
jstack看 Producer 线程状态，大量线程卡在SocketTimeoutException上 - 检查 Broker 端 CPU，发现
flushConsumeQueueService线程占用 60% CPU——这是异步构建 ConsumeQueue 的线程 - 进一步发现每个 Topic 的 Queue 数量太多（16 个），导致 ConsumeQueue 文件 IO 竞争
- 优化方案：每个 Topic 的 Queue 缩减到 8 个，同时
flushIntervalConsumeQueue从 1000ms 调到 500ms，减少刷盘延迟 - 调整后 10 万 TPS 稳定跑通，Producer 端 P99 延迟从 200ms 降到 50ms
关键参数调优清单（面试可能追问）：
sendMessageThreadPoolNums：Broker 处理 Producer 请求的线程数，默认 16 个，高并发场景建议 32-64putMessageFutureThreadPoolNums：异步写入线程数，默认 4 个，建议和 CPU 核数一致maxMessageSize：默认 4MB，传大文件（如 10MB 图片）需要调大，但注意网络带宽限制osPageCacheBusyTimeOutMills：Page Cache 忙等待超时，默认 1000ms，高并发场景改为 500ms 减少堆积
Producer 端负载均衡策略：默认轮询（Round Robin）分配 Queue，使用 MessageQueueSelector 可以实现自定义策略（如根据订单 ID 选择固定 Queue，保证顺序消息）。
// 消息队列选择器：保证同一个订单的消息进入同一个 Queue
producer.send(message, new MessageQueueSelector() {
@Override
public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
String orderId = (String) arg;
int index = Math.abs(orderId.hashCode()) % mqs.size();
return mqs.get(index);
}
}, orderId);Consumer：Push 模式本质是长轮询
Consumer 从 NameServer 获取路由信息后，连接到目标 Broker 消费消息。RocketMQ 的 Push 模式本质上不是真正的 Push——Broker 不会主动推送消息，而是 Consumer 发起长轮询请求。
长轮询时序：
Consumer Broker
│ │
│── PullRequest ────────→│ (Consumer 发起拉取请求)
│ │
│ ├── 有消息？立即返回
│ ├── 没消息？挂起请求（默认 15s）
│ │ ┌─ 15s 内新消息到达 → 立即响应
│ │ └─ 15s 无消息 → 返回空响应
│←────── Response ───────│
│ │
│── 下一轮 PullRequest ──→│ (Consumer 再次发起)为什么不用真正的 Push？ 真正的 Push 需要 Broker 维护 Consumer 的连接状态、消费能力、背压控制，复杂度太高。长轮询的优点是：Consumer 控制消费速率，Broker 不需要维护 Consumer 状态，实现简单可靠。
消费模式：
- 集群消费（默认）：Queue 负载均衡到 Consumer 组内各实例，一条消息被消费一次。适用于大多数场景。
- 广播消费：每个实例消费全部消息。适用于每个实例都需要完整数据的场景（如配置同步）。
Rebalance 机制：当 Consumer 上下线、Topic 扩容/缩容时，触发 Rebalance 重新分配 Queue。RocketMQ 默认使用平均分配策略（AllocateMessageQueueAveragely），将 Queue 尽可能均匀地分配到各个 Consumer。
Rebalance 触发条件（面试高频）：
- Consumer 实例上下线（20 秒内无心跳即触发）
- Broker 宕机或恢复
- Topic 的 Queue 数量变更
- Consumer Group 订阅关系变更
Rebalance 的坑：Rebalance 期间 Consumer 获取到新的 Queue 分配方案后，会先暂停旧 Queue 的消费，然后开始新 Queue 的消费。这个过程会导致短暂的消息堆积（通常几十毫秒）。如果 Consumer 处理时间长，Rebalance 频繁触发，可能出现"边消费边 Rebalance"的死循环——消费太慢导致在 Rebalance 窗口内未完成，触发新一轮 Rebalance。生产上遇到过 Consumer 的 consumeTimeout 设了 30 分钟（处理大消息），但 Rebalance 的默认超时是 15 秒，导致永远无法完成 Rebalance。解决方案：处理大消息时用异步回调，不要在 consumeMessage 里同步阻塞太久。
// Consumer 创建示例
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumer_group");
consumer.setNamesrvAddr("192.168.1.1:9876");
consumer.subscribe("topic", "*");
// 默认是集群消费，无需显式设置
// 切换为广播消费：
// consumer.setMessageModel(MessageModel.BROADCASTING);
consumer.registerMessageListener((MessageListenerConcurrently) (msgs, context) -> {
for (MessageExt msg : msgs) {
System.out.printf("Consume: %s %n", new String(msg.getBody()));
}
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});
consumer.start();面试连环追问（高频）
1. NameServer 挂了 Broker 还能发消息吗？
能，但有限制。Producer 启动时从 NameServer 拉取的路由信息缓存在本地，缓存的 topicPublishInfoTable 默认有效期 30 秒。如果 Producer 已经启动且缓存未过期，即使所有 NameServer 宕机，Producer 仍然可以继续向已知的 Broker 发送消息。但新启动的 Producer 无法获取路由，发消息会失败。所以 NameServer 挂了不影响已有客户端，影响的是新客户端和动态扩容。
2. CommitLog 和 ConsumeQueue 的过期清理怎么配合？
CommitLog 文件写满 1GB 后不再追加，标记为可清理。但清理前必须确认该文件内所有消息对应的 ConsumeQueue 条目已经被消费过。RocketMQ 通过 ConsumeQueue 中的 maxOffset 和 Consumer 的消费进度 consumerOffset 来判断：当一个 CommitLog 文件中的所有消息都被消费完成后，该文件才进入待清理队列。默认 72 小时后强制清理，不管是否消费完。
3. RocketMQ 为什么能保证消息不丢失？
三个层面：
- Producer 端：同步发送 + 重试 2 次 + Broker 返回确认（
SendStatus.SEND_OK） - Broker 端：同步刷盘或同步复制 + CommitLog 顺序写 + 主从同步
- Consumer 端：消费完成后才确认（
CONSUME_SUCCESS），未确认的消息会重试
真正丢消息只有一种情况：异步刷盘+异步复制下，Master 写入 Page Cache 后宕机，同时 Slave 未同步——此时 Master 重启后 Page Cache 中的数据丢失。解决方案：至少用异步刷盘+同步复制。
4. RocketMQ 5.x Controller 模式怎么选主？
5.x 引入基于 Raft 的 Controller 模式，Broker 分为两阶段：先通过 Controller 选举出 Master，然后 Slave 从 Master 同步数据。相比之前的 ASYNC_MASTER 模式，Controller 模式支持自动故障切换，Master 宕机后 Controller 自动将 Slave 提升为 Master。部署方式：Controller 3 节点（Raft 多数派），Broker 节点注册到 Controller。
总结
RocketMQ 架构设计的核心哲学：用"最终一致性"换取"简单性"和"高性能"。
| 组件 | 关键设计 | 面试话术示例 |
|---|---|---|
| NameServer | 最终一致性、无状态、无通信 | "NameServer 不互相通信，通过 Broker 定时心跳保证最终一致，牺牲了强一致性但换来了超高可用和简单运维" |
| Broker | CommitLog + ConsumeQueue 双写 | "所有消息顺序写 CommitLog 保证高性能，异步构建 ConsumeQueue 实现按 Topic 独立消费" |
| Producer | 三种发送模式 + 自动重试 | "同步发送保证可靠性，异步发送保证吞吐，Oneway 极致性能；发送失败自动重试 2 次" |
| Consumer | Push 本质是长轮询 | "Push 模式是长轮询的封装，不是真的推；集群消费下 Rebalance 负责 Queue 分配" |
生产避坑清单（每一条都踩过）：
- NameServer 至少 2 台，客户端配置多个地址，
heartbeatInterval缩短到 10 秒减少窗口期 brokerRole=ASYNC_MASTER时 Master 宕机后 Slave 不自动升 Master，建议用SYNC_MASTER或 RocketMQ 5.x ControllerflushDiskType=SYNC_FLUSH在高吞吐场景下几乎不可用，双 11 级别的压测用 ASYNC_FLUSH + 多副本- Producer 的
sendMsgTimeout默认 3 秒，大消息体（>1MB）需要调大，否则超时导致重复重试 - Consumer 处理大消息时不要用同步阻塞，
consumeTimeout和 Rebalance 超时（15s）冲突会导致死循环 - Rebalance 频繁触发时检查 Consumer 心跳是否正常，可能是有 Consumer 实例在"假死"（进程存活但线程卡死）
- CommitLog 的
fileReservedTime默认 72 小时，突发流量下可能撑爆磁盘，根据实际写入量反算 - Topic 的 Queue 数量不是越多越好，Queue 过多导致 ConsumeQueue 文件 IO 竞争，高并发压测时 8 个 Queue 比 16 个更稳定
参考：RocketMQ 官方文档、《RocketMQ 技术内幕》、Apache RocketMQ GitHub