使用毫秒级时间戳作为分数，并在分数相同时引入唯一序列号或采用复合分值编码，可避免 Redis ZSET 因字典序排序导致的消息乱序。生产环境必须配合 Lua 脚本实现“查询 + 删除”的原子操作，防止重复消费。

命令速用版

以下 Lua 脚本可原子性地获取并删除到期任务，避免多消费者竞争导致的重复处理：

local key = KEYS[1]\nlocal now = ARGV[1]\nlocal limit = ARGV[2]\n\nlocal tasks = redis.call('ZRANGEBYSCORE', key, '-inf', now, 'LIMIT', 0, limit)\nif #tasks > 0 then\n    redis.call('ZREM', key, unpack(tasks))\nend\n\nreturn tasks

调用时传入队列 Key、当前毫秒时间戳和每次获取数量。脚本执行期间 Redis 会阻塞其他命令，保证任务不会被多个消费者同时拿到。

为什么会这样

Redis ZSET 在分数（Score）相同时，会按照成员（Member）的字典序进行二级排序，而不是按插入时间。

如果使用秒级时间戳，同一秒内产生的多个任务分数完全相同，Redis 会将任务 ID 或内容作为字符串比较大小。例如任务 ID"task_10"可能排在"task_2"前面，导致执行顺序不符合预期。此外，非原子性的“先查后删”操作在多 Worker 场景下，会导致多个消费者拿到同一组任务，只有第一个删除成功，其余 Worker 仍会处理已过期任务，造成重复消费。

分步处理

第一步：升级时间戳精度

将分数计算逻辑从秒级改为毫秒级。Java 中使用System.currentTimeMillis()或time.Now().UnixMilli()，避免使用Unix()。毫秒级能大幅降低同一分数的概率，但不能完全消除高并发下的冲突。

第二步：确保成员唯一性

Member 字段必须包含唯一标识，如 UUID 或“业务 ID+ 随机串”。不要仅依赖业务 ID，避免重试时覆盖旧任务。若需严格顺序，可在分数中引入复合编码，如final_score = timestamp * 1000 + sequence，但需注意 Redis Score 为 double 类型，高位数值过大会丢失精度。

第三步：实现原子消费

禁止在客户端代码中分开执行 ZRANGEBYSCORE 和 ZREM。将逻辑写入 Lua 脚本，一次性返回任务列表并从集合中移除。若任务处理失败，需重新计算执行时间戳（如当前时间 + 退避时间）再次写入，不要复用原分数。

第四步：定期清理积压

后台运行定时任务，定期删除已执行或重试超限的历史数据。例如每 5 分钟执行ZREMRANGEBYSCORE key -inf (now - 86400000)，清理 24 小时前的任务，防止内存无限增长。

怎么验证是否生效

检查排序顺序：向队列写入多个同一秒产生的任务，使用ZRANGE key 0 -1 WITHSCORES查看排列顺序。若顺序符合预期（如按 ID 字典序或复合分数顺序），则精度调整生效。

验证原子性：启动多个消费者实例同时运行，观察日志中是否有相同任务 ID 被多次处理。若使用 Lua 脚本，应无重复消费；若分开执行命令，大概率会出现重复。

监控内存增长：观察 Redis 内存使用情况，确认定期清理任务是否正常运行。若内存持续上涨，检查是否有死信任务未被移除。

常见坑

浮点数精度丢失：Redis Score 是 double 类型。若尝试通过小数位拼接时间戳（如score = points + timestamp / 1e13），在大数值下会丢失精度，导致排序错误。推荐全程使用整数运算或确保数值在安全范围内。

空转浪费资源：消费者轮询时不要固定 Sleep 时间。无任务时动态增加休眠间隔（如 100ms 升至 500ms），有任务时立即恢复，减少 Redis QPS 压力。

任务价值序列化缺失：若 ZREM 只返回 Member 而不带 Value，需提前将任务数据序列化进 Member 字符串（如 JSON+ID）。否则删除后无法获取任务详情，除非额外使用 Hash 存储详情，但这会增加复杂度。

常见问题

秒级时间戳一定会乱序吗？

不一定，但风险极高。若同一秒内只有一个任务，不会乱序；但高并发下同一秒产生多个任务时，Redis 会按成员字典序排序，导致业务顺序不可控。

必须用 Lua 脚本吗？

生产环境必须用。分开执行 ZRANGEBYSCORE 和 ZREM 是非原子操作，多消费者竞争下必然出现重复消费，Lua 脚本是保证原子性的标准方案。

任务执行失败怎么处理？

不要直接复用原分数。应计算新的执行时间戳（如当前时间 + 指数退避时长），更新 Score 后重新入队，并记录重试次数，超过阈值转入死信队列。

参考来源

• 怎么利用 Redis ZSet 实现延迟任务队列_将执行时间戳作为 Score 分值
• 基于 Redis Zset 实现延迟队列
• 基于 Redis 的 ZSet 实现延迟队列
• redis 有序集合 zset 实现延迟队列_zset 有序集合 + 定时任务实现延迟队列-CSDN 博客
• 怎么解决 Redis ZSet 分值相同时的排序混乱_引入时间戳作为复合分值
• redis-延迟队列 - 分布式任务 - 优雅 - 解决方案 (zset)
• Redis Zset 排序规则详解：如何避免 Score 相同导致的排序问题
• redis 延时队列 zset 如何实现
• 如何在 Redis 中实现延迟队列？