关注一下 我以前在业务上也有几次准备用key过期通知，就是怕丢失（实际没测过）。后来放弃了

@imhered 因为开发任务比较紧，所以想到这个当时也怕会丢失，实际使用的时候确实丢失了，所以就想问问社区有没有更好的解决方案

@wang-weifeng 其实我觉得吧，node做异步分片做的好，时间差不会太大，用setTimeout也没什么问题

@zy445566

用setTimeout问题可大了，少量的延迟任务(几十个)没问题，但是一旦上百上千上万个延迟任务，那问题可就大了。

任务不能持久化，一旦进程崩溃，任务全部丢失，以及多进程下的问题，还有时间误差大的问题。

比较好的肯定是用redis，分布式，多进程，持久化都能够很好的支持。

再不济单进程也是使用一些数据模型来实现定时，比如timer-whell

来自酷炫的 CNodeMD

@axetroy

用户扫码输入信息后，1分钟开始指导用户做另一个事，然后在过2分钟出一个结果，结束后，另一个用户继续填写，继续这种操作，同时同一时刻也会有很多个这个用户扫码完成这个任务，接着下一组

在种需求下，每个用户就最多就两个setTimeout，针对同一时刻会有很多用户，我觉得10W用户扛一个实例就相当相当不错了，顶天20W压栈。压力就算略大，伸缩10个实例，应该问题也不是很大。 瞬时超过100W+单redis也没吊用，集群不大的话，就算扛了并发，消费都要好一会。 题外话：不是说node的web应用的瓶颈一定就是CPU运算，有的时候数据交换也会把网卡给堵死。

来自酷炫的 CNodeMD

@wang-weifeng redis的键消息通知采用的是发布即忘的策略，node单个实例有可能出现断线的情况，可以通过多个实例来提高可靠，但只需要一个实例来处理，这里的话考虑加锁或者算法。加锁可以考虑 ioredis-lock

@fightAndLearn 谢谢，我来看一下

LZ说的键到期通知丢失可能是因为Redis内存使用超过设置的maxmemory，那个键还没过期就直接被redis的近似LRU算法踢掉了，所以就没有到期通知了

@nullcc 根据的提示，我看了一下， 然后我看这边的信息是不是Redis 的内存消耗峰值大于了由 Redis 分配器分配的内存总量，造成了这个问题

可以用阿里云的 MQ 啊，发送定时消息。