3. 延迟队列核心原理：基于 ZSET 的延迟队列模型

延迟队列的核心在于将任务的执行时间与当前系统时间解耦，让任务在“未来某个时刻”才被消费者取出并处理。Redis 的 ZSET（有序集合） 天然支持按分数排序，这一特性使其成为实现延迟队列的理想底层结构。

3.1 基于 ZSET 的延迟队列模型

ZSET 延迟队列的基本模型包含三个核心角色：生产者、ZSET 存储层、消费者。生产者将任务写入 ZSET，消费者通过轮询或定时任务扫描 ZSET 中分数（时间戳）小于等于当前时间的元素，取出并执行。

3.2 时间轮与 ZSET 对比

时间轮（Timing Wheel）是另一种经典的延迟任务调度算法，常见于 Netty、Kafka 等高性能中间件。下表从多个维度对比两种方案：

3.3 Score 作为时间戳的设计思路

ZSET 的 score 是一个 64 位浮点数，可以精确表示毫秒级时间戳。设计时通常采用以下方案：

• 时间戳单位：统一使用毫秒级时间戳（13 位数字），避免秒级精度导致任务提前或延迟执行。
• score 计算公式：score = 当前系统时间戳(ms) + 延迟时间(ms)。例如：当前时间 1700000000000ms，延迟 5 分钟，则 score = 1700000300000。
• 消费者轮询策略：使用 ZRANGEBYSCORE queue 0 current_timestamp_ms 获取所有已到期任务，配合 ZREM 原子移除。
• 避免分数冲突：如果同一毫秒内写入多个任务，ZSET 会按 member（任务 ID）排序。建议在 member 中拼接随机数或序列号，确保唯一性。

// 生产者：写入延迟任务
long delayMs = 5 * 60 * 1000; // 5分钟
long executeAt = System.currentTimeMillis() + delayMs;
String taskId = UUID.randomUUID().toString();
jedis.zadd("delay_queue", executeAt, taskId);

// 消费者：轮询到期任务
Set<String> readyTasks = jedis.zrangeByScore("delay_queue", 0, System.currentTimeMillis());
for (String taskId : readyTasks) {
    // 尝试移除任务，防止并发消费
    long removed = jedis.zrem("delay_queue", taskId);
    if (removed == 1) {
        // 成功获取任务，执行处理逻辑
        processTask(taskId);
    }
}

3.4 延迟队列的可靠性保障

基于 ZSET 的延迟队列虽然简单，但在生产环境中需要额外关注以下可靠性问题：

• 任务丢失：消费者在 ZREM 之后、业务处理完成之前崩溃，任务会丢失。解决方案：引入“处理中”队列或任务状态表。
• 重复消费：多个消费者同时轮询到同一任务。解决方案：使用 Lua 脚本原子操作，或利用 Redis 分布式锁。
• 队列积压：消费者处理速度跟不上任务到期速度。解决方案：增加消费者实例，或使用 Redis 集群分片。
• 时间精度：ZSET 的 score 是浮点数，高并发下可能出现精度误差。解决方案：使用毫秒级时间戳，避免微秒级精度。