一、延时队列是什么？核心概念与应用场景
普通队列的核心机制是：消息一旦抵达，立即被消费者处理，中间没有任何等待。
而延时队列的思路则是：消息到达后并不急于消费，而是先暂存起来，等到预设的时间点再触发处理。这就像一个可定时的闹钟，到点才响。
普通队列： [消息] → 立即消费
延时队列： [消息] → 等待30分钟 → 到期 → 消费
现实业务中，延时队列的应用比比皆是：
- 用户下单后30分钟未支付，系统自动取消订单。
- 发出的红包24小时未被领取，自动原路退回。
- 会议开始前5分钟，向与会者推送提醒通知。
- 订单签收7天后，系统自动确认收货。
这些场景的共同需求在于：让某个任务在未来的特定时刻被精确触发。
二、为什么首选 ZSet 实现延时队列
Redis 提供了多种数据结构，哪一个能担当延时队列的重任？我们来逐一分析：
| 数据类型 | 存储结构 | 能否实现延时队列 |
|---|---|---|
| List | 按插入顺序排列 | ❌ 无法按时间查找到期任务 |
| Set | 无序集合 | ❌ 无法指定执行时间 |
| ZSet | 按 score 值排序 | ✅ 用 score 存储到期时间戳 |
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 轮询 | score=时间戳，定时轮询 | 实现简单，Redis 原生支持 | 需要轮询，精度为秒级 |
| Redis 过期回调 | key 过期触发通知 | 无需轮询 | 通知不可靠，可能丢失 |
| RabbitMQ 延时插件 | 消息 TTL + 死信队列 | 专业可靠，功能完善 | 需额外安装插件，配置复杂 |
| 数据库轮询 | 定时扫描数据表 | 实现最直接 | 大数据量时性能低下 |
总体来看，ZSet 方案在“功能够用且实现简单”这个维度上优势最为突出。
八、ZSet 的 score 由谁赋值？
这个问题看似基础，却常被混淆。score 由 开发者（即生产者） 在写入时显式指定。
ZADD key score member
↑
你指定的
ZADD delay_queue 1718000000 "task_001"
# ↑ 时间戳就是 score，由你计算
# score 决定了 ZSet 中的排序位置
排序规则： score 值越小，元素越靠前。因此到期时间越早的任务，在 ZSet 中排在越前面，也会越先被消费。
九、Set vs ZSet：到底谁能胜任延时队列？
再确认一次，毕竟这两个数据结构名称非常相似：
| 对比维度 | Set | ZSet |
|---|---|---|
| 是否有序 | ❌ 无序 | ✅ 按 score 排序 |
| 能否查询到期任务 | ❌ 不能 | ✅ 通过 ZRANGEBYSCORE 0 now |
| 能否实现延时队列 | 不行 | 可以 |
延时队列最核心的需求就是“按时间排序并查询到期任务”，只有带 score 属性的 ZSet 能够完美满足。
十、面试高频问题（附赠实用知识点）
Q: 为什么不能用 List 实现延时队列？
因为 List 仅支持头出尾出，无法判断内部消息是否“到期”。它本质上是一个纯粹的 FIFO 队列，不具备按时间筛选的能力。
Q: 轮询会不会造成性能瓶颈？
单次 ZRANGEBYSCORE + ZREM 的时间复杂度为 O(log N)，每秒轮询一次对 Redis 的压力极小。即使存储 10 万条延时任务，系统也能轻松应对。
Q: 面对超大规模数据怎么办？
当数据量进一步膨胀时，可以采取以下优化策略：
- 使用多个 ZSet key 进行分桶（例如按分钟、小时划分）
- 每个分桶分配独立的消费者线程
- 结合 Redis Cluster 分片，提升整体吞吐能力
Q: 消息丢失如何避免？
Redis 基于内存，宕机可能导致数据丢失。对于关键业务，建议做到双重保障：
- 开启 AOF 持久化，降低丢失风险
- 业务层面做双写：Redis 丢数据后，依赖定时脚本从数据库扫描表进行兜底补偿
Q: score 可以存储毫秒级时间戳吗？
完全可以。ZSet 的 score 为 double 浮点数，虽然毫秒精度存在微小损失，但几十位的毫秒时间戳完全能够存放。
核心总结：ZSet 的 score 排序能力 + Lua 原子抢占任务 = 轻量可靠的延时队列方案。
