Redis ZSet 方案

当数据库轮询开始拖慢主库或调度延迟不可控时，Redis ZSet 是常见的下一步。ZSet 天然适合延时任务：成员是任务 ID，score 是执行时间戳，调度器只需要取出 score 小于当前时间的成员，就能找到到期任务。

本章会把 ZSet 方案拆成存储、扫描、抢占和确认四个环节。任务详情可以放在数据库或 Redis Hash 中，ZSet 只负责按时间排序；调度器通过 ZRANGEBYSCORE 找到到期任务，再用 Lua 脚本原子地移除或迁移到执行中集合，避免多个节点拿到同一个任务。执行成功后写回最终状态，失败则根据重试策略重新放入 ZSet。

ZSet 方案的优势是到期扫描快、实现相对简单、适合秒级调度和较高吞吐。但它也带来新的问题：Redis 内存成本高，任务持久化和恢复依赖 AOF/RDB 或外部数据库，超大队列需要分片，多业务混用时需要队列隔离和限流。如果只把所有任务塞进一个 ZSet，热门业务很容易影响低频但重要的任务。

本章还会讨论 score 设计。score 可以直接使用毫秒时间戳，也可以把时间桶、优先级或分片信息组合进任务 key。无论怎样设计，都要保证扫描范围稳定、任务可删除、可重试、可追踪，并且不会因为时钟偏差导致大量任务提前或延后执行。

完成本章后，你会得到一个比数据库轮询更高性能的延时队列方案，同时也会知道 Redis ZSet 并不是最终答案：它适合大量中短期延时任务，但必须配合持久化、分片、监控和降级策略才能进入生产。