电商下单链路中的消息队列设计

电商下单不是一个接口写一张订单表那么简单。订单创建后，还会影响库存、优惠券、支付、通知、履约、推荐、报表等多个系统。

如果全部同步调用，下单接口会慢，也会因为下游服务故障拖垮核心链路。

Rendering diagram...

下单事件设计

订单创建成功后可以发布 OrderCreated。

{
  "event_id": "evt_order_10001_created",
  "event_type": "OrderCreated",
  "order_id": "10001",
  "user_id": "90001",
  "amount": 199.00,
  "created_at": "2026-05-17T21:30:00+08:00"
}

消费者各自订阅这个事件，完成自己的工作。

支付事件

支付成功后发布 OrderPaid。库存、履约、积分、报表都可以基于支付成功事件继续推进。

支付事件必须幂等。支付回调可能重复，MQ 消费也可能重复。

UPDATE orders
SET status = 'PAID'
WHERE id = 10001
  AND status = 'CREATED';

条件更新能防止重复支付事件造成状态回退或重复处理。

超时取消

下单后发送一条延迟消息，30 分钟后检查订单是否仍未支付。

如果仍未支付，就取消订单并释放库存。如果已经支付，就忽略消息。

消费者拆分

一个 Topic 不一定只有一个消费者。不同业务可以使用不同 Consumer Group。

order-events
  ├── inventory-service
  ├── report-service
  ├── notification-service
  └── recommendation-service

这样一个事件可以同时驱动多个系统，而且它们互不影响。

常见坑

第一个坑是同步链路过长。下单接口里同步调用太多系统，稳定性会很差。

第二个坑是消息没有唯一 ID。没有事件 ID，就很难做去重。

第三个坑是没有状态机。订单状态随便改，重复消息和乱序消息会让数据错乱。

第四个坑是没有补偿。消息队列不是百分百魔法，关键链路仍然需要对账和补偿任务。

小结

电商下单链路用 MQ 的核心，是把订单状态变化转成事件流。核心交易由订单服务保证，非核心动作通过消息异步扩展。

参考链接

• RocketMQ Transaction Message
• Kafka Documentation