商城订单超过 30 分钟未支付自动取消订单，最佳解决方案是怎样？

[herozw]

如果用定时任务设置一个每秒执行的脚本，那样可能影响服务器性能。

[upupxjg]

记录创建时间，再次操作的时候检查超时，超时了有后续处理的话（比较麻烦的情况）设置状态+进队列，怕太多再搞个定期 dump 归档之类的

[upupxjg]

“最优解”要看你超时了有什么业务什么处理

[honeycomb]

guava 里有一个 cache，可以参考它的原理。

[ipconfiger]

首先你的订单在失效的时候需要有两个状态 一个是 失效 另外一个是完成失效, 失效可以用失效时间在记录中提现, 小于当前时间的都是属于失效, 然后在后台任务中慢慢处理失效的订单的其他回退的操作, 比如退款, 库存之类的, 都处理完后再设置状态为完成失效.

[frazy]

延迟 （ dead ）队列 + Job 补充 解决问题

[zjqzxc]

前后台分别进行
前台 js 负责倒计时，倒计时结束后向后台发送一个倒计时结束的请求，此时后台检查是否确实已经超时了
后台把这个计时加入延迟队列，采用 redis 的话就把检查实际间隔设置断些，几秒几十秒；磁盘数据库的话就 1~2 分钟甚至 3~5 分钟都可以。

[twogoods]

https://mp.weixin.qq.com/s/eDMV25YqCPYjxQG-dvqSqQ

[movistar]

有的解决方案能解决问题,有的就是小玩具
这种东西肯定得依赖中间件的,不管是分布式存储,分布式消息队列还是分布式锁
难道一个商城只有一台服务器一个服务么......
就算最简单的每秒扫一次库更新状态,N 台服务器之间怎么分配任务...
这些都是线上产品需要解决的问题
玩具无视,单机就太简单了......

[orderc]

可以参考我的实现 https://github.com/ouqiang/delay-queue

[orvice]

不知道大家有没有注意到
cloudxns 每次登陆，有时候能收到一些域名取消托管的邮件。

所以，你可以用户进行某些操作后，去触发一些任务。

[liteyou]

定时任务总还是蛮担心的，一旦启动，就像是开闸放出来的猛兽。要么出现队列任务卡住的情况，本该清理的数据堆积如山，；要么干了不该干的事情。总之，完全无人值守的任务，还是定期去喵一眼，比较放心(❁´ω`❁)

[petelin]

我的高可靠性解决方案:
创建订单之后, 写到延迟队列里一个任务, 同时记录数据库, 失效时间

兜底轮训, 每一分钟轮训一遍数据库, 根据订单状况+失效时间, 这两个字段加个索引, 如果觉得处于代付款的订单不多的话,可以加在订单状态上.

成功之后, 改订单状况.

对于我们的业务是够了, 30 分钟能有多少个未付款的订单 ?? k 级别的轮训一遍小事呀~

[bobuick]

python 的话，celery 可以做到。以前做电商做过类似的，可以用 celery 配合 rabbitmq 做成延迟队列的形式。
不过目前市面上也有不少延迟队列服务，可直接使用

[refear99]

创建订单的时候就插入延迟队列，设置 30 分钟延迟
worker 长轮训这个队列，30 分钟自动可见，消费的时候开启事务锁订单，检查是否已支付，如果未支付就关单退优惠券，已支付的话就删除消息

[fortunezhang]

@wangxn 一般我也是这么做，等他查询的时候更改状态。但是自从有了微信模板消息，就 tm 不好用了。客户说 30 分钟没付款，你给他发个模板消息，这就尴尬了

[wangxiaoer]

@hging 我觉得这种方式成本高，你需要考虑异步任务执行意外的情况，比如异常中止怎么办，重启服务器怎么办等，如果考虑异步任务恢复就要面临集群，调度等。

[killerv]

这个不用走队列吧，只需要在操作订单相关的时候对比一下时间就行了吧

[jsrgqinbin]

延迟队列
扫描太耗性能了

[sweelia]

rabbitmq 延时队列，定时任务扫全库扑杀漏网之鱼

[Reign]

楼上又是 crontab 又是队列的真是服了你们了，至于这么复杂么？生成订单写一个时间戳和 ID，下次用户再访问“我的订单”时取消这个超时的订单就行了，如果用户再也不访问这个订单了，你还关心这个 ID 搞毛线啊？