有一个有关订单自动取消的问题，请大家指教一下

[zhangwugui]

前提：是这样的，一笔订单下单之后，如果不支付，会处于待支付状态。而一般这个订单会有类似 30 分钟不支付自动取消订单的功能。

实现：这种功能的实现，可以通过定时任务，每隔 30 秒或一分钟扫描一次。但如果集群环境下，可能定时任务会执行重复。当然我们可以通过类似操作系统 PV 操作限制同一时段只能一个定时任务执行。

目标：我想知道，这种情况，除了定时任务，还有没有其他好点的实现？

想法：目前在领导的提醒下，想到了用消息来处理，下完单后延时 30 分钟发送消息来处理，不知还有没有其他的处理方式，多谢大家，请多多指教。

[BBCCBB]

消息队列里的延时队列, 可靠+时延低

[BBCCBB]

用户自己触发的这种并不能即使恢复库存.

[BBCCBB]

所以还是推荐延时队列, 只要你的代码没问题, 就能保证被消费掉.

[waczx]

rabbitmq 有消息延迟处理的机制。
把订单信息写进一个 queue，并指定消息的过期时间，到期后，rabbitmq 会把这个消息交给另一个 queue 来处理。
很简单，在 admin 后台配置就可以。

[airyland]

redis 定时任务 + 补偿任务：扫描过去 n 分钟内订单进行处理，更新时注意检查状态并且加 lock。

[willvvvvv]

定时任务去扫，操作前加 REDIS 锁

[SlipStupig]

@MiguelValentine 你这样订单到期了就没有了，但是相关的库存，还有用户历史订单也没有了，你这样还不如直接删除这个用户，然后呢，他到时候账号登陆上去，他会自己重新注册一个的新的账户，以后他们再也不敢随便下单了 23333

@Doodlister 你这个复杂度有点高了，一个个对比，如果订单量比较大的话，性能下降会很厉害的

@Jealee 本身 redis 就没有 ACK 机制，你也无法保证你的 producer 不会崩溃，一旦崩溃你如何保证消息不丢失呢，如果有 rdb 和 aof 开启的情况下，我曾经加载过 100g RBD 文件，8 core 32g 内存，差不多要 40 秒才能全部载入完成这个对一些电商场景来说是致命了，如果是 cluster 模式还好一点，但是也会出现短时间的一个数据不一致情况，特殊情况下可能并不能接受这种情况

[zhangwugui]

@SlipStupig 感谢建议。想了想，准备用延时队列试试看看。

[guyskk0x0]

起个独立进程(1 个生产者)，每秒查一次超时订单
select * from order where now() > deadline
，然后扔（分布式）队列里，由多个消费者进程去关闭订单。

[dawncold]

你领导说的那个方法就挺好

[ioth]

没区别，支付宝的订单状态你去参考一下，有时候要学习马家军