RocketMQ总结详解：大厂面试必问的核心知识点

RocketMQ 面试核心知识点总结

RocketMQ 的核心不是背 API，而是理解它如何在高吞吐、高可靠、顺序性、事务一致性之间做取舍。下面按面试高频链路整理。

1. 架构与四大组件

NameServer：轻量路由中心，无状态、节点间不通信，Broker 定时上报路由，Producer/Consumer 从 NameServer 拉取 Topic 路由。

Broker：消息存储与转发，支持主从、同步/异步复制、DLedger 自动选主。

Producer：支持同步、异步、单向发送;同步发送最可靠，失败可重试。

Consumer：支持集群消费和广播消费;集群模式有重试，广播模式无重试。

面试金句：NameServer 是“通讯录”，Broker 是“仓库”，Producer 是“发货方”，Consumer 是“收货方”。

2. 存储模型：CommitLog + ConsumeQueue + IndexFile

CommitLog：所有 Topic 消息混写同一个物理文件，严格顺序追加，写性能极高。

ConsumeQueue：按 Topic + Queue 维护索引，每条 20 字节，存 CommitLog Offset、Size、Tag HashCode。

IndexFile：按 Key 或时间查询消息，用于消息轨迹和问题排查。

核心设计：写走 CommitLog 顺序写，读走 ConsumeQueue 索引定位，读写分离，Topic 数量不影响写入性能。

3. 高性能从哪来

顺序写磁盘：所有消息追加写入 CommitLog。

零拷贝：写入用 MMAP，读取用 sendfile，减少内核态拷贝。

PageCache：热数据尽量在内存中完成读写。

异步化：异步刷盘、异步构建 ConsumeQueue、异步主从复制。

4. 消息不丢失：生产、存储、消费三段保障

生产端：优先同步发送，失败重试;核心业务避免 OneWay。

存储端：同步刷盘保证落盘;同步复制或 DLedger 多数派落盘防止主节点宕机丢失。

消费端：消费成功才提交 Offset;失败返回 RECONSUME_LATER 触发重试。

最可靠组合是同步发送 + 同步刷盘 + 同步复制，但吞吐会明显下降，需要按业务等级取舍。

5. 消息重复与幂等

RocketMQ 只保证至少一次投递，不保证恰好一次。

重复来源：

生产者未收到 ACK 重发

消费成功但 Offset 未提交

消费者重平衡后消息重新分配

幂等方案：

业务唯一键去重

去重表或 Redis SETNX

状态机校验，如订单已支付则忽略重复消息

6. 事务消息

流程：

Producer 发送 Half 消息，对消费者不可见。

执行本地事务。

返回 Commit 或 Rollback。

若未返回，Broker 定时回查本地事务状态。

适用场景：订单创建后通知下游、支付成功后开通权益、跨服务最终一致性。

注意：事务消息解决的是“本地事务与消息发送”的一致性，消费端仍需做幂等。

7. 顺序消息

发送端：同一 ShardingKey 的消息路由到同一个 MessageQueue。

消费端：使用顺序消费监听器，单线程消费同一队列。

实际多是分区顺序，不是全局顺序;全局顺序会严重牺牲吞吐。

风险：顺序消息消费失败会阻塞队列，后续同队列消息都会被卡住。

8. 消费重试与死信队列

集群消费失败或超时会触发重试。

无序消息默认最多重试 16 次，重试间隔阶梯递增。

超过最大重试次数后进入死信 Topic，可用于人工补偿或回溯。

广播消费不提供失败重试。

9. 消息积压怎么处理

先扩容 Consumer，但 Consumer 数不能超过 Queue 数，否则多余实例空闲。

临时增加 Queue 数量，配合新消费组分流。

消费逻辑降级，先落库或写入新 Topic，后续异步处理。

排查根因：慢 SQL、外部接口超时、异常吞掉、线程阻塞。

建立消费延迟监控，不要等积压到百万级才发现。

10. 面试最容易追问的点

NameServer 为什么不用 ZooKeeper?AP 优先，路由最终一致即可，避免选举阻塞。

异步刷盘会不会丢消息?单机宕机可能丢 PageCache 数据，核心链路建议同步刷盘或 DLedger 多数派。

为什么所有 Topic 混写 CommitLog?保证顺序写，避免多文件随机写。

顺序消息和普通消息怎么选?99% 场景用分区顺序，全局顺序代价太高。

事务消息和本地消息表区别?事务消息由 Broker 承担半消息和回查，本地消息表需要业务自己维护补偿任务。