Celery 死信队列 Dead‑Letter Queue（DLQ）
通俗理解：正常队列放不下、处理不了的消息，丢到死信队列。存放那些确定处理失败、不能再重试的任务消息。
前提：Celery本身没有开箱即用的死信队列，需要借助broker的能力（Redis / RabbitMQ）手动配置。
什么消息会进死信
- 任务多次重试，重试次数耗尽，还是失败，不再继续重试。
- 消息过期（超过TTL）。
- 消息被拒绝，不允许重新入队。
- 队列满了，消息无法投递。
正常流程：任务 → 业务队列(work_queue) → worker取出来执行。
失败重试：抛出异常 → 重新放回原队列，反复重试。
重试耗尽：不再放回原业务队列，路由转发到死信队列 dlq。
死信队列里面的消息，不会被普通worker消费 。
需要人工观察、排查问题：参数错误、业务bug、第三方接口挂掉；修复完之后，可以把死信消息重新放回业务队列重新执行。
对比普通失败 vs 死信
- 普通失败+重试：还抱有希望，放回原队列，等下一次worker拿出来再跑。
- 死信：已经放弃自动重试，交给人工处理。
不要让消息无限重试！无限重试会疯狂打数据库、打第三方接口，雪崩。所以设置最大重试次数，耗尽就丢死信。
RabbitMQ 和 Redis 的区别
-
RabbitMQ ：原生完整支持死信交换机 DLX，配置简单。
消息满足条件，通过死信交换机路由到死信队列。
-
Redis broker（celery默认常用）
Redis本身没有原生死信队列。
Celery‑Redis 实现死信，一般两种方案：
- 方案A：任务重试耗尽之后，手动在
on_failure钩子里面，把任务手动push到另一个独立redis list，作为死信队列。 - 方案B：使用单独的死信worker，不推荐。
很多人踩坑：用Redis做broker，不配置死信；重试耗尽之后任务直接丢掉，消息直接消失，找不到。
简单代码模拟（Redis场景，手动实现死信）
python
from celery import Task
import redis
r = redis.Redis(decode_responses=True)
DEAD_LETTER_QUEUE = "dead_letter_queue"
class BaseTaskWithDLQ(Task):
autoretry_for = (Exception,)
retry_backoff = 1
retry_max = 3 # 最多重试3次，耗尽触发on_failure
def on_failure(self, exc, task_id, args, kwargs, einfo):
# 重试耗尽，进入on_failure钩子
print(f"任务{task_id}彻底失败，送入死信队列，参数 {args}")
# 手动把任务信息存入死信队列redis list
r.lpush(DEAD_LETTER_QUEUE, str({
"task_id": task_id,
"args": args,
"kwargs": kwargs,
"error": str(exc)
}))
@shared_task(base=BaseTaskWithDLQ)
def test_task(x):
1 / x逻辑：
- 抛出异常，自动重试，最多3次。
- 3次全部失败，进入
on_failure钩子。 - 在钩子里面把任务信息推到独立redis list，充当死信队列。
- 普通worker不会消费这个
dead_letter_queue。
死信队列配套运维操作
- 定时告警：监控死信队列长度，长度>0就告警，通知开发。
- 排查：查看死信里面的任务id、参数、报错。
- 修复bug之后，把死信消息重新放回业务队列重新消费。
- 清理旧的死信消息。
重要误区
- ❌死信队列不会自动重新执行任务。死信是保存失败消息，等待人工介入，不会自己恢复。
- ❌
on_failure钩子本身不等于死信队列。钩子只是通知；需要你自己把消息存储下来，才形成死信。 - ❌Redis broker不会自动把消息丢死信，必须自己实现；RabbitMQ可以通过DLX自动路由。
- 如果任务内部捕获异常吞掉异常，不抛出去：不会重试，也不会进死信。
和之前知识点串联
on_failure钩子：事件回调，只是收到任务彻底失败的通知，没有保存消息的能力；我们利用这个钩子把消息存入死信存储。- 钩子是通知；死信队列是存储失败消息的容器。
- 中间件可以在任务执行前拦截；死信是任务已经彻底失败之后的归宿。
通俗比喻
快递派送：
正常任务 = 快递派送。
重试 = 派送失败，第二天再派送一次。
重试多次全部失败 → 快递无法送达，放到无人认领包裹仓库（死信队列） 。
不会反复派送；需要人去仓库查看包裹，确认地址修好之后，再重新派送。
什么时候需要死信队列？
业务场景：任务不能丢，失败之后希望保留现场，不能直接消失。
比如订单回调、数据同步任务；如果不做死信，重试耗尽任务直接丢失，业务数据就缺了。
简单总结：
死信队列就是专门存放重试已经全部失败，不再自动处理的消息的队列；目的是保存现场，告警，留给人工排查和恢复。RabbitMQ原生支持；Redis做broker需要借助on_failure钩子手动实现。