DjangoCelery并发设置详解

本文深入解析了 Django 项目中 Celery 消费者并发配置的核心原理与实战陷阱：不仅厘清了 `--concurrency`（单进程任务数）与 worker 进程数的本质区别，还直击生产环境高频痛点——数据库连接耗尽、死锁冲突、多实例协同失控及任务假活跃等问题；通过分布式锁、`select_for_update`、Redis 计数器等可落地方案，手把手教你科学限流、安全排队、精准控压，强调“并发配置只是水龙头，任务逻辑才是水管”，真正帮你避开盲目调参带来的 OOM、连接风暴和隐性雪崩。

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 本身不提供行级锁或排队语义，得自己兜底。

常见做法是结合任务签名 + 锁机制：

• 用 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 或内存泄漏

并发配置只是水龙头，任务逻辑才是水管。拧紧水龙头治不了爆裂的管道。

今天关于《DjangoCelery并发设置详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！