用途：理解消息如何被存储与投递、部署该注意什么
| 角色 |
职责 |
关键点 |
| NameServer |
路由注册与发现（无状态） |
节点间不通信，Broker 向所有节点注册；可多实例 |
| Broker |
存储与投递消息 |
主从（Master/Slave 或 Dledger 多副本）；处理拉取与位点 |
| Producer |
发送 |
同步/异步/单向；从 NameServer 取路由后直连 Broker |
| Consumer |
消费 |
消费者组（Group）内实例分摊队列；位点由 Broker 管理 |
- Topic → MessageQueue（队列/分片）：并行度单位，队列数决定消费并发上限。
- CommitLog：所有消息混合顺序写一个文件（顺序 IO，写吞吐高），达到大小滚动。
- ConsumeQueue：逻辑队列索引，存 commitlog 偏移、大小、tag hash，供消费快速定位。
- IndexFile：按 key/时间建哈希索引，支持消息查询（运维排障常用）。
- 刷盘：同步刷盘（可靠性高、吞吐低）/ 异步刷盘（默认，宕机可能丢少量消息）。
- 读写分离：ConsumeQueue 与 CommitLog 读依赖页缓存，写走顺序追加，因此重启后页缓存冷启动会影响读性能。
| 形态 |
说明 |
取舍 |
| 多 Master 无 Slave |
部署简单，吞吐高 |
单机维护/宕机期间消息不可消费（延迟恢复） |
| 多 Master 多 Slave（异步复制） |
默认常用 |
极端情况可能丢少量消息 |
| 同步双写 Slave |
主备都落盘才返回 |
吞吐下降，可靠性高 |
| Dledger（Raft） |
自动选主、多副本一致 |
运维与资源成本更高 |
- 队列数按消费者实例数的整数倍设置，避免负载倾斜。
- Broker 磁盘 IO 是瓶颈：独立盘、关闭 atime、监控刷盘耗时与页缓存命中率。
- NameServer 轻量但必须多实例；客户端会缓存路由，NameServer 短暂不可用不影响已建立的路由。
- 消息保留时间（默认 3 小时以上/常见 48-72 小时）决定“回溯消费”能力，需与磁盘容量权衡。
- 客户端与 Broker 版本兼容性、事务/延迟消息特性支持范围需确认（不同发行版有差异）。
RocketMQ 的特点：队列模型 + 强大的消息位点管理、事务消息、延迟/定时消息、消息轨迹与查询、Tag 过滤、顺序消息（队列内有序）。适合业务消息（订单、事务通知、领域事件），与 Kafka 的差异见“与 Kafka 的选型对比”。
| 误区 |
修正 |
| 把 Topic 当队列用（一个业务一个 Topic 一个队列） |
队列数决定并发，需按消费能力规划 |
| 认为同步刷盘 = 不丢消息 |
还需同步复制 + 生产者重试 + 消费幂等 |
| 忽视消息保留期 |
积压或回溯需求超过保留期即丢 |
| NameServer 与 Broker 混部小规格 |
压测下路由与存储互相干扰 |
| 用消息查询当常态手段 |
它是运维能力，业务不应依赖 |
- Apache RocketMQ 官方文档：Architecture、Feature、Deployment
- 《RocketMQ 技术内幕》（存储与实现原理）