这是一个创建于 1350 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，对阿里云上的机器订单，过期前通知用户。怎么做到即使处理大量用户订单通知，也能做到足够的准确呢？如果用消息队列的延时队列的话，消息堆积了怎么处理？如果用定时任务的话，服务器的 CPU 顶得住吗？
 |
1
securityCoding 2021-04-16 17:40:42 +08:00  1
有意思这个问题,说说我的想法:
- 过期时间可能很长,延迟消息没有那么大的时间维度 总体思路是: 定时任务+多次延时消息 1. 假设过期时间为 30 天,在 20 天以前采用定时任务扫描的方式检查是否到了消息投递周期,如果剩余时间小于 10 天,则开始投递到消息队列,假如消息队列最大延时时间为 7 天,则第一投递延时 7 天,之后不断实时计算缩小延时,直到达到阈值开始真正消费 - 消息堆积 这是个比较通用的问题场景 1. 首先排查消费代码性能,优化到最佳性能 2. 场景允许的话采用批量拉取,批量消费 3. 水平扩充消费组实例 4. 使用消息队列两个指标一定要关注 , 消息投递耗时和消费耗时 至于你说的 cpu 压力大,这个不是问题,你应该问你的 db 扛得住吗 233 |
 |
2
night98 2021-04-16 18:01:40 +08:00
分区域分片进行就行，剩下的就是按楼上老哥的说法，提前一天跑个批就行了，然后扔 mq 里面等处理就完事了，延迟时间也就一天左右，消费的话也没啥会阻塞的，直接关机器清理资源，这些都可以异步。
|
 |
3
qxqsxbd 2021-04-16 18:16:11 +08:00
每天跑一遍定时任务，检查所有人的过期时间，过期时间在 24 小时（或者某个特定时间）内的创建一个新的定时任务
|
 |
4
winRain OP 多谢各位的建议，我看了一些帖子之后也有了自己的一个想法。那就是添加任务的时候，对当前年月日分别进行 hash，然后组装在一起，作为记录的一个字段。然后以一个定时任务，每日按刚才的字段去查询，将当日的任务放到不同的队列上去消费。
|
 |
5
ch2 2021-04-16 21:34:48 +08:00
那个通知又不是卡点的，误差个几分钟几十分钟几小时都行
|
 |
6
skybrown 2021-04-17 20:24:49 +08:00
优先队列？
|
 |
7
kerro1990 2021-04-17 21:46:06 +08:00
时间戳排序就行了，先过期的排前面，然后分批处理
|
Select Language