celery任务重试必须显式传countdown参数，否则默认countdown=0导致瞬时重试；指数退避需手动计算countdown值（如2**self.request.retries），并用raise self.retry(countdown=countdown, exc=exc)触发，不可仅调用self.retry()。
Celery任务重试必须显式传countdown
Celery的retry()方法默认不退避，它直接以countdown=0重新入队，相当于立刻重试——这在多数网络或服务抖动场景下会加重失败。真正的指数退避要靠手动计算countdown值，并传给retry()。常见错误是只调self.retry()却不传参数，结果任务反复瞬时重试，甚至触发限流或压垮下游。
正确做法是结合self.request.retries动态算等待时间：
-
countdown = 2 ** self.request.retries是最简指数基线（第1次失败后等1s，第2次等2s，第3次等4s） - 加随机抖动防雪崩：
countdown = (2 ** self.request.retries) + random.uniform(0, 1) - 设上限避免无限增长：
countdown = min(2 ** self.request.retries, 60)（最长等60秒） - 必须用
raise self.retry(countdown=countdown, exc=exc)，不能只写self.retry(...)——否则原异常被吞，日志里看不到根因
异步协程任务别用Celery retry，改用tenacity
如果你的任务函数是async def（比如用aiohttp发请求），Celery原生不支持awaitable重试逻辑。self.retry()会报TypeError: object can't be used in 'await' expression，因为它是同步调度机制。
这时该把重试逻辑下沉到函数内部，用tenacity装饰处理函数本身：
- 安装：
pip install tenacity - 装饰器写法：
@retry(wait=wait_exponential(multiplier=1, min=1, max=60), stop=stop_after_attempt(3)) -
min和max是jitter后的最终等待上下限，不是指数计算前的原始值 - 务必用
retry_if_exception_type((ConnectionError, asyncio.TimeoutError))限定重试异常，避免把ValueError也重试
Django中重试逻辑别混进视图或模型，隔离到任务函数里
有人把retry逻辑写在Django视图里，比如HTTP请求失败后手动循环+time.sleep()，这会阻塞整个WSGI线程，严重拖慢响应。Celery任务本意就是把耗时/不稳定操作移出请求生命周期。
正确边界是：
- 视图只负责触发
task.delay()，不碰重试 - 模型方法也不该含重试——它可能被同步调用，导致事务卡住
- 所有重试、退避、异常过滤都封装在
@shared_task函数内部，且明确区分“可重试异常”（如requests.exceptions.ConnectionError）和“不可重试异常”（如ValueError） - 如果任务涉及数据库写入，重试前确认是否幂等；否则得加唯一键或状态字段防重复
别依赖queue.Queue做重试，它根本不支持退避
有同学想用Python标准库queue.Queue自己实现任务重试队列，这是误区。get_nowait()要么立刻返回，要么抛queue.Empty，它没有“等X秒再取”的能力。退避必须作用于“任务处理失败后”，而不是“取任务环节”。
典型反模式：
- 在
while True:循环里反复queue.get_nowait()→ 失败就time.sleep(1)→ 这实际是轮询空队列，CPU白耗 - 把失败任务
put()回原队列 → 可能无限循环，尤其没设重试次数上限时
真要自定义队列重试，应该用带TTL的延迟队列（如Redis ZSET），或者直接用Celery的retry(countdown=...)——它底层就是投递到Broker延时队列。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
