Redis延时队列原理与实现详解

一、延时队列是什么？核心概念与应用场景

普通队列的核心机制是：消息一旦抵达，立即被消费者处理，中间没有任何等待。

而延时队列的思路则是：消息到达后并不急于消费，而是先暂存起来，等到预设的时间点再触发处理。这就像一个可定时的闹钟，到点才响。

普通队列： [消息] → 立即消费

延时队列： [消息] → 等待30分钟 → 到期 → 消费

现实业务中，延时队列的应用比比皆是：

• 用户下单后30分钟未支付，系统自动取消订单。
• 发出的红包24小时未被领取，自动原路退回。
• 会议开始前5分钟，向与会者推送提醒通知。
• 订单签收7天后，系统自动确认收货。

这些场景的共同需求在于：让某个任务在未来的特定时刻被精确触发。

二、为什么首选 ZSet 实现延时队列

Redis 提供了多种数据结构，哪一个能担当延时队列的重任？我们来逐一分析：

List 虽然有序，但顺序完全由插入次序决定，无法直接找出“哪些消息现在该执行”。Set 更不用说，整个就是无序的集合，无法按时间筛选。只有 ZSet，凭借其 score 排序 的独特能力，成为最佳选择。我们只需把任务的到期时间戳设为 score 存入，ZSet 就会自动按到期时间从小到大排列，查询到期任务变得轻而易举。

# 用法简洁直观
ZADD delay_queue 1718000000 "task_001"   # score 设为到期时间戳
ZADD delay_queue 1718000300 "task_002"   # ZSet 自动按时间排序

三、核心流程原理图解

明确整体思路后，流程便非常清晰：

生产者                     Redis ZSet                      消费者(定时任务)
──────                    ──────────                      ──────────────
XADD delay_q              score = 到期时间戳
score=到期时间            member = 任务数据
                          ┌─────────────────┐
                          │ 1718000000 task1 │  ← 最早到期
                          │ 1718000300 task2 │
                          │ 1718000600 task3 │
                          └─────────────────┘
                                  ↓
                          ZRANGEBYSCORE 0 当前时间
                          取到 task1（已到期）
                                  ↓
                          执行 task1 → ZREM 删除

生产者只需把任务写入 ZSet，消费者则像一位忠诚的哨兵，不断检查是否存在 score 小于等于当前时间的任务。一旦发现，立即取出执行并从集合中移除。

四、基础实现与潜在隐患

按照上述思路，可以快速写出第一版代码：

// 生产者：投递延时任务到 ZSet
$redis->zAdd('delay:orders', time() + 1800, json_encode([
    'order_id' => 12345,
    'action'   => 'auto_cancel',
]));

// 消费者：每秒轮询到期任务（存在 BUG 的版本）
$now = time();
$tasks = $redis->zRangeByScore('delay:orders', 0, $now, ['limit' => [0, 1]]);
if ($tasks) {
    $task = $tasks[0];
    // ⚠️ 这里有隐患！若多个消费者同时读取，会拿到同一条任务
    $redis->zRem('delay:orders', $task);
    processTask($task);
}

代码看似顺畅，但问题很大！ZRANGEBYSCORE 与 ZREM 是两条独立的命令，不具备原子性。一旦部署多个消费者实例（生产环境常见），多个进程可能几乎同时读到同一条任务，随后各自删除、各自执行。订单被重复取消？这就会引发严重的数据一致性问题。

五、Lua 脚本：原子化解决并发冲突

Redis 的 Lua 脚本是解决此类并发问题的标准方案。它能把“查询到期任务 + 删除任务 + 返回结果”三个步骤捆绑成一次原子操作，要么全部成功，要么全部失败，不留中间状态。

-- 原子操作：查询到期任务 + 立即删除 + 返回
local tasks = redis.call('ZRANGEBYSCORE', KEYS[1], 0, ARGV[1], 'LIMIT', 0, 1)
if #tasks == 0 then
    return nil
end
local task = tasks[1]
local removed = redis.call('ZREM', KEYS[1], task)
if removed == 1 then
    return task       -- 删除成功，返回任务
else
    return nil        -- 已被其他消费者抢走
end

PHP 端调用相应调整为：

$lua = <<<'LUA'
local tasks = redis.call('ZRANGEBYSCORE', KEYS[1], 0, ARGV[1], 'LIMIT', 0, 1)
if #tasks == 0 then return nil end
local task = tasks[1]
if redis.call('ZREM', KEYS[1], task) == 1 then
    return task
else
    return nil
end
LUA;

// 定时任务循环执行
while (true) {
    $task = $redis->eval($lua, ['delay:orders', time()], 1);
    //                                      ↑ KEYS 部分       ↑ key数量
    if ($task) {
        $data = json_decode($task, true);
        echo "处理任务: {$data['order_id']}n";
        processTask($data);
    } else {
        sleep(1);  // 无到期任务，等待一秒
    }
}

六、完整实战：30分钟未支付自动取消订单

理论讲解再多，不如动手写一个完整的示例。下面是“下单30分钟未支付自动取消”的完整实现：

connect('127.0.0.1', 6380);

    // 1. 创建订单...
    // 2. 投递延时任务：30分钟后自动取消
    $delayAt = time() + 1800;  // 30分钟
    $task = json_encode([
        'order_id' => $orderId,
        'action'   => 'auto_cancel',
        'create_at'=> date('Y-m-d H:i:s'),
    ]);
    $redis->zAdd('delay:orders', $delayAt, $task);
    echo "订单 {$orderId} 已创建，30分钟后未支付将自动取消n";
}

// ====== 消费者（定时脚本） ======
$lua = <<<'LUA'
local tasks = redis.call('ZRANGEBYSCORE', KEYS[1], 0, ARGV[1], 'LIMIT', 0, 1)
if #tasks == 0 then return nil end
if redis.call('ZREM', KEYS[1], tasks[1]) == 1 then
    return tasks[1]
end
return nil
LUA;

while (true) {
    $task = $redis->eval($lua, ['delay:orders', time()], 1);
    if ($task) {
        $data = json_decode($task, true);
        // 二次确认订单实际状态
        $order = getOrder($data['order_id']);
        if ($order['status'] === 'unpaid') {
            cancelOrder($data['order_id']);
            echo "⏰ 订单 {$data['order_id']} 超时未支付，已自动取消n";
        } else {
            echo "✓ 订单 {$data['order_id']} 已支付，跳过n";
        }
    } else {
        sleep(1);
    }
}

这里有个细节需要留意：即使任务到期被取出，消费端依然要二次核实订单的真实状态。万一用户在超时前的最后一秒完成了支付呢？这种“双保险”设计是业务正确性的必要保障，逻辑上必须考虑周全。

七、ZSet 延时队列 vs 其他方案对比

Redis ZSet 方案并非唯一选择，但它是最简单、最轻量的实现方式。我们将其与几种常见方案进行对比：

总体来看，ZSet 方案在“功能够用且实现简单”这个维度上优势最为突出。

八、ZSet 的 score 由谁赋值？

这个问题看似基础，却常被混淆。score 由 开发者（即生产者） 在写入时显式指定。

ZADD key score member          
          ↑     
你指定的
ZADD delay_queue 1718000000 "task_001"
#                 ↑    时间戳就是 score，由你计算
#                 score 决定了 ZSet 中的排序位置

排序规则： score 值越小，元素越靠前。因此到期时间越早的任务，在 ZSet 中排在越前面，也会越先被消费。

九、Set vs ZSet：到底谁能胜任延时队列？

再确认一次，毕竟这两个数据结构名称非常相似：

延时队列最核心的需求就是“按时间排序并查询到期任务”，只有带 score 属性的 ZSet 能够完美满足。

十、面试高频问题（附赠实用知识点）

Q: 为什么不能用 List 实现延时队列？

因为 List 仅支持头出尾出，无法判断内部消息是否“到期”。它本质上是一个纯粹的 FIFO 队列，不具备按时间筛选的能力。

Q: 轮询会不会造成性能瓶颈？

单次 ZRANGEBYSCORE + ZREM 的时间复杂度为 O(log N)，每秒轮询一次对 Redis 的压力极小。即使存储 10 万条延时任务，系统也能轻松应对。

Q: 面对超大规模数据怎么办？

当数据量进一步膨胀时，可以采取以下优化策略：

1. 使用多个 ZSet key 进行分桶（例如按分钟、小时划分）
2. 每个分桶分配独立的消费者线程
3. 结合 Redis Cluster 分片，提升整体吞吐能力

Q: 消息丢失如何避免？

Redis 基于内存，宕机可能导致数据丢失。对于关键业务，建议做到双重保障：

• 开启 AOF 持久化，降低丢失风险
• 业务层面做双写：Redis 丢数据后，依赖定时脚本从数据库扫描表进行兜底补偿

Q: score 可以存储毫秒级时间戳吗？

完全可以。ZSet 的 score 为 double 浮点数，虽然毫秒精度存在微小损失，但几十位的毫秒时间戳完全能够存放。

核心总结：ZSet 的 score 排序能力 + Lua 原子抢占任务 = 轻量可靠的延时队列方案。