Celery worker吞吐量卡在10–20 QPS主因是prefetch过大导致任务“锁死”在慢worker中，需配合task_acks_late=True并按任务类型设worker_prefetch_multiplier=1等分层阈值。
直接改 worker_prefetch_multiplier 和 task_acks_late 就能明显提速，但多数人调完反而更慢——问题出在没理解 prefetch 是“预取条数 × 每个任务的平均处理时间”，而不是单纯调大就快。
为什么 Celery worker 吞吐量卡在 10–20 QPS 上不去
常见现象是：加了 8 个 worker 进程，CPU 却只跑 15%，Redis 监控显示队列积压持续上涨，celery -A tasks inspect stats 显示 prefetch_count 接近上限但 processed 增长缓慢。
根本原因不是并发不够，而是任务被提前锁死在 worker 内存里，无法被其他空闲 worker 抢走。尤其当任务耗时差异大（比如有的 100ms，有的 5s），高 prefetch 会让慢任务“霸占”大量预取额度，阻塞后续快速任务调度。
- 默认
worker_prefetch_multiplier=4，开 4 个进程 → 每个预取 4 条 → 总共锁住 16 条任务 - 若其中一条卡住 5 秒，这 5 秒内其他 15 条都只能干等
-
task_acks_late=True必须配合使用，否则任务一取走就 ack，失败后直接丢弃
Celery 并发模型：-c、-P、-concurrency 的真实作用
-c（即 worker_concurrency）控制的是“同时执行的任务数”，但它受制于实际使用的 pool 类型：-P solo 是单线程协程，-P prefork（默认）才是多进程，-P eventlet 或 -P gevent 是协程池。
立即学习“Python免费学习笔记（深入）”；
关键点在于：只有 prefork 模式下，-c 才真正对应操作系统进程数；而 eventlet 下，-c 是协程数量，不等于 CPU 核心数，且需确保所有依赖库是异步友好的（比如不能用 requests）。
- CPU 密集型任务：必须用
-P prefork -c $(nproc)，避免 GIL 拖累 - I/O 密集型任务（如 HTTP 调用、DB 查询）：可选
-P eventlet -c 1000，但要确认aiohttp/aiomysql已替换掉同步库 - 混合型任务：不要混用
prefork和eventlet在同一 worker，会引发不可预测的阻塞
prefetch 设置的三个安全阈值
prefetch 不是越大越好，它本质是“本地缓冲区大小”，和任务处理稳定性强相关。生产环境应按任务类型分 tier 设置：
- 短平快任务（worker_prefetch_multiplier=1，搭配
task_acks_late=True - 中等任务（100ms–2s，如轻量计算、API 转发）：
worker_prefetch_multiplier=2，必须开启worker_disable_rate_limits=True防止误触发限流 - 长任务（>2s，如文件处理、模型推理）：
worker_prefetch_multiplier=1强制逐条取，再配task_soft_time_limit=30+task_time_limit=45防夯死
所有场景下，broker_transport_options = {'visibility_timeout': 3600} 必须显式设为大于最长任务耗时，否则 Redis 消息会被重复投递。
为什么开了 task_acks_late 还会丢任务
典型错误是只设了 task_acks_late=True，却没关自动重试或没配死信队列。Celery 在 worker crash 时会把未 ack 的消息放回队列头部，导致“重复消费”，而非“丢失”。真丢任务的情况只发生在：
- 消息被消费、ack 了，但业务代码抛异常没被捕获 → 任务状态变成
FAILURE，但数据已变更，无法回滚 - 用了
redisbroker 且没配retry_policy，网络闪断时连接中断，消息直接消失（AMQP 协议如 RabbitMQ 默认更可靠） -
task_reject_on_worker_lost=True未开启，worker 被 kill -9 时来不及 requeue
最简兜底方案：对关键任务加 @app.task(bind=True, autoretry_for=(Exception,), retry_kwargs={'max_retries': 3})，并确保数据库操作幂等。
