Redis List 任务队列为什么会丢任务：从 BRPOP 改到 LMOVE 的可靠消费

线上任务偶尔出现“没执行也没重试”的情况，排查到最后发现并不是 Worker 没启动，而是 Redis List 队列用了 BRPOP：任务一旦被弹出，Redis 里就没有这条数据了。如果 Worker 在写数据库、调用外部接口或提交结果之前宕机，这条任务既不在待消费队列里，也没有进入失败记录，业务上就像凭空消失了一样。

现场：队列长度下降了，业务结果却没出现

一个导出任务队列，生产者用 LPUSH export:ready 写任务，Worker 用 BRPOP export:ready 5 阻塞等待。监控里能看到队列长度下降，Worker 日志也有“收到任务”的记录，但部分任务没有生成文件，也没有标记失败状态。

redis-cli LPUSH export:ready '{\"job_id\":\"exp_1001\",\"user_id\":42}'
redis-cli BRPOP export:ready 5

这两行命令本身没有逻辑错误。问题在于 BRPOP 的语义太直接：它返回任务内容的同时，也把任务从 List 里直接删掉了。只要 Worker 在后续业务步骤里崩溃退出，Redis 已经没有机会感知到这条任务还需要重试。

先别急着扩容，先确认任务是不是被弹走了

遇到这种现象，不要第一时间怀疑 Redis 响应慢或者 Worker 数量不够。先把几个核心证据对应上：待消费队列长度、业务结果记录、Worker 崩溃时间、任务日志里的 job_id。

redis-cli LLEN export:ready
grep 'exp_1001' worker.log
grep 'panic\\|signal\\|restart' worker.log

如果 export:ready 里已经没有对应任务，业务表也没有完成记录，而 Worker 日志在处理同一个 job_id 时刚好发生重启，那基本可以确认：任务不是堆积了，而是在消费后到执行确认前的窗口里丢了。

根因：BRPOP 少了一个可恢复的处理中状态

可靠任务系统通常需要三个状态：待处理、处理中、已完成。BRPOP 把“待处理”直接变成“从 Redis 删除”，中间没有“处理中”这个可观测状态。队列看起来消费干净了，但这并不等于任务真的完成了。

这个问题在本地调试时很难暴露，因为本地 Worker 很少在这么短的关键窗口里退出。线上环境则不一样：进程发布重启、机器 OOM、外部接口卡死、数据库连接异常，都可能发生在任务取出之后。没有处理中队列，后续的补偿扫描就没有可操作的抓手。

修复：用 LMOVE 把任务先转进处理中队列

更稳妥的链路是把待消费队列拆成两个 List：export:ready 和 export:processing。Worker 不再直接取走就删除任务，而是把任务原子移动到处理中队列。业务执行成功后，再从处理中队列里移除这条任务。

redis-cli LMOVE export:ready export:processing RIGHT LEFT

如果希望保留阻塞等待的特性，可以使用阻塞版本命令：

redis-cli BLMOVE export:ready export:processing RIGHT LEFT 5

Worker 处理成功后，再执行确认删除操作：

redis-cli LREM export:processing 1 '{\"job_id\":\"exp_1001\",\"user_id\":42}'

这套做法的关键是：任务离开 ready 后，并没有立刻消失，而是在 processing 里留下完整痕迹。进程挂了、接口超时了、机器重启了，补偿程序仍然能从处理中队列里找到它。

补偿扫描：别让 processing 变成新的垃圾堆

只加处理中队列还不够。Worker 崩溃后，任务会留在 export:processing，如果没有补偿扫描机制，它只是从“丢任务”变成“卡任务”。处理中的每条任务最好带上 job_id、创建时间、重试次数，业务表里也同步保留任务状态。

{
  "job_id": "exp_1001",
  "user_id": 42,
  "created_at": 1783533600,
  "retry": 0
}

补偿程序可以周期性检查处理中队列，把超过预设阈值仍未完成的任务重新放回 ready，或者标记为失败交给人工处理。阈值不要随便定，报表导出场景可能允许 10 分钟的超时，短信发送场景可能 30 秒就应该触发重试。

• 业务必须保证幂等：同一个 job_id 重试时，不能重复扣款、重复发券或重复写结果。
• 确认操作必须在业务成功之后执行：先 LREM 再写结果，会重新制造出丢任务的窗口。
• 任务体不要太大：List 适合承载轻量任务，文件内容和大对象应该放到外部存储，只在队列里存放对应的引用。
• 监控 processing 队列长度：它持续增长说明 Worker 成功率、确认逻辑或补偿扫描有异常。
• 保留失败出口：超过最大重试次数后，不要无限塞回队列，要落库归档或进入人工复核流程。

复查：恢复后应该看到这些变化

改成 LMOVE 方案后，可以手动杀掉 Worker 做一次验证：任务被取走后，应该出现在 export:processing；Worker 恢复或补偿程序运行后，任务要么被重新投回 ready，要么成功处理并从 processing 删除。

redis-cli LLEN export:ready
redis-cli LLEN export:processing
redis-cli LRANGE export:processing 0 5

更完整的监控要看三类指标：待消费队列长度、处理中队列长度、任务最终成功率。只看 ready 长度会误判，因为任务可能不是堆在入口，而是卡在处理中环节。

相关问题

Redis List 还能不能用来做任务队列？

可以，但要看业务的可靠性要求。轻量、允许少量丢失的通知任务可以直接用简单 List 实现；必须可恢复的任务，至少要加处理中队列、幂等校验和补偿扫描机制。

BRPOP 一定不安全吗？

不是。它适合简单阻塞消费场景，问题是它本身没有确认机制。如果任务取出后必须保证最终被处理，就不能只靠 BRPOP 实现。

LMOVE 和 Redis Stream 怎么选？

List 方案逻辑简单，适合已有旧 List 队列的小范围改造；Redis Stream 自带消费组和待确认列表，更适合多消费者、重投和观测要求更高的场景。

处理中队列里的任务重复执行怎么办？

靠业务幂等兜底。任务表可以用 job_id 做唯一约束，执行前先检查状态，成功后只允许状态从处理中流转成完成，重试逻辑只补跑没完成的任务。

Redis List 队列丢任务，很多时候不是 Redis 本身不稳定，而是消费语义太薄：BRPOP 把任务弹走，却没有留下确认和恢复的入口。把链路改成 LMOVE 转移到处理中队列、业务成功后 LREM 确认，再加上超时补偿和幂等检查，才更适合作为能上线承压的任务队列使用。