求一个定时取消订单的解决方案

[yangyuhan12138]

目前我们的方案是 rabbitmq 的死信队列,并发不高还好,但是我们最近会搞一波促销活动,订单超时时间是 35 分钟,意思就是有 35 分钟时间窗口的订单都会进入死信队列,害怕把 mq 弄挂了...或者说 rabbitmq 有没有啥水平扩容的方案,我们现在的模式为镜像模式,三台机器存的是一样的内容,所以消息的上限还是为单台机器的容量

还有一个方案是刚刚搜到的,就是 redis 的 zset,用时间戳当 score,这个方案感觉还挺不错呢,有没有人用过

大佬们多多给点建议 谢谢大家了

[helone]

关键词 延时队列

[wangyanrui]

并发这得多高啊？ rabbitMQ 万儿八千的并发还是可以的呀。

[yangyuhan12138]

@helone 搜了 搜了好多种方案 我比较倾向的就是 mq 和 zset 想看看大家生产上是选择的啥解决方案 咨询了些大佬 他们有点不推荐 mq,反而更推荐定时任务,这个我就有点费解了...

[yangyuhan12138]

@wangyanrui 35 分钟的窗口应该会有几十万条消息堆在 mq 里边 因为我们是在下单的时候就会存 mq 延时队列,35 分钟后再通知,查询订单是否支付,如果未支付就给他取消订单

[xuanbg]

没明白订单超时为啥要用队列？付款的时候检查一下是否超时不就行了吗？

[wangyanrui]

@xuanbg 定时取消订单呀兄弟 = =

[wangyanrui]

@yangyuhan12138 估算一下队列最大长度和空间，如果超了默认值就设置一下 RabbitMQ 的参数就 OK 啦

如果单你说的几十万条订单消息，完全没压力

[Varobjs]

半小时几十万订单待取消？转化率按几百比 1 算，一小时几千有效订单，一天几万到几十万有效订单，

有这量还在考虑这玩意啊

[tanrenye]

订单实际状态用定时任务跑就行了，涉及到显示和支付，单独再用代码判断即可（比如返回给前端，根据时间等条件修改返回的数值，支付的时候也是，用代码做判断），任何使用队列、定时器都不能做到 100%实时，这是我的经验。

[BBCCBB]

rabbitmq 能堆很多消息.
redis 的问题就是持久化不完善, 挂了就惨了..

开源的 rocketmq 能实现的定时 level 也有限,

如果一定要没容量限制, 就买云上的 mq, 比如 aliyun 上的 mq, 支持任意事件量级的延迟消息...

不过一般用 rabbitmq/redis 再加扫表防止遗漏都能解决了..

[dongisking]

redis 的 zrangebysocre 的确可以但是没用过，网上都是说把时间戳存 score，然后找一个东西监听这些 key 然后删掉大于这个时间戳的成员

[fewok]

正确评估体谅，不要过度设计。
一个取消订单，延迟队列都扛不住。我就好奇，正向下单，服务能扛住嘛？

[cabing]

软件的设计依赖需求，而需求一般分作三个大块: 1 功能需求，2 质量属性，3 约束

对所做的技术选型的约束需要有全面的了解啊。

你们需要压测下 rabbitmq 的性能。比如 mysql 非 ssd 单机读 2000，ssd6000，单机写 1000 ssd 单机 3000

rabbitmq 队列，业务场景比较单一，性能估计 50 倍以上于数据库，一般场景下应该是没问题。


比较这些量都不大。

半个小时 100 万 1000000/1800 平均峰值 555，预估最高峰值平均的 5 倍 ，就是 3000 以内。。。数据库都快能抗住了。。。别担心。



当然你可以使用 redis 异步做个备案也行。

[yangyuhan12138]

@Varobjs 不是待取消 我们是下单之前都会放一下 到了三十五分钟还没支付就给他取消并还原库存, 所以就是支付了的也会通知

[kaneg]

每隔一分钟查询数据库大于 35 分钟的订单然后取消不行吗？

[tairan2006]

rabbitmq 本来就是分布式的，Erlang 写的东西不都是分布式的么…没必要想别的方案，用好 mq 就可以解决问题

[yangyuhan12138]

@wangyanrui 现在我们就是不太知道 mq 到底能存多少 而且我也没搜到水平扩容的方案,他们推荐的都是出队速度要大于入队速度才好
@tanrenye 谢谢分享 我懂你意思了 但是定时任务可能会给数据库比较大的压力呀 而且这个方案可能改动比较大哦
@BBCCBB 能上云早上了 哈哈哈哈 不让上云...
@dongisking 对的 我现在比较倾向这个方案
@fewok 这个只要订单创建成功就会入队 还是有点吓人 这里可能是瓶颈 其他的流程我们也在改造...
@cabing 不是速度问题 速度到无所谓 本身就是一个异步流程 主要是容量问题 怕的是存不下 几十万我觉得是没啥 但是领导 你懂得... 几十万 消息 就算 10k 每条 几十万也才几百 m 把 而且应该远小于 10k 每条的
@kaneg 这个可能给数据库造成比较大的压力 而且可能重复处理 需要做一些处理才行

[yangyuhan12138]

@tairan2006 现在是镜像模式 他的分布式叫集群更合适吧 每台机器存的消息是一样的 容量上线就是单机容量 他的分布式只是提高了吞吐量

[wangyanrui]

@yangyuhan12138 估算每条消息的大小，估算消息条数
然后 https://www.rabbitmq.com/memory.html

想多存点就加内存呗，反正内存比程序员的时薪要便宜，hhh

[cabing]

容量问题。模拟线上场景，单机压测下啊。

出个测试报告给领导，同时需要附上你的备用方案。

但是，划重点：你需要有 1-2 个备用方案。涉及到金额，怎么过分小心都不为过。