背景

订单超时未支付是电商中的一个核心场景，当用户创建订单后，超过一定时间没有支付，平台需要及时将该订单关闭。需要关闭的主要原因有以下几个：

1. 提高交易效率：自动取消未支付的订单可以迅速释放被锁定的商品库存，商品能重新上架销售，提高商品周转率和销售效率。
2. 优化用户体验：对于消费者而言，自动退款减少了手动取消的操作步骤，提升了购物体验。
3. 管理库存准确性：避免因长时间占用库存而导致的真实库存与系统显示不符，减少因库存问题引发的订单履行错误。
4. 防止恶意下单：防范恶意用户通过大量下单但不支付来占用商品库存，干扰正常销售。
5. 资金流动与会计清晰：自动退款有助于电商平台和卖家及时处理财务事务，明确账目，避免长期挂账带来的财务管理复杂性。

时序图

增加时序图的原因是为了更好的理解后续各个方案的优缺点，另外是可以看的更清晰，便于理解。我们的场景是用户没有做完成支付这个步骤，也就是下图右侧的流程。

方案对比

方案一 被动关闭

主要看红框中的内容，与上方时序图的区别

被动关闭简单说就是依赖用户。这个方案在用户每次访问订单详情时，在订单详情接口中进行逻辑判断，支付是否超时，超时则关闭订单。时序图如下：

这个方案的优点只有一个，那就是不用开发自动关单的功能，只要查询订单详情接口加一些逻辑即可。缺点确实有很多：

1. 用户永远不过来点详情：这种情况订单就会一直处于待支付的状态，相当恐怖兄弟，相当于有一个库存一直被锁着。
2. 查询接口变得不单一：查询订单详情是一个查询接口，如果处理超时未支付时，就会引入写操作，个人认为是不太合适的

方案二 定时关闭

主要看红框中的内容，与上方时序图的区别

定时关闭一般都是通过xxl-job（分布式调度平台）来实现的。处理的逻辑是：

1. 定时任务查询超时未关闭的订单（注意这里扫出来的订单全部都需要关闭，后续与MQ关单方案对比）
2. 订单服务只返回订单号列表（只返回订单号，不用回表）
3. 遍历订单号列表，发送关单MQ消息

定时任务关闭个人非常推荐，非大厂的情况下，这个方案感觉是最优方案。原因是：

1. 大部分公司的订单里其实并不大
2. 超时不支付的订单非常少，大家想想自己买了不想要的东西是不是会立即点取消支付
3. 查询的时候有索引，不回表
4. 订单量中等的情况，可以读写分离，扫从库不会对业务造成影响

但是定时任务扫表的缺点也是有的：

1. 性能瓶颈与资源消耗：这种场景在扫主库的前提下是有影响的，集中式的查询一堆数据，会占用数据大量的IO资源，由于读写共享的是一个主库，集中式的读会让数据库的响应变慢，肯定对业务是有影响的
2. 实时性问题：简单说就是没办法保证及时的退款。假设超时未支付的时间是30分钟，但是定时任务5分钟跑一次，也就是说这个单子可能在下单30～35分钟后执行退款，与我们期望的下单后30分钟退款不一致

个人非常推荐使用该实现方案，原因很简单实时性的问题我们可以改成1分钟，缩短定时任务的频率；资源消耗的问题在超时单量不是特别多的情况下，其实产生的影响不大，这个场景扫的不是全表。

方案三 Rocket MQ延迟消息

主要看红框中的内容，与上方时序图的区别

目前MQ最常见时RocketMQ，所以消息队列以RocketMQ为例，像RabbitMQ也有类似的功能死信队列这里不展开讨论。处理的逻辑是：

1. 下单后异步发送延迟消息
2. 延迟消息到延迟时间，消息投递到队列，消费者此时可以拉到该消息
3. 判断订单是否完成支付，完成这不需要任何处理

Rocket MQ的好处是可用性非常高，RocketMQ本身有重试机制，能保证消息失败后的重试。从实际情况看，不是高峰的情况下，基本不会出现消息消费失败的情况。但是这个方案有个明显的缺点是有大量无效的调度，可以看到这个方案所有的订单都会去发送一个延迟消息，但是实际场景100个订单都不一定有一个超时未支付的订单。

总结

以上方案算是比较常见的方案，还有其他方案比如JDK自带的内存队列，Redis过期监听等大家可以去看看。以上方案个人推荐方案二定时任务，具体采用那种方案还是要根据业务情况来，毕竟技术是为了赋能业务，能解决问题就行，做完比完美更重要。