通过合理配置 `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 拾取。
用于构建、编译或部署 WebAssembly HTTP 应用到 Gcore FastEdge 边缘计算——触发关键词为“deploy to FastEdge”“build a FastEdge app”“Wasm on the edge”“Gcore edge function”、上传 .wasm 文件或使用 fastedge Rust SDK。
⚠️ 注意：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 秒）导致的长时间不可用问题，显著提升分布式任务系统的健壮性与可靠性。
