RocketMQ 架构设计与面试要点

RocketMQ 是阿里巴巴开源的分布式消息中间件，具有高性能、高可靠、高实时等特点，尤其在处理金融级分布式事务方面表现卓越。

1. 技术架构

RocketMQ 包含四大核心角色：

NameServer: 注册中心。提供 Broker 管理和路由信息管理。各 Broker 会向所有 NameServer 注册信息，Producer/Consumer 定期拉取路由表。去中心化设计，节点间互不通信。
Broker: 存储核心。负责消息存储、查询和高可用。支持 Master/Slave 架构，Slave 提供读取服务。
Producer: 生产者。支持分布式集群部署，通过轮询或 Hash 方式发送消息。
Consumer: 消费者。支持 Push 和 Pull 模式，支持集群消费（负载均衡）和广播消费。

2. 消息模型

RocketMQ 采用 主题模型 (Pub/Sub) 实现：

Topic: 消息的逻辑归类。
Queue (MessageQueue): 提高并发能力的物理单位。一个 Topic 分布在多个 Broker 上，每个 Topic 包含多个 Queue。
Consumer Group: 消费者组。同一组内的消费者共同消费一个 Topic 的不同 Queue。一个 Queue 同时只能被一个消费者消费。

3. 存储机制 (核心要点)

RocketMQ 采用 混合型存储结构，所有队列共用一个日志数据文件：

CommitLog: 消息主体存储文件。顺序写入，单个文件默认 1G。利用 MappedByteBuffer (内存映射) 提高写入效率。
ConsumeQueue: 逻辑消费队列（索引）。保存消息在 CommitLog 中的物理偏移量、消息大小和 Tag 的 HashCode。
IndexFile: 提供基于 Key 或时间区间的消息查询。

刷盘与复制策略

刷盘: 同步刷盘（可靠性高） vs 异步刷盘（吞吐量大）。
复制: 同步双写（Master/Slave 均成功才返回） vs 异步复制。

4. 高级特性实现原理

4.1 顺序消息

普通顺序: 保证同一 Queue 内有序。发送时使用 Hash 取模 将同一业务 ID 的消息发往同一 Queue。
严格顺序: 即使故障也不乱序，代价是可用性降低。

4.2 重复消费 (幂等性)

MQ 保证消息至少送达一次，不保证不重复。必须在消费端实现幂等：

数据库唯一键约束。
Redis 状态位检查。

4.3 分布式事务 (Half Message)

发送 Half Message（对消费者不可见）。
执行本地事务。
根据本地事务结果发送 Commit/Rollback。
事务反查: 若第 3 步丢失，Broker 会主动询问 Producer 本地事务状态。

4.4 消息堆积

根源：生产过快或消费过慢。
解决：增加消费者实例 + 同步增加 Topic 队列数（因为 Queue 数限制了消费者并发度）。

5. 参考资料

[RocketMQ 技术内幕 - 丁威]
[十分钟入门 RocketMQ - 阿里中间件团队]
[RocketMQ 流程分析 - JavaGuide]
[分布式消息中心设计实践 - GitHub PR]