不能直接用zrem判断并消费任务，因为zrangebyscore与zrem分步执行存在竞态，会导致重复消费或误删；必须用lua脚本将“查询到期任务+条件删除”封装为原子操作，确保取出即删除且精准匹配时间条件。
为什么不能直接用 ZREM 判断并消费任务
延时队列的核心是「在指定时间点精准、不重复地执行一次任务」。如果先用 ZRANGEBYSCORE 查出待执行任务，再用 ZREM 删除，中间存在竞态：多个消费者可能查到同一任务，导致重复消费；而单纯靠 ZREM 返回值无法确认是否真删掉了目标元素（它只返回删除个数，不反馈具体删了谁）。
必须把「读取 + 条件删除」打包成原子操作——Lua 脚本是 Redis 唯一能保证这点的机制。
EVAL 脚本里怎么安全取出并移除最小分值且满足时间条件的任务
关键逻辑是：只取分值 ≤ 当前时间戳（unix timestamp）的最老一条任务（score 最小），且确保取出即删除，不给其他客户端机会。
- 用
ZRANGEBYSCORE key -inf <timestamp> LIMIT 0 1</timestamp>拿第一个候选任务（避免全量扫描） - 拿到结果后立刻用
ZREM key member删除它——但必须在 Lua 中串行执行，且加判断：仅当该 member 确实存在且 score ≤ timestamp 才删（防止时钟漂移或重复触发） - 脚本返回值设为任务内容（
member），方便客户端直接使用；若无匹配项，返回nil
示例脚本：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
eval "local task = redis.call('zrangebyscore', KEYS[1], '-inf', ARGV[1], 'limit', 0, 1) if #task == 0 then return nil end redis.call('zrem', KEYS[1], task[1]) return task[1]" 1 my_delay_queue 1717023600
时间戳精度和时钟同步怎么影响消费准确性
Redis 本身不维护绝对时间，ARGV[1] 是客户端传入的时间戳。如果应用服务器时钟快于 Redis 服务器（比如 NTP 同步延迟或虚拟机时钟漂移），会导致任务「提前被消费」；反之则延迟。
- 生产环境务必让所有客户端和服务端走同一 NTP 源，误差控制在 100ms 内
- 不要用
redis.call('time')做判断——它返回的是 Redis 进程启动时间 + uptime，不是当前 Unix 时间 - 对精度要求高的场景（如金融定时结算），建议在 Lua 中多加一层保护：用
redis.call('zscore', KEYS[1], task[1])二次校验分值是否仍 ≤ ARGV[1]，再删
为什么不用 ZPOPMIN？它看起来更简洁
ZPOPMIN 确实能原子弹出最小分值元素，但它不支持「按分值范围过滤」——它总是弹出全局最小的那一个，哪怕它的分值远小于当前时间（比如一个已过期 1 小时的任务卡在队列里）。这会导致：旧任务挤占新任务的执行顺序，甚至因反复失败而持续阻塞。
-
ZPOPMIN适合严格 FIFO 的优先队列，不适合延时队列 - 延时队列必须绑定时间条件，所以绕不开
ZRANGEBYSCORE+ 条件ZREM组合 - 如果用
ZPOPMIN，还得额外做「检查分值是否超时」+「不满足就放回」，反而破坏原子性
真正容易被忽略的是：Lua 脚本里两次 redis.call 调用之间没有锁，但整个脚本是原子的——只要逻辑写对，就不会有中间态暴露给其他客户端。别为了省一行代码牺牲语义正确性。
