调大worker_prefetch_multiplier会加剧任务饥饿和丢失风险：长任务阻塞进程导致短任务排队，且worker崩溃时预取未确认任务会被锁住；应设为1并启用task_acks_late=true。
为什么调大 worker_prefetch_multiplier 反而让任务更卡？
默认值是 4，意味着一个 worker 会一次性从 Redis/RabbitMQ 拉取最多 4 个任务到本地内存。当存在长耗时任务（比如 30 秒的 PDF 生成）和短任务（比如 100ms 的发短信）混杂时，长任务占着进程不放，短任务只能排队等——这就是“饥饿”现象。
真正起作用的是 task_acks_late=True 配合 worker_prefetch_multiplier=1：任务执行完才确认消费，Broker 才会把下一个任务发过来。否则预取太多，worker 进程一崩，所有已预取但未确认的任务就“消失”了（实际还在队列里，但被锁住）。
- 不要盲目设成 0 或负数——Celery 会忽略，回退到默认值 4
- 若用
--pool=eventlet或--pool=gevent，prefetch 行为受协程调度影响，=1仍是安全起点 - RabbitMQ 用户注意：
prefetch_count是 AMQP 层级概念，Celery 的worker_prefetch_multiplier会乘以worker_concurrency后设置它；Redis 没有原生 prefetch，靠 Celery 自己模拟，所以更依赖task_acks_late
worker_concurrency 设多少才不浪费也不过载？
它不是“越多越好”。这个值控制每个 worker 进程 fork 出多少子进程（prefork 模式下），或启动多少线程/协程（eventlet/gevent）。设太高会导致频繁上下文切换、内存暴涨；设太低则压根跑不满 CPU。
经验公式是：worker_concurrency = CPU 核心数 × (1.0 ~ 1.5)。例如 4 核机器，从 4 开始试，观察 celery -A proj inspect stats 输出里的 pool.processes 和系统 htop 中的 CPU idle%：
- CPU idle 持续 >30%，可尝试 +1
- 内存 RSS 超过 1.5GB/worker 进程，说明单任务内存开销大，应降并发、拆任务
- 用
--autoscale=10,3时，Celery 会按队列积压自动启停子进程，但前提是你的任务执行时间相对稳定；突发性长任务会让 autoscale 失效
加 Worker 数量前，先确认是不是 Broker 或网络在拖后腿
启动 10 个 worker 却不见吞吐提升？大概率瓶颈不在 worker 本身。先验证 Broker 健康度：
- Redis：运行
redis-cli --latency -h your-redis-host，平均延迟 >10ms 就要查网络或 Redis 实例规格 - RabbitMQ：用
celery -A proj inspect ping看各 worker 是否都能秒回；如果某个 worker ping 不通，但status显示 OK，说明管理进程活着，但子进程或连接池卡死了 - 检查连接数：Redis 默认 maxclients=10000，Celery 每个 worker 默认建 10 个连接（
BROKER_POOL_LIMIT=10），10 个 worker 就占 100 连接；但若开了--autoscale或用了大量AsyncResult查询，连接可能瞬间飙高
别跳过这步——很多团队花半天调优 worker_concurrency，最后发现是 Redis 连接超时被内核 kill 了。
任务积压时，光加资源不如先切队列
当 celery -A proj inspect active 显示大量任务卡在同一个 queue（比如 default），且 inspect stats 里 broker.queued 持续 >1000，说明单一队列已成为瓶颈。此时加 worker 或调 prefetch 效果有限。
立刻做两件事：
- 按优先级或类型拆队列：定义
high、low、batch三个 queue，用@app.task(queue='high')标记关键任务 - 启动专用 worker：分别运行
celery -A proj worker -Q high --concurrency=2和celery -A proj worker -Q default,low --concurrency=8，避免低优任务饿死高优任务 - 检查是否漏了
CELERY_TASK_REJECT_ON_WORKER_LOST=True：Worker 崩溃时，未确认任务会被重新入队；否则它们就“静默丢失”了，你看到的积压其实是假象
队列分离是最容易落地、见效最快的积压缓解手段——它不依赖硬件扩容，只改配置和启动命令。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
