说说扣款后订单超时的订单超时和支付超时问题

分布式架构被越来越多的人接受和使用！除了分布式架构，跨系统，跨区域的外部接口调用也越来越多，比如，我们要发短信，调用第三方短信接口，支付调用支付宝，微信，银联等接口，物流查询调用顺丰等第三方物流公司接口。对于这些 Web 接口调用，都有可能发生超时问题。常见的有订单超时和支付超时，这类问题我们一般是怎么解决的呢？今天我们一起来分析分析！

一般的，一个订单可能包含下面几个过程。

其中，创建订单的时候，我们一般都会限制其在规定时间内完成。如果超过固定的时间，订单就会被取消。因为你这个订单占用的库存不可能一直让你占着。假设一个商品有 1000 个库存，你买了 1000 个，但你不支付，一直占着，其他人就买不了。所以，我们必须限制你在规定的时间内完成订单的支付，如果在规定的时间内没完成，则会被系统取消。释放库存，留给其他用户进行购买！

支付也是同样的道理，如果你的支付不设置超时限制，那么由于网络原因等因素，导致没有收到响应，系统就会一直处于阻塞状态，占用大量的资源。而且体验也不好，用户也不知到底发生了什么？所以支付也有超时限制。

超时问题，我们可以很好的理解。但是如果我的订单超时时间是 30 分钟，支付超时是 2 分钟，那么我在订单快超时的最后 30s 进行支付，而支付正在进行，30s 后，支付还未返回响应，也未超时，这时你的订单超时，订单就会被取消。而后，你的支付结果返回了，显示你支付成功了。但是这时订单已经被取消了，这怎么办呢？有什么好的办法吗？

这个问题在电商中非常的常见。比如，曾经著名的美团支付成功订单被超时取消时间。各大消费者都在投诉，扣款成功后订单超时，我们等着吃饭呢？美团把我们都给放一边了。

这个问题其实不是光美团有，其他电商公司也有。当然我们公司也不例外。所以，我就想了一个办法，解决这类问题。新增了一个支付中的状态，然后整个订单的生命周期状态变化，可以简化为下面的步骤。

待支付（订单写入数据库） ——> 处理中（支付层订单进入处理中状态） ——> 支付成功（收到支付层的支付成功通知） ——> 支付失败（收到支付层的支付失败通知） ——> 关单（订单有效期已过且未支付）。

如果订单未超时，发起支付，在支付过程中超时，这时发现订单正在进行支付，那么我们就先不进行超时处理，两分钟后，有了支付结果，我们在判断是否需要关单。

新增了这一个状态后，从此在也没有因为订单超时而扣款支付成功的问题订单。

最后说一下，关于定时关单的处理。不建议大家用定时任务去轮训处理，因为订单量太大，查询太费时间，而且影响其他功能的正常。被动取消的方法也不可取，因为库存问题你还没解决。业界推荐的方法就是延时消息处理，目前我们采用的就是这种方法。

： » 说说扣款后订单超时的订单超时和支付超时问题