Celery任务异常退出自动重入队列方法

通过合理配置 `acks_late=True` 和 `reject_on_worker_lost=True`，可确保 Celery 任务在 Worker 崩溃、被强制杀死（如 SIGKILL）或意外退出时，自动拒绝并重新入队，避免任务丢失，且无需依赖长时 `visibility_timeout`。

Celery 默认采用“预取确认”（acknowledgment on prefetch）机制：任务一旦被 Worker 取出，即刻向消息代理（如 RabbitMQ 或 Redis）发送 ACK，表示已接收。此时若 Worker 在执行中崩溃（例如因 OOM 被 kill、断电、SIGKILL 等无法捕获的信号），该任务将永久丢失——因为代理已认为它被成功消费。

要解决这一问题，需启用两项关键配置：

✅ acks_late=True

启用延迟确认：Worker 仅在任务执行成功后才向消息代理发送 ACK。这意味着任务在执行期间始终处于“未确认”（unacknowledged）状态，代理会持续保留其可见性。

✅ reject_on_worker_lost=True

当 Worker 进程非正常退出（如被 SIGKILL、段错误、强制 kill -9）时，Celery 会主动向代理发送 REJECT 指令（带 requeue=True），使该任务立即重新入队，供其他可用 Worker 拾取。

⚠️ 注意：reject_on_worker_lost=True 依赖于 acks_late=True 才能生效。若未启用 acks_late，任务早已被 ACK，代理不再持有其状态，reject_on_worker_lost 将无从触发。

? 配置方式（推荐全局 + 任务级双保险）

1. 全局配置（celery.py 或 config.py）：

app.conf.update(
    task_acks_late=True,
    task_reject_on_worker_lost=True,
    # 可选：防止任务被重复执行（配合幂等设计）
    worker_prefetch_multiplier=1,  # 避免单 Worker 预取过多任务
)

2. 任务级显式声明（更灵活、可读性强）：

@app.task(acks_late=True, reject_on_worker_lost=True, bind=True)
def process_payment(self, order_id: str):
    try:
        # 模拟耗时业务逻辑（如调用第三方支付网关）
        time.sleep(30)
        return {"status": "success", "order_id": order_id}
    except Exception as exc:
        # 主动重试（可选）或让框架自动处理
        raise self.retry(exc=exc, countdown=60, max_retries=3)

? 关键注意事项

• 消息代理支持要求：RabbitMQ 完全支持 requeue；Redis 作为 broker 时，需使用 redis:// URL 并确保 Celery ≥ 5.2，且底层 kombu 版本兼容（推荐使用 celery[redis]）。
• 不适用于 SIGTERM 正常关闭：若 Worker 接收 SIGTERM 并优雅退出，Celery 会尝试完成当前任务后再退出，此时不会触发 reject_on_worker_lost —— 这是预期行为，保障 graceful shutdown。
• 幂等性仍是底线：即使任务自动重入队，仍需确保任务逻辑具备幂等性（例如通过数据库唯一约束、乐观锁或外部状态检查），避免重复执行引发副作用。
• 监控建议补充：可结合 celery inspect active_queues、celery events 或 Prometheus + celery-exporter 实时观测 Worker 存活与任务积压，实现主动告警。

通过上述配置，任务可在 Worker 异常死亡后 毫秒级重新入队，彻底规避传统 visibility_timeout（如 86400 秒）导致的长时间不可用问题，显著提升分布式任务系统的健壮性与可靠性。