通过配置 `acks_late=true` 和 `reject_on_worker_lost=true`，可确保任务在 worker 崩溃或被强制终止（如 sigkill）时自动重回队列重试，无需依赖长时 visibility_timeout，实现秒级故障恢复。
在分布式异步任务系统中，Celery worker 因 OOM、进程被 kill（如 kill -9）、主机宕机等原因意外退出，是常见但高风险的场景。默认情况下，Celery 采用“预取确认”（prefetch + early ack）机制：任务一旦被 worker 取出即标记为已确认（ack），即使后续执行中断，该任务也不会重入队列——这将导致任务静默丢失。
要解决这一问题，关键在于改变任务确认（acknowledgement）时机与失败处理策略，核心配置如下：
✅ 必选配置项
| 配置项 | 作用 | 推荐值 |
|---|---|---|
| task_acks_late = True | 延迟确认：仅当任务成功执行完毕后才发送 ACK；若 worker 在执行中崩溃，Broker（如 RabbitMQ/Redis）会因未收到 ACK 而在 visibility_timeout 后自动重发任务 | True |
| task_reject_on_worker_lost = True | 增强型保障：当 worker 进程异常终止（包括 SIGKILL、段错误、强制 kill 等无法触发优雅 shutdown 的场景）时，Celery 主动向 Broker 发送 REJECT 指令（带 requeue=True），立即将任务放回队列首部，无需等待 visibility_timeout | True |
⚠️ 注意：reject_on_worker_lost=True 依赖于 Celery 5.0+（推荐使用 5.2+ 或 5.3+ 稳定版），且需 Broker 支持消息重入（RabbitMQ 完全支持；Redis 作为 Broker 时需使用 redis-py>=4.2.0 并启用 retry_on_timeout=True 等兼容配置）。
? 配置方式（两种粒度）
1. 全局配置（推荐用于统一策略）
# celeryconfig.py broker_url = "redis://localhost:6379/0" result_backend = "redis://localhost:6379/1" # 关键容错配置 task_acks_late = True task_reject_on_worker_lost = True # 可选：降低 visibility_timeout（配合 reject_on_worker_lost 后非必需，但仍建议设为合理值） worker_prefetch_multiplier = 1 # 避免单 worker 预取过多任务 visibility_timeout = 3600 # 1小时（即使未触发 reject，兜底超时重发）
2. 任务级配置（灵活控制关键任务）
from celery import Celery
app = Celery("tasks", broker="redis://localhost:6379/0")
@app.task(
acks_late=True,
reject_on_worker_lost=True,
bind=True, # 启用 self 参数，便于日志/重试控制
max_retries=3,
default_retry_delay=60
)
def process_payment(order_id):
try:
# 模拟耗时业务逻辑（如调用第三方支付接口）
import time; time.sleep(30)
return {"status": "success", "order_id": order_id}
except Exception as exc:
# 可选择性重试
raise self.retry(exc=exc)? 重要注意事项
reject_on_worker_lost=True 不替代监控：它解决的是“worker 突然死亡”的原子性保障，但无法替代 Prometheus + Grafana 对 worker CPU/内存/队列积压的实时监控与告警。
避免盲目开启所有任务：对幂等性差、副作用强（如已发短信、已扣款）的任务，应结合业务逻辑做显式幂等校验，而非仅依赖重入。
-
Broker 选型影响行为：
- RabbitMQ：原生支持 requeue，表现最稳定；
- Redis：需确保 redis-py>=4.2.0 且 Celery 配置 broker_transport_options = {"visibility_timeout": 3600}，否则可能丢消息。
-
测试验证方法：
# 启动 worker（记录 PID） celery -A tasks worker --loglevel=info # 在另一终端中强制杀死 worker（模拟 SIGKILL） kill -9 <worker_pid> # 立即查看队列：任务应已在几秒内重新出现在 ready 状态（可通过 rabbitmqctl list_queues 或 redis-cli llen 查看）
通过以上配置，Celery 可在 worker 非正常退出的瞬间完成任务“回滚”，显著提升任务系统的鲁棒性与最终一致性，真正实现毫秒到秒级的故障自愈能力。
