Redis定时任务-开发者社区

“Redis 定时任务”这个概念通常有两种层面的解读：

我们分别来深入讲解。

你可能会以为当你设置EXPIRE key 60时，Redis 会给这个 key 启动一个倒计时器，时间一到就触发删除。但这在海量数据下是不可能的，因为 CPU 撑不住。

Redis 采用的是惰性删除 (Lazy Deletion)+定期删除 (Periodic Deletion)相结合的策略。

原理：Redis 不会主动去盯着 key 什么时候过期。
触发时机：当客户端去访问某个 key（get/set 等操作）时，Redis 会先检查：“哎，这个 key 设置了过期时间吗？过期了吗？”
- 如果过期了：直接删除，返回nil。
- 没过期：正常返回数据。
优缺点：极其节省 CPU，但极其浪费内存。如果大量过期的 key 再也没被访问过，它们就会一直占着内存不释放。

为了解决惰性删除导致的“内存泄露”问题，Redis 有一个后台周期性任务。

原理：Redis 默认每秒运行 10 次（通过hz参数配置）serverCron任务。
流程：
1. 从设置了过期时间的 key 集合中，随机抽取20 个 key。
2. 检查这 20 个 key，删除其中已过期的。
3. 如果过期的 key 比例超过 25%，则重复步骤 1（说明过期的很多，要多删点）。
限制：为了防止这个循环卡死主线程（Redis 是单线程的），它有一个执行时间上限（默认 25ms）。如果超时，立刻停止，等下一轮再说。

总结：Redis 的过期不是“准时”的，而是在访问时和后台随机抽查时清理的。

这是开发者最关心的部分。假设你要做“订单 30 分钟自动关闭”，在 NestJS 或其他后端中，怎么用 Redis 实现？

这是实现分布式延时队列的标准做法。

原理：利用 ZSet 的Score来存储任务的执行时间戳。
数据结构：
- Key:delay_queue
- Score:Date.now() + 30 * 60 * 1000(未来执行的时间戳)
- Member:Order ID(或任务的 JSON 数据)
执行流程 (轮询 Loop)：
1. 消费者 (Consumer)每秒（或几百毫秒）轮询 Redis。
2. 执行命令ZRANGEBYSCORE delay_queue 0 <当前时间戳> LIMIT 0 1。
  - 意思是：把“截止到现在应该执行的任务”拿出来 1 个。
3. 如果拿到了任务：
  - 原子性移除：使用ZREM移除该任务（防止重复执行）。
  - 注意：在多实例并发下，通常建议使用Lua 脚本将ZRANGE和ZREM原子化，确保只有一个消费者抢到任务。
4. 处理业务逻辑（如关闭订单）。
优点：精度高，支持海量任务，原生支持排序。
缺点：消费者需要不断轮询（Polling），空转时会增加 Redis QPS。

订单 30 分钟自动关闭的具体实现流程：

假设现在是12:00，用户下了一个单order_1001。

第一步：生产者入队 (ZADD)用户下单成功后，代码往 Redis 里写一条记录：

第二步：消费者轮询 (ZRANGEBYSCORE)你有一个后台死循环脚本（Consumer），每秒钟问一次 Redis。

12:01 问：“Redis，有没有分数 <= 12:01的订单？”
- Redis：没有。
12:29 问：“Redis，有没有分数 <= 12:29的订单？”
- Redis：没有。（因为 order_1001 的分数是 12:30）
12:30:01 问：“Redis，有没有分数 <= 12:30:01的订单？”
- Redis：“有！order_1001 的分数是 12:30，它到期了！”

第三步：执行并删除 (ZREM)消费者拿到了order_1001：

Redis 有一个功能：当 Key 过期被删除时，发布一个 Pub/Sub 事件。

原理：
1. 开启配置notify-keyspace-events Ex。
2. 设置SET order_123 "data" EX 1800(30分钟过期)。
3. 应用订阅__keyevent@0__:expired频道。
4. 当 key 过期消失时，应用收到通知，解析 key 里的 ID，去关单。
为什么极其不推荐？
1. 不可靠：Redis 的 Pub/Sub 是“发后即忘”的。如果你的服务刚好重启了，或者网络抖动了一下，这个“过期事件”就丢了，Redis 不会重发。你的订单就永远关不掉了。
2. 不准时：结合第一部分说的“定期删除”原理，一个 key 过期了，可能很久之后才会被 Redis 的随机算法抽中并删除，此时才会发通知。延迟可能高达数分钟。