这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
多队列
为什么需要多队列？
单一 ZSet 队列的问题：
问题：任务量过大
假设每天 1000 万任务：
- 30 分钟内：450 万
- 30 分钟~7 天：350 万
- 7 天以上：200 万
所有任务都在同一个 ZSet：
- 内存占用：1000 万 × 1KB = 10GB
- 查询效率：扫描整个 ZSet 找到期任务
- 清理困难：已完成的任务需要单独清理多队列架构
按延时范围分层
┌─────────────────────────────────────────────────────────┐
│ 多队列延时架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ 热数据层（短延时队列） │
│ • 延时范围：< 30 分钟 │
│ • 精度：秒级 │
│ • 内存：少量（任务快速完成） │
│ • Redis: zset:short │
│ │
│ 温数据层（中延时队列） │
│ • 延时范围：30 分钟 ~ 7 天 │
│ • 精度：分钟级 │
│ • 内存：中等 │
│ • Redis: zset:medium │
│ │
│ 冷数据层（长延时队列） │
│ • 延时范围：> 7 天 │
│ • 精度：小时级 │
│ • 内存：少（使用数据库轮询） │
│ • Database: delay_tasks_long │
│ │
└─────────────────────────────────────────────────────────┘方案落地
多队列的优势
| 优势 | 说明 |
|---|---|
| ✅ 内存优化 | 长延时任务不占用 Redis 内存 |
| ✅ 性能优化 | 短延时任务查询更快 |
| ✅ 精度优化 | 不同层级使用不同精度 |
| ✅ 成本优化 | 减少内存使用，降低成本 |
| ✅ 可扩展 | 可以独立扩展不同层级 |