层级时间轮

问题分析

层级数量的确定需要考虑：

1. 最大延时需求：业务最长的延时任务（如30天）
2. 时间精度要求：最短的任务间隔（如1秒）
3. 内存限制：每层都会占用内存
4. 性能平衡：层级过多会增加降级开销

技术要点

1. 层级计算公式

最大延时 = tick_duration × wheel_size ^ (layer_count - 1)

倒推层级数量：
layer_count = ⌈log(wheel_size, max_delay / tick_duration)⌉ + 1

2. 标准配置方案

3. 设计原则

架构图解

层级设计决策树：

┌─────────────────────────────────────────┐
│  业务需求分析                            │
│  - 最大延时：30天                        │
│  - 最小精度：1秒                         │
│  - 任务分布：70%短延时，30%长延时         │
└─────────────────┬───────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────────┐
│  确定第一层                              │
│  tick_duration = 1秒（满足精度要求）      │
│  wheel_size = 60（常见值）               │
│  最大延时：60秒                          │
└─────────────────┬───────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────────┐
│  计算层级数量                            │
│  第2层：1分钟 × 60 = 1小时               │
│  第3层：1小时 × 24 = 1天                 │
│  第4层：1天 × 30 = 30天                  │
│  ✅ 满足需求，共4层                      │
└─────────────────┬───────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────────┐
│  验证配置                                │
│  ✓ 最大延时：30天（≥7天需求）            │
│  ✓ 精度：±1秒                            │
│  ✓ 层级数：4层（适中）                   │
│  ✓ 内存占用：约10MB（100万任务）          │
└─────────────────────────────────────────┘

性能对比

最佳实践

1. 动态计算层级数量

2. 根据业务特性调整

3. 监控与调优

总结：

• ✅ 通用场景：4层（秒-分-小时-天）
• ✅ 短延时场景：3层即可
• ✅ 超长延时：5-6层，但要权衡性能
• ❌ 避免：超过6层（降级开销大）

问题分析

任务降级过程中，精度是否丢失取决于：

1. 计算方式：是否基于当前时间重新计算
2. 时间单位：不同层的tick粒度不同
3. 累积误差：多次降级是否会叠加误差

技术要点

1. 降级过程不会丢失精度

关键：每次降级都重新计算 remaining_delay = execute_at - current_time，因此不会累积误差。

2. 精度对比

结论：精度逐步提高，最终达到第一层的tick精度。

3. 误差来源分析

架构图解

任务降级精度示意图：

7天任务：execute_at = T + 604800秒

T0: 添加任务
┌──────────────────────────────────────────┐
│ 天轮（L4）                                │
│ 剩余时间：604800秒                        │
│ 槽位：7，rounds：0                        │
│ 精度：±0.5天（12小时）                    │
└──────────────────────────────────────────┘
           │ 1天后
           ▼
T1: 第一次降级
┌──────────────────────────────────────────┐
│ 小时轮（L3）                              │
│ 剩余时间：518400秒（6天）                  │
│ 精确计算：execute_at - current_time       │
│ 槽位：0，rounds：6                        │
│ 精度：±0.5小时（30分钟）                  │
└──────────────────────────────────────────┘
           │ 6天后
           ▼
T2: 第二次降级
┌──────────────────────────────────────────┐
│ 分钟轮（L2）                              │
│ 剩余时间：3600秒（1小时）                 │
│ 精确计算：execute_at - current_time       │
│ 槽位：0，rounds：60                       │
│ 精度：±0.5分钟（30秒）                    │
└──────────────────────────────────────────┘
           │ 1小时后
           ▼
T3: 第三次降级
┌──────────────────────────────────────────┐
│ 秒轮（L1）                                │
│ 剩余时间：60秒                            │
│ 精确计算：execute_at - current_time       │
│ 槽位：60，rounds：0                       │
│ 精度：±0.5秒                              │
└──────────────────────────────────────────┘
           │ 60秒后
           ▼
T4: 执行任务
实际执行时间：T + 604800秒 ± 0.5秒
相对误差：0.5 / 604800 ≈ 0.00008%

性能对比

测试验证：

最佳实践

1. 使用高精度时间戳

2. 避免累积误差

3. 处理边界情况

4. 监控精度指标

总结：

• ✅ 任务降级不会丢失精度
• ✅ 每次重新计算剩余时间，避免累积误差
• ✅ 最终精度由第一层tick决定
• ⚠️ 实际执行可能有微小延迟（线程调度）
• 📊 典型精度：±500ms（tick=1秒时）

问题分析

进程重启面临的挑战：

1. 任务丢失：内存中的任务全部丢失
2. 状态恢复：需要恢复时间轮的运行状态
3. 数据一致性：避免重复执行或漏执行
4. 性能影响：持久化不能严重影响性能

技术要点

1. 持久化方案对比

2. 推荐方案：任务持久化 + 定期检查

3. 完整持久化架构

┌─────────────────────────────────────────────────────────┐
│                    应用层                                │
│  ┌──────────────────────────────────────────────────┐  │
│  │        LayeredTimingWheel (内存)                 │  │
│  │  - 秒轮  - 分轮  - 时轮  - 天轮                   │  │
│  └────────────┬─────────────────────────────────────┘  │
│               │                                         │
│               │ 添加任务时                              │
│               ▼                                         │
│  ┌──────────────────────────────────────────────────┐  │
│  │           持久化层                                │  │
│  │  ┌────────────┐  ┌────────────┐                 │  │
│  │  │ Redis ZSet │  │   PostgreSQL│                 │  │
│  │  │ - 实时写入  │  │ - 定期归档  │                 │  │
│  │  │ - 快速查询  │  │ - 历史记录  │                 │  │
│  │  └────────────┘  └────────────┘                 │  │
│  └──────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘
                    │ 进程重启
                    ▼
┌─────────────────────────────────────────────────────────┐
│                    恢复流程                              │
│                                                         │
│  1. 从Redis加载未执行的任务                              │
│     └──> execute_at > current_time                     │
│                                                         │
│  2. 重新构建时间轮状态                                   │
│     └──> 根据剩余延时分配到各层                          │
│                                                         │
│  3. 启动工作线程                                         │
│     └──> 继续处理任务                                   │
│                                                         │
│  4. 数据一致性检查                                       │
│     └──> 去重、补漏、修复                               │
└─────────────────────────────────────────────────────────┘

架构图解

持久化时机：

任务生命周期：

创建任务
    │
    ├─> 内存：添加到时间轮
    ├─> Redis：写入ZSet（score=execute_at）
    └─> DB：写入任务表（异步）
    │
    │
执行前
    │
    ├─> 内存：从时间轮取出
    ├─> Redis：删除（防止重复执行）
    └─> DB：更新状态为"已执行"
    │
    │
进程重启
    │
    ├─> 内存：清空
    ├─> Redis：保持不变
    └─> DB：保持不变
    │
    │
恢复流程
    │
    ├─> 从Redis读取 execute_at > now 的任务
    ├─> 重新添加到时间轮
    └─> 继续运行

最佳实践

1. Redis + PostgreSQL 双写策略

2. 数据一致性保证

3. 优雅重启流程

4. 监控告警

5. 性能优化

性能对比

总结：

• ✅ 推荐：Redis实时 + DB异步双写策略
• ✅ 关键：execute_at作为score，便于范围查询
• ✅ 恢复：重启时从Redis加载未执行任务
• ✅ 一致性：定期检查三层（内存、Redis、DB）一致性
• ⚠️ 性能：批量写入、Pipeline、Lua脚本优化