php - 用户提交订单，30分钟后没付款取消订单功能分析

我的思路有点不同，有类似Redis, 或者打个比方说Cookie吧（当然不能直接就用cookie）

//新创建订单后
$order_sn = '123456'; //订单号

//这个方法自己看着建立，实际项目中没有这个函数方法，这只是思路！
cookie()->push($order_sn, 1800);

//支付订单等操作时
//先检测cookie中是否还有这个订单号
if(!cookie()->has($order_sn)){
    die('该订单已过期！');
}

我刚好做过这样的功能，要看你取消订单后需不需要恢复库存了，不需要的话可以插入个结束时间来做标识，如果需要恢复库存的话可使用swoole里面的毫秒定时器swoole_timer_after来实现，如果使用的是laravel框架的话也可以使用延时队列来实现。

其实没必要做成定时器之类的，你可以在订单生成的时候同时插入数据库 一个结束时间

最近的项目也有类似的需求。我这边是被动更新 + crond 主动更新两种方式，因为是抢购，下单扣库存，5分钟不支付马上过期恢复库存。

当碰到支付完成到回跳时，订单刚好过期的时候，直接将订单设置为待退款状态，然后走另一个定时任务完成退款。

方案一 个人觉得是不可行的
因为没有办法控制客户端能在半个钟准时的发送一个请求来撤销你的订单。

个人建议使用方案二，定时任务脚步，一分钟执行一次
查询数据库 判断下单时间超过30分钟，取消订单。（如订单量大，不可用此方法）

另请注意，请判断好支付完成回调的验证，因为

用户下单后，20几分钟后再点击付款，再到支付页面停留，时间已经超过30分钟，然后支付成功回调时请注意判断验证回调的信息

另外希望有支付经验丰富的大哥指点指点。

想到了一个 为每个订单创建一次性定时任务 以创建时间为起点三十分钟后 检查一次 处理逻辑

写个定时任务脚步，一分钟执行一次，查库操作。
查询 未支付 并且 订单生产时间大于当前时间30分钟的
每次查询10条，去执行取消订单逻辑

虽然不是干客户端的，但是我感觉从客户端去计算时间未免有点不靠谱吧，在下单的时候服务器就应该有信息了，然后服务端去加定时就可以了.

普遍的做法是2，但是2比较尴尬crontab是分钟级别的。我觉得可以配合redis做一层下单时间校验。

未付款的订单都扔到临时表里，客户端去判断是否过期。

服务器做个定时任务，每天清除一次临时表的过期订单数据。没必要总是去清理。

1. 订单创建成功后放进redis 超时时间设置为30分钟

2. 做个crontab定时任务 检查订单是否超过30分钟

推荐第一种方法

我觉得性能最好的就是高票回答，也就是和php的session过期gc回收机制一样的原理。

如果理解不了那个方法，也可以试试看redis里面加过期时间的办法，这种方法有个缺陷就是如果某个redis节点当机，可能会导致那个节点下的用户订单丢失，这个时候就需要多机同步备份了。

守护进程处理

创建订单后，放个30分钟执行的任务到工作队列。

补充一：

工作队列具体流程：

1. 用户创建订单A

2. 生成30分钟后执行的任务，任务内容是：检查订单A是支付成功，如果没支付则标记为失效订单

3. 用户支付，如果订单已失效，说明已经过了30分钟，否则标记订单支付成功

Laravel自带的队列很方便：Queues

胡思乱想：

直接用Redis的过期功能把订单删了并不好，或者要预留多一点时间，不要准确30分钟过期。

考虑这种情况：

对接微信支付，用户在29分59秒支付成功，微信在支付成功时发送异步给服务器，1.1秒后到达服务器，而这个时候订单已经被删了。

在生成微信的订单时判定一次即可。

• 肯定不能依赖前端

• 2可以

客户端数据被篡改就能无限修改这个时间阈值了

查询的时候直接拿当前时间加上30分钟过滤，配合被动取消订单很完美的解决方案

不知道你的客户端是什么，但是方案1很依赖客户端，订单决策不应该由客户端发起

方案2的话就要考虑你的执行密度，要知道每时每刻都会有新订单发起的，每时每刻也会有订单过期。

用一些成熟的带TTL控制的方案吧，比如redis。

我之前的做法是在每次查询这个订单时候检查过期，被动过期。

比如，查询订单细节时，再去检查是否过期然后再处理。
当然，如果这条数据不被访问可能永远不会过期，直到有人访问它。

有点像薛定谔的猫，在你打开盒子（检查订单）之后，才知道它是否过期。所以叫被动过期