RabbitMQ 入门：订单创建后为什么要发消息？h1

我当时的疑问很直接h2

我最开始学消息队列时，总会想：

一个接口里直接把逻辑写完不就行了，为什么还要“发消息”？

后来在订单场景里，我慢慢理解了它的价值。

比如用户下单成功后，系统后面可能还要做很多事：

• 扣减库存
• 发送短信或站内通知
• 生成积分记录
• 通知物流或其他下游系统

如果这些操作都同步写在下单接口里，那接口会越来越重，失败点也越来越多。

所以 RabbitMQ 这种消息队列，本质上是在帮我们做一件事：

把主流程和后续流程拆开。

先说我现在的理解h2

RabbitMQ 最核心的价值，我目前理解成 3 点：

1. 异步处理：提升主流程响应速度
2. 应用解耦：让系统之间不要直接绑死
3. 削峰填谷：应对瞬时高并发

如果面试官问“订单创建后为什么要发消息”，我现在会先答：

• 下单成功是主流程
• 发券、发通知、积分变更是后续流程
• 后续流程可以异步化，降低接口耦合和响应时间

一个最容易理解的订单场景h2

假设有个创建订单接口：

@PostMapping("/order")
public Result<Long> createOrder(@RequestBody OrderDTO dto) {
    Long orderId = orderService.createOrder(dto);
    return Result.ok(orderId);
}

如果没有 MQ，createOrder() 里面可能会做很多额外操作：

public Long createOrder(OrderDTO dto) {
    // 1. 创建订单
    // 2. 扣库存
    // 3. 发短信
    // 4. 增加积分
    // 5. 记录消息通知
    return orderId;
}

这会带来几个问题：

• 接口耗时变长
• 任一环节失败都可能影响主流程
• 业务越来越复杂，方法越来越难维护

引入 RabbitMQ 后怎么变h2

引入 MQ 之后，可以把“主流程”和“后续通知类流程”拆开：

用户下单
-> 订单服务创建订单
-> 向 RabbitMQ 发送 order.created 消息
-> 库存服务 / 积分服务 / 通知服务 各自消费

这样主流程只需要保证：

• 订单创建成功
• 消息成功发出去

剩下的逻辑交给消费者异步处理。

RabbitMQ 的几个核心角色h2

学习阶段我一般只先记 4 个词：

1. Producer（生产者）h3

发消息的人。

比如订单服务下单成功后，把消息发到 RabbitMQ。

2. Consumer（消费者）h3

收消息并处理的人。

比如积分服务收到“订单已创建”消息后，给用户增加积分。

3. Queue（队列）h3

消息暂存的地方。

生产者把消息发进去，消费者从这里取。

4. Exchange（交换机）h3

消息的路由中转站。

它决定一条消息应该进哪个队列。

一个最小示例h2

生产者发送消息h3

@Resource
private RabbitTemplate rabbitTemplate;

public void sendOrderCreatedMessage(Long orderId) {
    rabbitTemplate.convertAndSend("order.direct", "order.created", orderId);
}

消费者接收消息h3

@Component
public class OrderCreatedConsumer {

    @RabbitListener(queues = "order.created.queue")
    public void handle(Long orderId) {
        System.out.println("收到订单消息：" + orderId);
        // 处理积分、通知等逻辑
    }
}

我当时就是先把“谁发、发到哪、谁消费”这三件事弄顺，后面的可靠性和重试再逐步补。

为什么 MQ 能提升响应速度h2

因为很多不影响“当前用户立刻拿到结果”的步骤，都可以异步做。

比如下单场景：

• 用户最关心的是“订单创建成功了没”
• 用户不一定非得等积分和短信都处理完

所以只要主流程成功，后面的事情放到消费者慢慢做，接口就会更轻。

为什么 MQ 能解耦h2

没有 MQ 的时候，订单服务可能直接调用：

• 积分服务
• 通知服务
• 库存服务

只要其中一个下游改接口、挂了、变慢了，订单服务就会受影响。

有了 MQ 后，订单服务只负责发消息，不关心是谁来消费、消费几个、消费逻辑怎么改。

这就是解耦。

为什么 MQ 能削峰h2

比如秒杀场景下，某一瞬间有很多请求过来。

如果都直接同步落到数据库或下游服务，系统容易被压垮。

而 MQ 可以先把消息存起来，消费者按自己的处理能力慢慢消费，相当于在系统中间加了一个“缓冲带”。

我踩过的几个坑h2

坑 1：觉得 MQ 是“高级技巧”，先不学h3

其实你不用一开始就学得特别深，先理解业务动机就行：为什么要异步、为什么要解耦。

坑 2：什么都异步化h3

不是所有流程都适合 MQ。

如果某个步骤是主流程成功的必要条件，那就不能随便异步。

比如“订单入库”本身就不能丢。

坑 3：以为发了消息就万事大吉h3

实际上还要考虑：

• 消息是否可靠送达
• 消费失败怎么办
• 会不会重复消费

这些是后续进阶再继续学的内容。

我现在给 MQ 下的定义h2

如果现在让我用一句话解释 MQ，我会说：

RabbitMQ 适合把不必同步完成、但又必须后续执行的逻辑拆出去做异步处理。

它不是为了“显得架构高级”，而是为了让主流程更稳、更快、更容易扩展。

我会拿这几条检查自己有没有真懂h2

• 能不能说清 Producer、Consumer、Queue、Exchange 的作用
• 能不能举出一个订单异步处理的真实场景
• 能不能解释为什么 MQ 可以提升接口响应速度
• 能不能区分哪些流程适合同步，哪些适合异步

面试里我会怎么讲h2

可以按这个结构讲：

• 问题：订单创建后还有库存、通知、积分等后续操作
• 痛点：全部同步处理会导致接口耗时长、耦合重、失败点多
• 方案：订单主流程成功后发送 RabbitMQ 消息，由不同消费者异步处理后续逻辑
• 收益：降低耦合、缩短响应时间、提升系统扩展性

最后说一句大白话h2

订单创建后发消息，不是“多此一举”，而是：

把必须立刻完成的主流程，和可以异步完成的后续流程拆开。