默认并发数由 --concurrency 参数（或 worker_concurrency 配置）控制，值为 CPU 核心数；它指定单个 worker 进程内同时执行的任务数，而非进程数。
celery worker 启动时怎么设并发数
默认情况下，celery worker 会按 CPU 核心数启动等量的子进程（prefork 模型），比如 4 核机器就起 4 个 worker 进程。这不是“线程数”，而是独立的、内存隔离的 Python 进程 —— 所以实际并发任务数 ≈ 进程数 × 每进程的 concurrency 值（但通常只设一次）。
真正控制单个 worker 实例能同时处理多少个任务的，是 --concurrency 参数（或配置项 worker_concurrency）：
celery -A myproject worker --concurrency=2
这个值设为 1 就是串行执行；设为 8 就最多同时跑 8 个任务（在该 worker 进程内）。
-
--concurrency是最直接、最常用的方式，优先级高于配置文件里的worker_concurrency - 若用
gevent或eventlet作为 pool（如--pool=gevent --concurrency=100），这时--concurrency表示协程数，不是进程数 —— 但要注意：Django ORM 默认非线程/协程安全，需额外加django-db-geventpool等适配 - 不要盲目调高：每个并发任务都可能占用数据库连接、内存和文件描述符，超限会触发
OperationalError: too many connections或 OOM
Django 中如何防止 Celery 并发冲垮数据库
并发数设得再低，如果一堆任务都在写同一个表（比如更新用户积分），还是可能引发死锁或唯一约束冲突。Celery 本身不提供行级锁或排队语义，得自己兜底。
立即学习“Python免费学习笔记（深入）”；
常见做法是结合任务签名 + 锁机制：
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 用
cache.add(key, 'locked', timeout=300)做简易分布式锁，key 可基于任务参数哈希生成（如f"update_balance_{user_id}"） - 对强顺序依赖的任务，改用
chord或链式调用（s1.s() | s2.s()），但注意这会牺牲并行性 - 更稳妥的是在数据库层加
SELECT ... FOR UPDATE（Django 用.select_for_update()），但仅对事务内操作有效，且需确保 task 在事务中执行（配合@transaction.atomic）
别依赖 rate_limit 来控并发 —— 它限制的是单位时间内的调用频次，不是同时运行数。比如 rate_limit='10/m' 允许每分钟最多 10 个任务开始执行，但若前 10 个都卡在 IO 上，第 11 个仍会被阻塞排队，不解决资源争抢。
多个 worker 实例之间怎么协同限流
单个 --concurrency=4 的 worker 不代表整个系统只有 4 并发。如果你启了 3 个 worker（比如按队列拆分），那总并发上限就是 3 × 4 = 12 —— 除非你显式做了跨进程协调。
真实生产中，往往需要全局并发上限（比如“支付回调任务最多同时处理 5 个”），这时得靠外部信号：
- 用 Redis 的
INCR/DECR+ 过期时间模拟计数器，在task_prerun和task_postrun信号里增减 - 借助
celery-batches或自定义Task.apply_async包装器，在提交前查 Redis 计数器，超限时抛Retry或进等待队列 - 避免用文件锁或本地变量 —— 多 worker 进程间不共享内存，根本无效
注意：Redis 计数器方案要处理任务失败未释放的情况，建议搭配 retry=False + 死信队列 + 定时巡检脚本清理残留锁。
为什么加了 --concurrency 还看到大量任务堆积在 active 状态
任务显示为 active 但迟迟不完成，大概率不是并发设高了，而是任务本身卡住了 —— 最常见的是数据库连接耗尽、HTTP 请求没设 timeout、或者用了同步阻塞调用（如 requests.get() 而没配 timeout）。
- 用
celery inspect active查看正在跑的任务详情，确认是不是全堵在某个函数里（比如send_mail()或requests.post()） - 检查数据库连接池：Django 默认每个线程/进程独占连接，worker 进程数 × concurrency 超过
max_connections就会卡住，需调大 PostgreSQL 的max_connections或用连接池中间件 -
--pool=prefork（默认）下，一个任务崩溃会导致整个子进程退出，继而触发 respawn，表现为日志里频繁出现Process 'ForkPoolWorker-2' pid:1234 exited with 'signal 11 (SIGSEGV)'—— 这时并发数再低也没用，得先 fix segfault 或内存泄漏
并发配置只是水龙头，任务逻辑才是水管。拧紧水龙头治不了爆裂的管道。
