有一个 Redis 通知的问题想问一下大家

[JoseGuo]

最近需要做一个订单超时未支付自动取消的功能
研究一下方案后，暂时决定用监听 Redis 失效 Key 来实现
简单测试了一下可以用，但有一个小问题
网络搜的实现过程 第一步大部分都是打开 redis.conf 里的键事件的通知
即这样设置 notify-keyspace-events Ex
但是我没按这个来 默认的设置没改动 仍然可用
即 notify-keyspace-events ""
有没有大佬可以解释一下这种情况
感谢

[liupeng2579793]

这问题消息队列不好吗

[dzdh]

消息队列+1

[Vkery]

消息队列+2

[rrfeng]

首先，redis 过期监听实现定时器很差劲，即不安全也不高效。

[rrfeng]

也用不到消息队列，看你订单量多少，大部分情况每分钟扫数据库就行了

[crystom]

config get notify-keyspace-events 看看

[sujin190]

https://github.com/snower/forsun

要不试试之前做的一个服务，可以用订单号为 key 创建定时任务，到期可以回调 url ，可以使用 redis 来持久化，我们差不多用到管理数百万任务级别，及时性和并发都还是可以的

[oneisall8955]

redisson 延时队列？有个坑，客户端宕机重启，旧的 key 到时间不触发问题

[nightsky]

几个订单啊？一天几万几十万这个量级的话，放个定时器去操作吧，贼快，还稳定

[reter]

同建议定时任务，每次扫数据库就可以了。
等到数据量大，延时不能忍受的时候，再考虑其他优化方案。

[demoshengxw]

延时队列不是更好么

[JoseGuo]

单体小项目 没集成 MQ 所以没使用消息队列
QZ 定时任务扫的话 每秒一次？ 感觉比较浪费

[JoseGuo]

延时队列持久化是个问题 宕机重启就没了
监听 redis 失效 key 肯定也会存在消息丢失问题
技术比较菜 望见谅

[luin]

这路走得有点弯... keyspace 通知不是用来做这个的。你可以考虑用 redis 的 stream 来做消息队列，不需要额外的服务。

[wxw752]

单体小项目也可以上 mq ，比较稳妥。

不会的话，可以去 B 站尚硅谷大学花几个小时学一下

[RedBeanIce]

@JoseGuo
楼上说的没错，定时任务扫库就行了。请记住两点。
大前提：不是为了学习其他技术的情况下
1 ，请不要过度设计，选择当下最适合最简单的方案，当前的场景与性能而言，扫库是最适合最简单的方案吧
2 ，引入 mq ，redis 等中间件会加深你项目的维护难度

[haoliang]

一个 daemon 就能搞定吧：进程启动时加载全量数据、使用时间轮进行任务排期、根据时间戳之类的 offset 增量添加数据。（单纯想想还挺简单的）

[haoliang]

忘了提虽然设想是单进程，但多线程 /协程是不可避免的 ...

[Chad0000]

op 试试 dapr ，应该有延迟消息。

[Goooooos]

可以用 sortset ，定时扫描 element 是订单号，score 是过期的 timestamp 。
这样比直接扫数据库性能会好一点，相对消息队列简单点