zrevrangebyscore 不适用于超时任务检测，因其按 score 降序返回，而超时检测需升序查找 score ≤ 当前时间戳的任务；正确做法是用 zrangebyscore tasks -inf [current_timestamp] 配合 lua 原子执行扫描与删除，并确保 score 为高精度到期时间戳以避免排序混乱和堆积性能问题。
为什么 ZREVRANGEBYSCORE 不能直接用于超时任务检测
因为 ZREVRANGEBYSCORE 返回的是按 score 降序排列的元素，而超时检测本质是“找出 score 小于等于当前时间戳”的任务——这需要升序范围查询，用 ZRANGEBYSCORE 更自然。强行用 ZREVRANGEBYSCORE 不仅逻辑反直觉，还容易漏掉边界情况（比如刚好等于当前时间的任务是否应被处理）。
常见错误现象：ZREVRANGEBYSCORE tasks +inf (1698765432 想取“早于当前时间”的任务，结果返回空——因为 +inf 是最大值，(1698765432 是开区间，方向错配导致范围无效。
- 超时任务的 score 应设为**到期时间戳**（如
System.currentTimeMillis() / 1000 + 300表示 5 分钟后过期） - 检测时用
ZRANGEBYSCORE tasks -inf [current_timestamp]获取所有已到期任务 - 必须加
[（闭区间），否则current_timestamp这一刻到期的任务会被跳过
如何原子性地取出并删除已超时任务
单纯 ZRANGEBYSCORE + ZREM 有竞态风险：两个进程同时查到同一任务，都去处理，造成重复执行。必须用 Lua 脚本保证原子性。
实操建议：写一个 Lua 脚本，先用 zrangebyscore 扫描，再用 zrem 删除，最后返回被删元素：
eval "local res = redis.call('zrangebyscore', KEYS[1], '-inf', ARGV[1]); if #res > 0 then redis.call('zrem', KEYS[1], unpack(res)); end; return res" 1 tasks 1698765432
注意点：
-
unpack(res)在 Redis 7.0+ 可用；老版本需改用redis.call('zrem', KEYS[1], table.unpack(res)) - 脚本中不要用
ZREMRANGEBYSCORE直接删——它不返回元素内容，你无法知道删了哪些任务 - 如果任务量大，避免一次扫太多，可限制数量：
ZRANGEBYSCORE tasks -inf [ts] LIMIT 0 100
score 设计不当导致排序失效的典型场景
当多个任务在**同一秒内到期**，且 score 只精确到秒，ZRANGEBYSCORE 返回顺序不确定——Redis 对相同 score 的元素不保证插入顺序，ZSet 内部用 dict + skiplist 实现，相同 score 下按 member 字典序排，但你通常不控制 member 名字。
解决办法：score 必须带足够精度，或嵌入唯一性信息：
- 用毫秒级时间戳（
System.currentTimeMillis()），避免秒级碰撞 - 若必须用秒，拼上自增 ID 或随机后缀：
1698765432:001，再转为浮点数或 base64 编码存入 score（注意 Redis score 是 double，精度上限约 2^53） - 避免用字符串做 score，
ZRANGEBYSCORE会按数值比较，"1698765432a"会导致错误解析
高并发下 ZSet 扫描性能骤降的原因和缓解方式
当任务量达百万级，ZRANGEBYSCORE ... LIMIT 0 100 看似只取 100 条，但 Redis 仍需从 skiplist 头部遍历到目标位置，复杂度是 O(log N + M)，M 是实际扫描节点数。如果大量任务堆积未清理，skiplist 层变深，延迟明显上升。
优化关键不是“怎么查得快”，而是“不让它堆”：
- 消费端必须稳定运行，失败任务要重入队（比如把失败的 member 用新 score 再
ZADD回去） - 定期用
ZREMRANGEBYSCORE tasks -inf [old_timestamp]清理真正废弃的旧任务（如 7 天前的） - 不要依赖单个 ZSet 存所有任务；按业务拆分，比如
tasks:order、tasks:notify，降低单个结构压力
真正难的不是命令怎么写，是 score 的语义是否清晰、清理策略是否闭环、以及有没有在任务失败时破坏这个闭环。
