分布式延时任务方案：Redis ZSet + 时间轮 (Time Wheel)

1. 方案背景

在电商等高并发场景下，订单超时取消、预定提醒等延时任务需要满足以下核心需求：

• 高可靠性：任务不能丢失，即使服务器宕机也需能恢复。

• 高精度：触发时间偏差应在毫秒级或秒级。

• 高性能：避免大批量任务直接轮询数据库导致的 I/O 瓶颈。

• 分布式扩展：支持多实例部署，任务不重复执行。

2. 核心架构设计

本方案采用“二级调度”思想：将 Redis 作为全局持久化任务池，将本地时间轮作为高精度触发器。

2.1 数据结构设计

• 总任务池 (order:timeout:all)：

  • 类型：ZSet

  • Score：任务执行的绝对时间戳（如15:30:0015:30:0015:30:00）。

  • Value：任务唯一标识（如orderId）。

• 实例私有桶 (order:timeout:processing:{instanceId})：

  • 类型：ZSet

  • 作用：记录该实例已取走但尚未完成的任务，用于宕机恢复。

• 心跳键 (instance:heartbeat:{instanceId})：

  • 类型：String(带过期时间)

  • 作用：标识实例存活状态。

3. 详细工作流程

第一阶段：任务入库 (Producer)

1. 业务系统创建订单，计算过期时间。

2. 执行ZADD order:timeout:all <timestamp> <orderId>。

第二阶段：预取并加载 (Loader)

1. 每个服务实例启动一个定时线程（如每 1 分钟执行一次）。

2. 通过Lua 脚本原子性地从“总池”中捞取未来 60s 内到期的任务，转移至“私有桶”。

3. 将任务加载至本地内存的HashedWheelTimer（时间轮）。

第三阶段：精准触发 (Execution)

1. 本地时间轮转动到预定刻度，触发回调函数。

2. 执行业务逻辑：调用支付网关查询状态、修改订单状态、回滚库存。

3. 确认完成：业务成功后，从 Redis “私有桶”中删除该任务。

4. 关键 Lua 脚本

4.1 预取脚本 (fetch_to_private.lua)

保证多个实例竞争时，任务只会被一个实例取走并转移。

Lua

-- KEYS[1]: 总池 (all), KEYS[2]: 私有桶 (processing) -- ARGV[1]: 当前时间, ARGV[2]: 预取截止时间 (now + 60s) local orders = redis.call('ZRANGEBYSCORE', KEYS[1], ARGV[1], ARGV[2]) if #orders > 0 then for i, order_id in ipairs(orders) do redis.call('ZREM', KEYS[1], order_id) redis.call('ZADD', KEYS[2], ARGV[2], order_id) end end return orders

4.2 确认删除脚本 (complete_task.lua)

Lua

-- KEYS[1]: 私有桶 -- ARGV[1]: 订单 ID return redis.call('ZREM', KEYS[1], ARGV[1])

5. 容错与恢复机制 (Fault Tolerance)

5.1 解决“易失性”

由于任务在执行前已进入 Redis “私有桶”，即使服务器内存的时间轮因宕机丢失，任务数据依然在 Redis 中。

5.2 故障清理 (Watchdog)

启动一个独立的监控任务（或利用现有实例的定时任务）：

1. 遍历所有私有桶order:timeout:processing:*。

2. 检查对应的实例心跳instance:heartbeat:{instanceId}。

3. 恢复逻辑：如果发现心跳消失，且私有桶中有残留任务，则说明该实例已宕机。将私有桶中的任务重新ZADD回总池。

6. 方案对比总结

7. 最佳实践建议

• 实例 ID 选择：在 K8s 环境下建议使用HOSTNAME(Pod Name)，在虚拟机环境下使用IP:Port。

• 任务幂等：取消订单逻辑必须实现幂等，防止在极端恢复场景下重复触发。

• 时钟同步：分布式环境下，请确保所有实例节点的 NTP 时间同步，以防预取区间出现偏差。

希望这份文档能帮助你清晰地整理方案。如果你需要针对特定的开发框架（如 Spring Boot 或 Quarkus）提供更详细的代码脚手架，我可以继续为你提供支持。