MQ 从 0 到 1（一）：为什么需要消息队列#

不用 MQ 的同步调用#

假设一个电商系统里，用户下单成功之后要做这些事：

1
1. 创建订单
2
2. 扣减库存
3
3. 生成支付单
4
4. 发短信通知
5
5. 发站内信
6
6. 增加用户积分
7
7. 推送数据到搜索系统
8
8. 记录运营分析数据

如果所有事情都写在一个接口里，大概会变成这样：

1
public void createOrder(CreateOrderCommand command) {
2
    Order order = orderService.create(command);
3
    stockService.deduct(order);
4
    paymentService.createPayment(order);
5
    smsService.sendOrderCreatedMessage(order);
6
    messageService.sendSiteMessage(order);
7
    pointService.addPoint(order);
8
    searchService.syncOrder(order);
9
    analysisService.record(order);
10
}

代码一眼能看懂，但问题也很明显。

问题一：接口响应慢#

用户真正关心的是：

我这个订单有没有创建成功？

但同步调用会让用户等所有步骤都完成。

假设每个步骤耗时如下：

总耗时可能接近 800ms。

如果短信服务偶尔慢一点，接口就会更慢。用户看到的就是一直转圈。

但短信、积分、搜索同步这些事情，并不一定要阻塞下单接口。

这时候就可以改成：

1
下单接口只做核心链路：
2
创建订单 -> 扣库存 -> 生成支付单
3

4
其他事情发消息：
5
发送 OrderCreatedEvent

消费者异步处理：

1
短信消费者：发送短信
2
积分消费者：增加积分
3
搜索消费者：同步搜索数据
4
分析消费者：记录运营数据

接口响应会变快，因为非核心动作被移到了异步链路。

问题二：系统耦合太重#

同步调用还有一个问题：订单服务知道得太多。

订单服务本来只应该关心订单，结果它还要知道：

• 短信服务怎么调用；
• 积分服务怎么调用；
• 搜索服务怎么调用；
• 运营分析服务怎么调用；
• 新增一个优惠券服务时，还要改订单服务。

这会让订单服务越来越胖。

用了 MQ 之后，订单服务只需要做一件事：

1
订单创建成功后，发布一条订单创建消息。

至于谁关心这条消息，由消费者自己订阅。

1
OrderCreatedEvent
2
    -> 短信服务消费
3
    -> 积分服务消费
4
    -> 搜索服务消费
5
    -> 分析服务消费
6
    -> 优惠券服务消费

订单服务不需要知道后面有多少消费者。

这就是解耦。

问题三：高峰流量打垮下游#

同步调用是“来一个请求，立刻处理一个请求”。

如果一场秒杀活动瞬间来了 10 万个请求，后端会直接把压力传给数据库和下游服务。

1
大量请求 -> 订单服务 -> 库存服务 -> 数据库

数据库顶不住时，系统就会雪崩。

MQ 可以作为缓冲层。

1
大量请求 -> 订单服务 -> MQ -> 消费者慢慢处理 -> 数据库

上游先把任务放进队列，下游按自己的处理能力慢慢消费。

这叫削峰填谷。

注意，MQ 不是让系统凭空变强，它只是把瞬时压力摊平。真正的处理能力还是取决于消费者数量、数据库能力、业务幂等和限流策略。

问题四：跨系统事务不好处理#

本地事务只能保证一个数据库里的操作一致。

比如下单时：

1
订单库：创建订单
2
库存库：扣库存
3
积分库：加积分
4
搜索系统：同步文档

这些操作不在一个数据库里，不能简单用一个 MySQL 事务包起来。

在真实项目里，更常见的做法是：

1
核心事务先成功。
2
然后发送业务事件。
3
消费者异步处理自己的数据。
4
如果失败，就重试或补偿。

这就是最终一致性的思路。

用户下单成功后，积分晚几秒到账，通常可以接受。

但订单创建成功、支付单没生成，这种核心链路就不能随便异步，要谨慎设计。

MQ 适合放什么#

适合放进 MQ 的事情，一般有几个特点：

• 不需要立即给用户返回结果；
• 失败后可以重试；
• 能接受短暂延迟；
• 可以设计幂等；
• 适合被多个系统订阅。

比如：

MQ 不是万能药，不是所有操作都应该丢到队列里。

MQ 的核心角色#

不管是 RabbitMQ、RocketMQ 还是 Kafka，最基本的角色都差不多。

1
生产者 Producer
2
    发送消息
3

4
消息中间件 Broker
5
    保存消息、路由消息、投递消息
6

7
消费者 Consumer
8
    接收消息并处理业务

用订单场景表示就是：

1
订单服务
2
  发送 OrderCreatedEvent
3
        |
4
        v
5
      MQ
6
        |
7
        +--> 短信消费者
8
        +--> 积分消费者
9
        +--> 搜索消费者
10
        +--> 分析消费者

生产者只负责把消息发出去。

消费者只负责处理自己关心的消息。

Broker 负责在中间保存和分发消息。

消息一般长什么样#

消息本质上就是一份数据。

比如订单创建消息：

1
{
2
  "eventId": "202607091200000001",
3
  "eventType": "ORDER_CREATED",
4
  "orderId": 10001,
5
  "userId": 90001,
6
  "occurredAt": "2026-07-09 12:00:00"
7
}

业务里不要只传一个字符串，也不要把整个大对象无脑塞进去。

建议消息里包含：

• 全局唯一的消息 ID；
• 事件类型；
• 业务主键，比如 orderId；
• 必要的业务字段；
• 事件发生时间；
• 版本号，方便后面兼容升级。

很多时候，消息里只放 orderId 就够了，消费者再根据 orderId 查询自己需要的数据。

MQ 会带来什么新问题#

MQ 解决了一些问题，也会引入新的复杂度。

最常见的是：

• 消息发送失败怎么办；
• 消息发出去了但数据库事务回滚怎么办；
• 消费者处理失败怎么办；
• 同一条消息被消费多次怎么办；
• 消息顺序是否需要保证；
• 消息堆积了怎么办；
• MQ 服务挂了怎么办；
• 消费太慢怎么扩容；
• 如何监控和告警。

所以 MQ 不是“加了就高级”，而是要配合可靠性、幂等、重试、死信队列、监控一起设计。

后面的文章会围绕这些问题展开。

MQ 和 @Async 的区别#

前面写过 @Async。

@Async 和 MQ 都能做异步，但定位不一样。

简单说：

1
本服务内部，轻量异步，可以先考虑 @Async。
2
跨服务、不能丢、要削峰，优先考虑 MQ。

小结#

这一篇先记住几个点：

• MQ 的核心思想是生产者发消息，消费者异步消费；
• MQ 常用来做异步、解耦、削峰和最终一致性；
• MQ 适合处理可延迟、可重试、可幂等的任务；
• MQ 会引入消息可靠性、重复消费、堆积、监控等新问题；
• 不要为了用 MQ 而用 MQ，要先判断业务是否真的需要。

下一篇开始进入 RabbitMQ，看它是怎么用交换机、队列和绑定关系完成消息路由的。

下一篇：MQ 从 0 到 1（二）：RabbitMQ 基础模型