RocketMQ 架构与核心概念¶
30 秒版（开场）¶
RocketMQ 是 NameServer（路由）+ Broker（存储）+ Producer/Consumer 的分布式消息中间件。消息按 Topic 分类，Queue 是并行与顺序域。事务、延迟和 FIFO 是其重要能力，但具体 API 与限制要区分 4.x/5.x；Go 客户端也要核对与目标 broker 的兼容矩阵。
3 分钟版（精讲深度）¶
- 是什么：阿里开源 MQ，支持普通/FIFO/事务/延迟消息；NameServer 提供路由发现，Broker 可采用主从、Controller/DLedger 等不同高可用部署，版本与模式要说清。
- 为什么：国内业务、电商、支付场景常见；选用时需讲清 与 Kafka 的语义与运维差异。
- 怎么做：Producer 发
Topic:Tag；Broker 写 CommitLog + ConsumeQueue 索引；Push/Pull 消费；Consumer Group 内 集群消费（一条消息只被一个实例消费）或 广播消费。
10 分钟版（原理 + 图示）¶
flowchart LR
P[Producer] --> NS[NameServer]
P --> B1[Broker Master]
B1 --> B2[Broker Slave]
C[Consumer Group] --> NS
C --> B1| 概念 | 说明 |
|---|---|
| Topic | 逻辑分类，如 ORDER_TOPIC |
| Tag | 子过滤，如 create / pay |
| Queue | Topic 下分片，顺序消息绑定单 Queue |
| Consumer Group | 同组 集群消费（一条消息只被一个实例消费）；不同 Group 各自独立消费全量（类似 Kafka 多订阅） |
| MessageModel | CLUSTERING（默认，负载均衡）vs BROADCASTING（同组每实例全量） |
| Offset | 消费进度，Broker 或本地管理 |
存储：CommitLog 顺序写 + ConsumeQueue 定长索引（类似 Kafka 分区日志思想，实现不同）。
生产场景¶
- 订单创建 → 下游库存、积分、通知
- 需要 延迟关单、事务消息（半消息）的支付链路
- 运维：Broker 磁盘、CommitLog 清理、消费堆积告警
排查与工具¶
- RocketMQ Console：Topic 堆积、消费 TPS、DLQ
mqadmin：集群状态、消费进度 reset（慎用）- 日志：broker.log、慢消费、send timeout
架构取舍¶
| 选型 | 适用 |
|---|---|
| RocketMQ | 国内云、事务/延迟/顺序、电商 |
| Kafka | 超高吞吐日志流、大数据管道 |
| Redis Stream | 轻量、小规模 |
深挖问答¶
- NameServer 挂了？ → 短时用本地缓存路由；新 Broker 无法注册；已有连接可继续一段时间。
- Tag 和 Key 区别？ → Tag 订阅过滤；Key 业务索引、消息查询。
- Push 和 Pull？ → Push 实为 Broker 长轮询推；Pull 自主拉，灵活但复杂。
- Go 客户端注意？ → 消费幂等、Rebalance 时重复消费、优雅 Shutdown。
反模式与事故¶
- Topic 过少、单 Queue 热点 → 并行度不足
- 消费慢不扩容 Consumer → 堆积拖垮 Broker
- 广播消费误用于需分摊流量的场景 → 每台都处理全量
代码示例¶
// 概念：Producer 发送（apache/rocketmq-client-go v2 风格示意）
msg := primitive.NewMessage("OrderTopic", body)
msg.WithTag("created")
msg.WithKeys([]string{orderID})
_, err := producer.SendSync(ctx, msg)