任务队列
Redis 任务队列
使用 Redis List 和 Stream 构建可靠的任务队列和作业处理系统。处理后台作业、延迟任务和工作分发。
真实业务场景
某图像处理服务每小时接收 10,000 个上传请求。处理每张图片（调整大小、压缩、水印）需要 2-5 秒。同步处理会导致 HTTP 请求超时。Redis 支持的任务队列将上传与处理解耦：API 立即将作业排队，Worker 进程按自己的节奏消费它们。失败的作业可以重试而不会丢失数据。
架构图
API 服务器 (生产者)
↓ LPUSH 作业到队列
┌──────────────────────────────────────┐
│ Redis │
│ ┌──────────────────────────────────┐ │
│ │ LIST: queue:images │ │
│ │ [job3] [job2] [job1] │ │
│ ├──────────────────────────────────┤ │
│ │ LIST: queue:images:processing │ │
│ │ (正在处理的作业) │ │
│ ├──────────────────────────────────┤ │
│ │ LIST: queue:images:failed │ │
│ │ (死信队列) │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────┘
↓ BRPOPLPUSH (原子出队)
Worker 1 | Worker 2 | Worker 3
关键命令解析
性能分析
LPUSH/BRPOP: O(1) 操作。Redis 单实例每秒可入队/出队 10万+ 作业。
BRPOP 高效阻塞——不浪费 CPU 进行轮询。连接在作业到达前保持空闲。
内存: 1K 作业负载 × 10万 排队作业 = ~100MB。Redis 轻松处理数百万排队作业。
BRPOPLPUSH 提供至少一次交付保证。结合幂等 Worker，确保可靠处理。
常见陷阱
使用 RPOP 代替 BRPOP: 紧密循环中的 RPOP 浪费 CPU 和网络资源。BRPOP 高效阻塞并降低 Redis 负载。
无处理列表: 如果 Worker 在 RPOP 后崩溃，作业将永远丢失。务必使用 BRPOPLPUSH 在处理列表中保留备份。
无限制的队列增长: 如果生产者速度超过消费者，队列会增长直到 Redis 内存耗尽。监控 LLEN 并设置警报。
无死信队列: 默默丢弃失败的作业使调试变得不可能。始终将失败移动到单独的列表进行检查。
最佳实践
使用 BRPOPLPUSH 进行具有崩溃恢复能力的可靠队列处理。
对失败的作业实施指数退避重试。
监控队列深度 (LLEN) 并设置自动缩放触发器。
添加作业元数据：时间戳、重试计数、优先级。
为不同优先级使用单独的队列 (queue:high, queue:low)。
在复杂场景中考虑使用 Redis Streams (XADD/XREADGROUP) 实现消费者组和消息确认。
可运行演示
Redis Demo
Click "Step" or "Run All" to execute commands...
▌