必须编码score防精度丢失且用Lua原子查删，因毫秒时间戳作score会导致ZRANGEBYSCORE漏任务和并发重复消费；编码方案为时间戳×1024+序列号，解码用整数除法与取模；Lua脚本确保查删原子性。
直接用毫秒时间戳当 score 会丢任务，且并发时必然重复消费——必须做两件事：score 编码防精度丢失 + Lua 原子查删。
为什么毫秒时间戳直接当 score 不行
Redis ZSet 的 score 是 double 类型，有效精度约 52 位。当前毫秒时间戳（如 1725507540123）已逼近 2^52 ≈ 4.5e15，再过几年就会出现相邻整数无法区分的情况，ZRANGEBYSCORE 可能漏掉部分到期任务。
更常见的是业务级翻车：多个 worker 同时执行 ZRANGEBYSCORE 拿到同一组任务，再各自 ZREM，结果任务被重复处理。
- 浮点精度问题在 2255 年后才彻底爆发，但实际项目中只要时间戳 >
1717023456789（2024 年中），就可能出现ZRANGEBYSCORE边界行为异常 - 哪怕只有一台 worker，若任务处理中途崩溃，没来得及
ZREM，下次轮询还会再次拉取——这不是并发问题，是原子性缺失
如何编码 score 保证精度和顺序
核心思路：把毫秒时间戳左移 10 位（×1024），再用低 10 位存自增序列号（0–1023），既避开 double 截断，又支持同毫秒内多任务保序。
例如：任务计划在 1725507540123 毫秒执行，这是第 7 个该毫秒插入的任务，则 score = 1725507540123 * 1024 + 7 → 1766915721085959。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 这个值远小于
2^52（≈4503599627370496），长期安全 - 解码时只需
score // 1024得到原始毫秒时间戳，score % 1024得到序列号 - PHP/Java/Go 等语言里用整数运算即可，无需字符串转换或 float 中转
必须用 Lua 脚本原子获取并删除任务
不能分两步调用：ZRANGEBYSCORE 和 ZREM 之间存在竞态窗口，哪怕只有 1ms，也足够另一个 client 插入或读取。
以下脚本从 delayed:queue 中安全取出最多 10 个已到期任务：
eval "local now = tonumber(ARGV[1]) local n = tonumber(ARGV[2]) local tasks = redis.call('ZRANGEBYSCORE', KEYS[1], '-inf', now, 'LIMIT', 0, n) if #tasks > 0 then redis.call('ZREM', KEYS[1], unpack(tasks)) end return tasks" 1 delayed:queue 1725507540123 10-
ARGV[1]必须传数字（不是字符串），否则tonumber()返回nil，比较失效 - 脚本返回的是 member 列表，不是 score；若需 score，加
WITHSCORES并调整解析逻辑 - 生产环境建议限制
n（如 ≤50），避免单次操作阻塞过久
消费者循环里容易忽略的校准逻辑
光靠定时轮询会浪费 CPU。理想做法是：没任务时，用 ZRANGE queue_key 0 0 WITHSCORES 查出队列中最近一个任务的 score，然后计算休眠时长 score - current_timestamp，再进入阻塞等待（配合 Pub/Sub 或客户端 timeout）。
这个差值可能为负——说明有任务已到期但没被及时捞走，此时应立即触发一次处理，而不是继续睡。
- Redis 本身不提供“到期自动通知”，所有“唤醒”都得靠外部信号或主动探测
- 如果用
SUBSCRIBE监听信号通道，务必确保每次PUBLISH都发生在ZADD之后，且两者在同一个连接或事务中完成（推荐用 pipeline） - 真正难的不是实现，而是验证：你得模拟时钟跳变、网络分区、进程 crash 等场景，确认每种情况下任务最多执行一次
