上海一家做服饰包鞋穿上用品的网站做房产网站长

上海一家做服饰包鞋穿上用品的网站,做房产网站长,做网站哪个软件好,做外贸一年能赚多少“Redis 定时任务”这个概念通常有两种层面的解读#xff1a;内部原理#xff1a; Redis 自身是如何管理 key 的过期时间#xff08;TTL#xff09;的#xff1f;它是怎么知道并在某个时间点删除数据的#xff1f;应用实现#xff1a; 开发者如何利用 Redis 实现分布式的…“Redis 定时任务”这个概念通常有两种层面的解读内部原理Redis 自身是如何管理 key 的过期时间TTL的它是怎么知道并在某个时间点删除数据的应用实现开发者如何利用 Redis 实现分布式的“延时队列”或“定时任务”例如下单 30 分钟后未支付自动取消我们分别来深入讲解。一、 Redis 内部原理Key 的过期策略你可能会以为当你设置EXPIRE key 60时Redis 会给这个 key 启动一个倒计时器时间一到就触发删除。但这在海量数据下是不可能的因为 CPU 撑不住。Redis 采用的是惰性删除 (Lazy Deletion)定期删除 (Periodic Deletion)相结合的策略。1. 惰性删除 (Lazy Deletion)原理Redis 不会主动去盯着 key 什么时候过期。触发时机当客户端去访问某个 keyget/set 等操作时Redis 会先检查“哎这个 key 设置了过期时间吗过期了吗”如果过期了直接删除返回nil。没过期正常返回数据。优缺点极其节省 CPU但极其浪费内存。如果大量过期的 key 再也没被访问过它们就会一直占着内存不释放。2. 定期删除 (Periodic Deletion)为了解决惰性删除导致的“内存泄露”问题Redis 有一个后台周期性任务。原理Redis 默认每秒运行 10 次通过hz参数配置serverCron任务。流程从设置了过期时间的 key 集合中随机抽取20 个 key。检查这 20 个 key删除其中已过期的。如果过期的 key 比例超过 25%则重复步骤 1说明过期的很多要多删点。限制为了防止这个循环卡死主线程Redis 是单线程的它有一个执行时间上限默认 25ms。如果超时立刻停止等下一轮再说。总结Redis 的过期不是“准时”的而是在访问时和后台随机抽查时清理的。二、 应用实现基于 Redis 的定时任务延时队列这是开发者最关心的部分。假设你要做“订单 30 分钟自动关闭”在 NestJS 或其他后端中怎么用 Redis 实现方案 1Redis ZSet (Sorted Set) ——最推荐、最主流这是实现分布式延时队列的标准做法。原理利用 ZSet 的Score来存储任务的执行时间戳。数据结构Key:delay_queueScore:Date.now() 30 * 60 * 1000(未来执行的时间戳)Member:Order ID(或任务的 JSON 数据)执行流程 (轮询 Loop)消费者 (Consumer)每秒或几百毫秒轮询 Redis。执行命令ZRANGEBYSCORE delay_queue 0 当前时间戳 LIMIT 0 1。意思是把“截止到现在应该执行的任务”拿出来 1 个。如果拿到了任务原子性移除使用ZREM移除该任务防止重复执行。注意在多实例并发下通常建议使用Lua 脚本将ZRANGE和ZREM原子化确保只有一个消费者抢到任务。处理业务逻辑如关闭订单。优点精度高支持海量任务原生支持排序。缺点消费者需要不断轮询Polling空转时会增加 Redis QPS。订单 30 分钟自动关闭的具体实现流程假设现在是12:00用户下了一个单order_1001。第一步生产者入队 (ZADD)用户下单成功后代码往 Redis 里写一条记录命令ZADD delay_queue 12:30的时间戳 order_1001含义“Redis 帮我记一下order_1001 这个单子要在 12:30 处理。”注意这时候数据是存在的不是等它消失。第二步消费者轮询 (ZRANGEBYSCORE)你有一个后台死循环脚本Consumer每秒钟问一次 Redis。12:01 问“Redis有没有分数 12:01的订单”Redis没有。12:29 问“Redis有没有分数 12:29的订单”Redis没有。因为 order_1001 的分数是 12:3012:30:01 问“Redis有没有分数 12:30:01的订单”Redis“有order_1001 的分数是 12:30它到期了”第三步执行并删除 (ZREM)消费者拿到了order_1001去数据库查一下这个订单支付没有没支付 - 执行关单逻辑。已支付 - 忽略。关键从 Redis 里删掉这行记录 (ZREM delay_queue order_1001)防止下一秒又把它取出来重复执行。方案 2Redis KeySpace Notifications (键空间通知) ——不推荐Redis 有一个功能当 Key 过期被删除时发布一个 Pub/Sub 事件。原理开启配置notify-keyspace-events Ex。设置SET order_123 data EX 1800(30分钟过期)。应用订阅__keyevent0__:expired频道。当 key 过期消失时应用收到通知解析 key 里的 ID去关单。为什么极其不推荐不可靠Redis 的 Pub/Sub 是“发后即忘”的。如果你的服务刚好重启了或者网络抖动了一下这个“过期事件”就丢了Redis 不会重发。你的订单就永远关不掉了。不准时结合第一部分说的“定期删除”原理一个 key 过期了可能很久之后才会被 Redis 的随机算法抽中并删除此时才会发通知。延迟可能高达数分钟。方案 3Redisson DelayedQueue (Java/Node 生态封装)如果你不想手写 ZSet 的轮询逻辑很多客户端库如 Java 的 Redisson或者 Node.js 的 BullMQ封装好了。原理它是ZSet Pub/Sub的结合体。数据存在 ZSet 里。客户端一旦有新任务加入或者有任务即将到期会通过 Pub/Sub 通知消费者“醒醒干活了”。这样避免了 ZSet 方案中高频率空轮询的 CPU 浪费。