各位技术大佬们，大家好！今天咱们聊一个电商平台绕不开的话题：订单未支付过期自动关单。

想象一下：双11大促期间，用户疯狂下单，但总有一些人下完单就忘了支付，或者犹豫了。这些「僵尸订单」占着库存不让，真正想购买的用户却买不到，商家急得直跳脚。这时候，自动关单功能就成了救命稻草。

那如何实现这个功能呢？今天老司机就给你扒一扒电商平台常用的3种自动关单方案，从原理到代码，一次性讲清楚！

方案一：定时任务 - 简单粗暴但有效

第一种方案是定时任务，这也是最容易想到的方案。简单来说，就是每隔一段时间（比如1分钟），扫描一遍数据库中所有未支付的订单，如果发现订单创建时间超过了支付超时时间（比如30分钟），就执行关单操作。

实现思路

1. 使用Spring的@Scheduled注解或者Quartz框架创建定时任务
2. 定时任务每隔一段时间执行一次，查询未支付且已过期的订单
3. 对符合条件的订单执行关单逻辑（更新订单状态、释放库存等）

代码示例

// 使用Spring的@Scheduled注解实现定时任务
@Component
public class OrderCloseTask {@Autowiredprivate OrderService orderService;// 每隔1分钟执行一次@Scheduled(cron = "0 */1 * * * ?")public void closeExpiredOrders() {// 查询30分钟前创建且未支付的订单List<Order> expiredOrders = orderService.findExpiredUnpaidOrders(30);for (Order order : expiredOrders) {// 执行关单逻辑orderService.closeOrder(order.getId());}}
}

优点

• 实现简单，容易理解
• 开发成本低

缺点

• 实时性差：订单可能会在超时后1分钟内才被关闭
• 数据库压力大：如果订单量很大，每次扫描都会给数据库带来较大压力
• 资源浪费：即使没有过期订单，定时任务也会按时执行

方案二：延迟队列 - 精准控制时间

第二种方案是延迟队列，这是一种更高级的实现方式。延迟队列可以让消息在指定的延迟时间后才被消费，非常适合处理订单过期这种场景。

实现思路

1. 当用户创建订单时，将订单信息放入延迟队列，设置延迟时间为支付超时时间（比如30分钟）
2. 30分钟后，消息被消费者取出
3. 消费者检查订单状态，如果仍然未支付，则执行关单操作

代码示例（使用RabbitMQ的延迟队列）

// 发送延迟消息
@Service
public class OrderService {@Autowiredprivate RabbitTemplate rabbitTemplate;public void createOrder(Order order) {// 保存订单orderRepository.save(order);// 发送延迟消息，30分钟后执行关单rabbitTemplate.convertAndSend("order.delay.exchange","order.delay.routingKey",order.getId(),message -> {message.getMessageProperties().setDelay(30 * 60 * 1000); // 30分钟return message;});}
}// 消费延迟消息
@Component
public class OrderCloseConsumer {@Autowiredprivate OrderService orderService;@RabbitListener(queues = "order.close.queue")public void handleOrderClose(Long orderId) {// 检查订单状态Order order = orderService.getById(orderId);if (order != null && order.getStatus() == OrderStatus.UNPAID) {// 执行关单逻辑orderService.closeOrder(orderId);}}
}

优点

• 实时性好：订单超时后立即被处理
• 数据库压力小：不需要定时扫描全表
• 资源利用率高：只有真正需要处理的订单才会被消费

缺点

• 实现复杂度较高，需要引入消息中间件
• 消息中间件可能成为单点故障
• 如果消息中间件宕机，可能导致关单失败

方案三：TTL + 死信队列 - 更可靠的延迟处理

第三种方案是TTL（Time To Live）+ 死信队列，这是对延迟队列的一种改进，更加可靠。

实现思路

1. 创建一个具有TTL的队列，当消息在队列中存活时间超过TTL后，会被自动转发到死信队列
2. 当用户创建订单时，将订单信息发送到TTL队列，设置TTL为支付超时时间
3. 消息过期后，被转发到死信队列
4. 消费者从死信队列中取出消息，执行关单操作

代码示例（使用RabbitMQ的TTL和死信队列）

// 配置RabbitMQ
@Configuration
public class RabbitMQConfig {// 创建TTL队列@Beanpublic Queue ttlQueue() {Map<String, Object> args = new HashMap<>();args.put("x-message-ttl", 30 * 60 * 1000); // 30分钟args.put("x-dead-letter-exchange", "dead.letter.exchange");args.put("x-dead-letter-routing-key", "dead.letter.routingKey");return new Queue("order.ttl.queue", true, false, false, args);}// 创建死信队列@Beanpublic Queue deadLetterQueue() {return new Queue("order.dead.letter.queue", true);}// 其他交换器和绑定配置...
}// 发送消息到TTL队列
@Service
public class OrderService {@Autowiredprivate RabbitTemplate rabbitTemplate;public void createOrder(Order order) {// 保存订单orderRepository.save(order);// 发送消息到TTL队列rabbitTemplate.convertAndSend("order.ttl.exchange", "order.ttl.routingKey", order.getId());}
}// 消费死信队列中的消息
@Component
public class DeadLetterConsumer {@Autowiredprivate OrderService orderService;@RabbitListener(queues = "order.dead.letter.queue")public void handleDeadLetter(Long orderId) {// 检查订单状态并执行关单逻辑Order order = orderService.getById(orderId);if (order != null && order.getStatus() == OrderStatus.UNPAID) {orderService.closeOrder(orderId);}}
}

优点

• 可靠性高：即使消息中间件重启，消息也不会丢失
• 实时性好：订单超时后立即被处理
• 解耦性强：关单逻辑与订单创建逻辑完全分离

缺点

• 实现复杂度最高
• 需要额外配置TTL队列和死信队列
• 调试和监控相对困难

三种方案对比：该怎么选？

• 小公司、小项目：建议使用定时任务，简单粗暴见效快
• 中等规模电商：建议使用延迟队列，平衡了实时性和复杂度
• 大型电商、高并发场景：建议使用TTL + 死信队列，可靠性最高

实战经验分享：避免踩坑

1. 幂等性处理：关单操作一定要做幂等性处理，避免重复关单。可以在关单前检查订单状态，或者使用分布式锁
2. 异常处理：关单过程中可能会出现各种异常（如数据库连接失败、库存服务不可用等），一定要做好异常处理和重试机制
3. 监控告警：对关单操作进行监控，如果出现大量关单失败或者关单延迟，要及时告警
4. 参数可配置：支付超时时间不要写死在代码里，要做成可配置的，方便根据业务需求调整
5. 灰度发布：新的关单方案上线前，先进行灰度发布，观察一段时间确认没问题后再全量上线

总结

订单未支付过期自动关单是电商平台的核心功能之一，实现方案有很多种，没有最好的，只有最适合自己业务的。

小项目可以用定时任务，简单又高效；中等规模项目可以用延迟队列，平衡实时性和复杂度；大型高并发项目建议用TTL + 死信队列，可靠性最高。

最后，老司机再提醒一句：无论选择哪种方案，一定要做好幂等性处理、异常处理和监控告警，这样才能保证系统稳定运行。

如果觉得这篇文章有用，欢迎分享给身边的小伙伴，也欢迎在评论区留言讨论你遇到过的关单问题～

咱们下期再见！