谢谢各位的指点 受教了 我再考虑一下用哪种方案 但是好像有点歪楼了 问题本意是为啥配置没打开依然能用
 |
1
liupeng2579793 Jul 11, 2022
这问题消息队列不好吗
|
 |
2
dzdh Jul 11, 2022
消息队列+1
|
 |
3
Vkery Jul 11, 2022
消息队列+2
|
 |
4
rrfeng Jul 11, 2022
首先，redis 过期监听实现定时器很差劲，即不安全也不高效。
|
|
5
rrfeng Jul 11, 2022  1
也用不到消息队列，看你订单量多少，大部分情况每分钟扫数据库就行了
|
 |
6
crystom Jul 11, 2022 1
config get notify-keyspace-events 看看
|
 |
7
sujin190 Jul 11, 2022
https://github.com/snower/forsun
要不试试之前做的一个服务，可以用订单号为 key 创建定时任务，到期可以回调 url ，可以使用 redis 来持久化，我们差不多用到管理数百万任务级别，及时性和并发都还是可以的 |
 |
8
itechify PRO redisson 延时队列？有个坑，客户端宕机重启，旧的 key 到时间不触发问题
|
 |
9
nightsky Jul 11, 2022
几个订单啊？一天几万几十万这个量级的话，放个定时器去操作吧，贼快，还稳定
|
 |
10
reter Jul 11, 2022
同建议定时任务，每次扫数据库就可以了。
等到数据量大，延时不能忍受的时候，再考虑其他优化方案。 |
 |
11
demoshengxw Jul 11, 2022 via iPhone
延时队列不是更好么
|
 |
12
JoseGuo OP 单体小项目 没集成 MQ 所以没使用消息队列
QZ 定时任务扫的话 每秒一次？ 感觉比较浪费 |
|
13
JoseGuo OP 延时队列持久化是个问题 宕机重启就没了
监听 redis 失效 key 肯定也会存在消息丢失问题 技术比较菜 望见谅 |
 |
14
luin Jul 12, 2022
这路走得有点弯... keyspace 通知不是用来做这个的。你可以考虑用 redis 的 stream 来做消息队列，不需要额外的服务。
|
 |
15
rockddd Jul 12, 2022
单体小项目也可以上 mq ，比较稳妥。
不会的话，可以去 B 站尚硅谷大学花几个小时学一下 |
 |
16
RedBeanIce Jul 12, 2022
@JoseGuo
楼上说的没错，定时任务扫库就行了。请记住两点。 大前提：不是为了学习其他技术的情况下 1 ，请不要过度设计，选择当下最适合最简单的方案，当前的场景与性能而言，扫库是最适合最简单的方案吧 2 ，引入 mq ，redis 等中间件会加深你项目的维护难度 |
 |
17
haoliang Jul 12, 2022
一个 daemon 就能搞定吧：进程启动时加载全量数据、使用时间轮进行任务排期、根据时间戳之类的 offset 增量添加数据。（单纯想想还挺简单的）
|
|
18
haoliang Jul 12, 2022
忘了提虽然设想是单进程，但多线程 /协程是不可避免的 ...
|
 |
19
ktqFDx9m2Bvfq3y4 Jul 12, 2022 via iPhone
op 试试 dapr ，应该有延迟消息。
|
 |
20
Sezxy Jul 12, 2022 1
可以用 sortset ，定时扫描 element 是订单号，score 是过期的 timestamp 。
这样比直接扫数据库性能会好一点，相对消息队列简单点 |
 |
21
bthulu Jul 12, 2022
@RedBeanIce 你傻啊, 这是订单支付超时, 要精确到秒的, 你每秒扫一次库吗?
|
 |
22
NewExist Jul 12, 2022
可以使用 redis 的消息队列。对于小项目升级成本不大
|
 |
23
micean Jul 12, 2022
单体小项目为什么还要花精力去维护 mq ？
|
 |
24
hoopan Jul 12, 2022
传统做法就是 crontab 定期执行脚本扫表，如果业务量不大可以这样做。
建议是消息队列，用处多多，以后扩展也方便。消息队列有各类实现方法，redis 也能搞消息队列。 |
 |
25
xaplux Jul 12, 2022 1
单体应用，使用延迟队列实现就行，java 可以使用 DelayQueue ，然后每次重启服务，再从把表中未支付订单数据重新加载到延迟队列就行了
|
 |
26
cxshun Jul 12, 2022
redis 的失效是延时的，它是依赖定时器和主动获取的时候判断的，不要依赖它来做业务，除非你不需要实时。
这种直接用延时队列就好了，RocketMQ 也有，或者自己用定时任务来处理。 |
 |
27
zr8657 Jul 12, 2022
建议上个 mq ，熟练了也就半个小时的事，小规模一个单体 mq 就够了，基本也不用维护
|
 |
28
zzvgtiger Jul 12, 2022
前面好几个人已经说过了 redis 的 key 过期机制用来做这种订单超时未支付自动取消的业务不太合适，刚好前几天看到一篇文章有对比实现这种业务的几种方法的优劣，你可以参考一下。https://mp.weixin.qq.com/s/TBOvb2BKdJUii-XDR50_YQ
|
|
29
JoseGuo OP @RedBeanIce 同意
|
|
30
JoseGuo OP @philchang1995 我看一下 谢谢
|
 |
33
boks Jul 12, 2022
我之前的做法是使用 redis 的有序集合，把过期时间存在 score 里，每秒查一次 score <= 当前时间戳 的数据
|
 |
35
awalkingman Jul 12, 2022
楼上说维护的应该都是老手了。自己搞 demo 可以多尝试一些新技术新东西。生产如果量级不是很大，还是推荐扫表，越简单越好维护，越好调试和排查问题。
开发只是需要几天，维护是没有尽头的。 |
 |
36
tusj Jul 12, 2022
就查订单展示的时候，判断一下状态 + 时间不就好了吗？为啥要引入 redis ？
|
 |
37
oppoic Jul 12, 2022
定时扫库不行，即便到下一次扫库间隔只有一分钟，用户端也无法接受这么长的延迟
redis 自动过期更不行，redis 过期自动删除 key 实现的没那么严谨，网上有文章分析过这个 “订单到时未支付，自动取消” 这是一个经典面试题，我提供几个不一样的思路： 1 ）插入订单表的时候，就有个未支付关闭时间（比如下单时间后的 15 分钟，这个做成可配置的） 2 ）用户端一般可以看到 “未支付倒计时”，倒计时结束了，发请求让服务端关订单（服务端做些验证） |
 |
38
qinxi Jul 12, 2022
@bthulu #21 冷知识. 你可以把 now+1min 时间前需要处理的都扫出来, 已经过期的直接处理, 未来 1 分钟内过期的你可以放队列延时处理 比如 netty 的 HashedWheelTimer
|
 |
40
so1n Jul 12, 2022
公众号看多了把...哪些说监听 key 过期的都是没生产经验的
|
 |
41
flashBee233 Jul 12, 2022
37 楼的 2 ）思路也可以 ，比如规定的是超过 30 分钟未支付订单超时，10:00 下单 10:30 超时 前端检测当前时间是否超过 10:30 且是未完成的订单，但这又依赖前端的请求前端不打开这个页面就不会执行这个操作
|
 |
42
jucelin Jul 12, 2022
定时扫，业务上也配合判定下时间
|
|
43
JoseGuo OP 破案了 确实现在开启的配置是 notify-keyspace-events AE 并不是""
|
|
45
bthulu Jul 12, 2022
@qinxi 更冷的知识, 一分钟数据量有没有可能会把内存撑爆呢? 比如日志类的, 每条数据算 10k, 每秒一千人访问, 每人 10 条日志, 就是 100M. 一分钟就是 6G.
|
 |
46
nekoneko Jul 12, 2022
体量不大的话
1. 时间轮 2. 定时任务 3. 延时队列 |
 |
47
fifa899 Jul 12, 2022
MQ 队列.延迟消费才是正解.redis 都用了.广播通知,延迟消息还是交给 MQ 比较专业
|
 |
49
ccppgo Jul 12, 2022
订单过期时间 + 定时任务才是正解吧 复杂度最低
|
|
50
qinxi Jul 12, 2022
@bthulu #45 你要是非得来杠, 即使每分钟 10 万订单这种方式也可以解决, 思路就是缩短时间 10s 15s 30s 根据情况来.
你已经每分钟 10 万订单了开 50 台机器处理不过分吧? 你算算我现在每台机器多少数据呢? 这种问题需要处理数据分配而已. 分发节点负责把 10 万的 id 分发给 50 个节点不复杂吧? |
 |
51
lesismal Jul 12, 2022
redis 通知是存在的问题，比如通知的瞬间，刚好你监听事件的这个服务与 redis 断线了、没收到通知。
时间+定时任务判断处理订单状态就行了。 这里的时间与隔壁帖子根据当前时间计算当前体力、而不是定时去计算更新增加后的体力的玩法其实是类似的。 可以考虑记下这个词：COW(copy on write)，其实本质就是只在真正需要的时候才去触发实际操作、尽量减少成本的浪费。 |
 |
52
liudaolunhuibl Jul 12, 2022
redis 的这个 key 通知机制不太好，建议用消息队列的延时队列或者自己实现一个时间轮算法，总之需要的效果就是达到一段时间之后再去检查状态
|
 |
53
wu00 Jul 12, 2022
肯定是上“定时任务”调度器，一般都提供延时任务。
比如 quartz 、sidekiq 、hangfire 之类的，能统计、执行结果、重试。 自己用 redis/mq 实现一套耗时耗力还不靠谱 |
|
54
wu00 Jul 12, 2022
下单的同时创建一个 delayjob ，xx 分钟后执行，第三方组件去负责调度就行了。
你只管控制 delayjob 里面并发和幂等，未支付就关闭，其他状态就忽略，几乎能控制在秒级，下单并发大你就不会在这提问了。 |
 |
55
nilai Jul 12, 2022
redis 的 key 的过期机制 并不是完全精确的过期， 它内部有算法，比如每次按一定的百分比来进行抽样。 这样有可能会导致明明已经过期的 key, 但是它还存在于 redis 中
|
 |
56
VisionKi Jul 12, 2022
前段时间也在找类似的解决方案，楼主的方案在于如果宕机了就无法监听到了，最后用了 redis 的 zset 实现。
实现方法： 存入订单的 id ，以过期时间的时间戳为 score 。只需要每秒取出分数小于当前时间戳的 id ，再异步处理业务即可。 有个问题就是 zset 没有类似 LPOP 的原子性操作，不能取出删除一步到位，不过对于单机应用来说也够用了。 |
Select Language