架构与存储模型
核心组件
| 组件 | 作用 |
|---|---|
| NameServer | 提供轻量路由注册与发现，各节点相互独立 |
| Broker | 接收、存储和投递消息，维护消费进度等数据 |
| Producer | 从 NameServer 获取路由并向 Broker 发送消息 |
| Consumer | 按 Consumer Group 订阅并消费消息 |
| Proxy | 5.x 客户端接入层，提供 gRPC 等协议入口 |
| Controller | 在支持的高可用模式下管理 Broker 副本选主 |
NameServer 不是 ZooKeeper 式强一致协调服务。它保存路由视图，客户端会缓存并定期刷新；路由传播存在短暂延迟。
Topic 与 MessageQueue
Topic 是消息逻辑分类，MessageQueue 是 Topic 的并行存储和消费单元。顺序、负载均衡和消费并发都以 MessageQueue 为重要边界。
同一 Consumer Group 内，一条 MessageQueue 通常分配给一个 Consumer 实例；实例数超过可分配队列数时会有实例空闲。
存储结构
RocketMQ 的消息主体顺序写入 CommitLog，再通过异步构建的 ConsumeQueue 提供按 Topic/MessageQueue 消费的逻辑索引，IndexFile 支持按 Key 等条件查询。
- CommitLog 是统一物理日志；
- ConsumeQueue 保存逻辑位置、大小和 Tag Hash 等信息，不保存完整消息体；
- Index 查询用于运维和有限检索，不应当作通用数据库索引。
发送方式
| 方式 | 语义 |
|---|---|
| 同步发送 | 等待 Broker 返回发送结果，适合关注结果的业务消息 |
| 异步发送 | 通过 Callback 获取结果，提高并发吞吐 |
| One-Way | 不等待 Broker 结果，可靠性最低 |
发送成功表示 Broker 接管到相应持久化边界，不表示 Consumer 已经完成业务处理。
消费模式
- Clustering：同组 Consumer 分担消息，每条消息由组内一个实例处理；
- Broadcasting：每个 Consumer 实例都处理消息，但消费进度和故障恢复语义与集群模式不同。
业务广播通常还要考虑实例扩缩容后是否需要补历史，不能只看“每个实例收到一份”。
Tag 与属性过滤
Tag 是轻量分类，SQL 属性过滤可按消息属性表达更复杂条件。过滤条件应与 Topic 边界合理配合，避免把完全不同的业务生命周期塞入一个 Topic。