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

[herozw]

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

[lepig]

@zhea55 +1

[imn1]

如果不需要推送通知的话，有必要搞定时器么？
判定时间状态不允许操作就是了

[zhea55]

Redis 里面有个 expire 的功能，时间到期了，会删除对应的 key

google：redis expire callback

貌似过期了可以得到通知。


性能问题，第三方去考虑。

[pubby]

@qiujin +1 beanstalkd 好用

[tagtag]

被动的超时处理应该没什么疑问，主动的应该只能轮询了吧。

[gamexg]

订单本身有超时时间字段，需要关注超时时设置这个字段。

每次客户查看订单时检查下是否超时来显示订单状态。

另外后台有个每分钟或更长时间的定时任务处理超时订单，直接查数据库，这个任务主要负责回滚库存或发邮件通知等操作。

除非很大的量，不然太建议过早优化上队列之类的。
即使上专门的队列也需要一个直接查数据库的兜底机制来防止队列丢失数据或执行错误等造成超时订单长时间未处理。

[qq316107934]

大家都不考虑订单超时之后商品回库的问题吗？感觉还是要用定时器啊

[Patrick95]

对啊楼上好多人提出的解决方案都没有考虑过订单支付超时商品回库的问题。

[cowpea]

@whileFalse 我也觉得分钟就行了，没有观测者的话，差个几十秒也没啥（业务特别严谨就另说，再说回来，能被超时取消的单子，用户也不会在乎那几十秒，右侧取整分肯定会多几十秒）。有观测的话，判断超时做处理就好了。

[lazypu]

redis.
每秒都去查询 redis 总不会有啥问题了吧.

[linpf]

我是做了定时任务，同时每次访问该数据的时候也判断一下。

[LukeLeeee]

python 的话 celery 有一个 countdown 的功能很合适，也能精确到订单维度，在处理 task 的时候订单支付超时 然后商品回库等一系列操作

[UnPace]

用户主动触发改变订单状态肯定不可行，最合理的就是定时任务扫。

[ixixixe2]

@qq316107934 搞个 0 点自动检测不就好了

[cxbig]

Cronjob 每分钟跑一次可以了

[gcli]

定时任务，每分钟执行一次，超时的订单，更改订单状态，释放资源

[orderc]

google 延迟队列

[dullwit]

DelayQueue，支持延时获取元素的无界阻塞队列

[gcli]

好吧，涨知识了，延迟队列
接下来准备把定时任务替换为延迟队列

[minotaur]

延迟消息队列 简单点就 redis