• 校验用户名等信息，如果没问题会在数据库中添加一个用户记录
  • 如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
  • 分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
  • 发送给用户一个包含操作指南的系统通知

注册流程这个例子（写库同步做、发邮件/短信/分析/通知异步化）是 MQ 最经典的教学案例，但它只展示了 MQ 三大价值中的”异步”。本文以该例为起点，补全异步、解耦、削峰三大价值的工程形态，以及”不该用 MQ”的反面清单与引入 MQ 必须配套的三件事。

从注册例子看异步化收益

同步链路：注册 = 写库(20ms) + 发邮件(300ms) + 短信(500ms) + 分析(200ms) + 通知(100ms) ≈ 1.1s 响应。异步化后：注册 = 写库 + 发消息(5ms) ≈ 25ms 响应，其余四件事由消费者各自完成。用户体验从 1.1s 到 25ms，就是 MQ 的第一价值：把”用户不必等的事”移出请求路径。

三大价值的工程形态

1. 异步（提速）：主链路只保留强一致部分，弱一致环节发消息异步做。判断标准：该环节失败是否允许”稍后补偿”？允许则异步化（邮件可重发），不允许则留同步（扣款）。

2. 解耦（演进）：下单系统不需要知道”积分系统、风控系统、WMS 的存在”——新增下游=新增消费者，不改上游代码。广播式演进：topic 是契约，消费者自由订阅。代价是隐式依赖：下游消费失败无人知晓，需监控兜底（见配套三件事）。

3. 削峰（保命）：秒杀 10 万 QPS 涌入，下游 DB 只能扛 5000——MQ 把请求暂存为积压，消费者按自身容量匀速消费（**把”瞬时冲击”变成”平稳流水”**）。配合上游限流（超额直接拒绝），系统从”被打死”变为”排队处理”。

延伸场景族

  • 最终一致分布式事务：事务消息/本地消息表（见重发补偿篇）
  • 延迟任务：延迟消息（订单超时取消）替代轮询扫表
  • 日志/事件采集：行为事件流式入仓（Kafka 生态）
  • 广播通知：配置变更、缓存失效广播（所有实例订阅）
  • 任务分发：计算任务队列（消费者水平扩展吞吐）

不该用 MQ 的反面清单

  • 需要即时响应结果：用户等”支付结果”不能异步——MQ 是 fire-and-forget，要结果需额外查询/回调链路
  • 强一致要求：扣款与记账必须同时成功 → 本地事务/分布式事务，MQ 只给最终一致
  • 下游只有一个且调用简单：直接 RPC 更简单；MQ 引入的运维成本（集群、监控、积压处理）不划算
  • 消息量极小的内部通知：事件总线/直接调用足够，别为三个消息养一个 Kafka 集群

引入 MQ 必须配套的三件事（否则异步变事故）

  1. 幂等消费：重投不可避免（at-least-once），消费端去重表/唯一键/状态机（见幂等篇）
  2. 积压监控与预案：lag 告警 + 扩容消费者/临时转发队列的预案（见堆积篇）
  3. 失败处理链路：重试队列（退避）+ 死信队列（人工/补偿）+ 消费失败告警——没有死信处理的 MQ 系统等于把失败藏进黑洞

选型速览

  • RocketMQ：事务消息/延迟消息/顺序消息齐全，业务消息首选（国内生态）
  • Kafka：高吞吐日志/事件流，分区序+批量压缩，分析生态强
  • RabbitMQ：路由灵活（交换机模型）、协议标准（AMQP），中小规模业务消息
  • 云 MNS/SQS：免运维轻量场景

注册例子只是入口：MQ 的三大价值（异步/解耦/削峰）对应三种架构决策（移出请求路径/订阅式演进/缓冲保命），而每种决策都带着配套义务（幂等/监控/死信）。把价值与义务配对理解，MQ 才是架构资产而非故障源头。