消息队列 RocketMQ 实践：千里达票务系统订单链路异步解耦
最早千里达票务系统是同步调用：下单 → 扣库存 → 调支付 → 发短信 → 加会员积分。任何一个下游慢一点，整个下单接口就被拖垮，节假日一次短信网关抖动，整个景区都买不了票。接入阿里云消息队列 RocketMQ 后，主链路只做核心写库，其余异步化，接口 P99 直接降了一半。
一、为什么要 MQ
- 削峰：节假日抢票洪峰瞬间打过来，MQ 当缓冲；
- 解耦：短信、积分、发票、通知各自订阅，新增下游不动主链路；
- 可靠：支付回调落库后发消息，下游挂了不影响主订单；
- 最终一致：库存扣减与订单创建通过事务消息保证一致。
二、拓扑
下单服务 → RocketMQ(OrderTopic) → 库存服务/短信服务/积分服务/数据分析
支付服务 → RocketMQ(PayTopic) → 发票服务/短信服务/财务对账
三、关键实现
3.1 生产端（订单创建）
Message msg = new Message("OrderTopic", "TagNewOrder",
JSON.toJSONBytes(orderDTO));
SendResult result = producer.send(msg, (mq, q, arg) -> {
return mq.getQueueId() % q.getQueueNum();
}, orderDTO.getSceneId()); // 同景区订单路由到同队列，保证局部有序
3.2 消费端
consumer.subscribe("OrderTopic", "TagNewOrder", (msgs, ctx) -> {
for (MessageExt m : msgs) {
OrderDTO dto = JSON.parseObject(m.getBody(), OrderDTO.class);
smsService.sendOrderNotice(dto);
}
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});
3.3 关键策略
- 顺序消息：同景区同游客的订单按队列顺序消费；
- 事务消息：下单与扣库存跨库，用半消息保证最终一致；
- 死信队列：重试 16 次仍失败进死信，人工介入；
- 幂等：消费端按 order_no 去重，避免重复发短信。
四、踩坑复盘
- 消息积压：国庆当天短信网关慢，积压 20 万条。解决：临时扩容消费者 + 降级非核心通知；
- 重复消费：网络抖动导致重复投，给用户发了两条短信。解决：消费端 Redis 去重；
- 顺序与吞吐矛盾：强制全局有序后吞吐上不去。解决：按景区做分区有序，不追求全局；
- 死信堆积没人看：早期死信告警没配，一周后才发现某类订单短信一直失败。解决：死信队列接云监控告警。
五、效果与总结
接入 RocketMQ 后，下单接口 P99 从 800ms 降到 350ms，节假日短信网关抖动再也不会拖垮主交易。对千里达票务系统这种多下游、强波峰的业务，MQ 是"主链路稳得住"的关键中间件：先把异步和同步拆开，再谈高并发。
