Celery任务重复调用修改对象异常及Django+AI服务选型咨询

一、实验现象原理分析 #

1. 状态检查未生效的原因 #

Celery默认采用多进程工作模式，每个worker进程拥有完全独立的内存空间。你代码中定义的全局变量arr和status，是每个worker进程私有的，进程之间无法直接共享这些变量。

当你同时发起两个请求时，第一个请求被Worker A处理，Worker A将自身的status设为busy；第二个请求被空闲的Worker B接收到，Worker B自己的status初始值是waiting，完全看不到Worker A的状态变更，所以直接执行了任务逻辑，根本不会触发return 'try later'的分支。

2. 第二次调用看似修改数组的原因 #

第二个任务由Worker B处理，Worker B的arr是全新的空数组，执行append(5)后，返回的是Worker B自己内存中的[5]；而你用来检查数组状态的任务，大概率是被Worker A（或其他未执行第二个任务的进程）处理，读取的是Worker A内存中的[3]。这两个arr是完全独立的变量，不存在任何关联，所以出现了"返回结果和实际检查结果不一致"的情况。

二、目标场景适配性与建议 #

Celery完全适合你这种"Django API + AI服务Worker"的场景，但不能依赖进程内全局变量做状态控制，需要改用跨进程的共享机制，以下是具体建议：

• 用共享存储统一维护状态：将模型加载状态、忙闲标记存储在Redis、Memcached或Django数据库中，所有Worker进程都从这个共享存储读取和更新状态，确保状态判断的一致性。
• 实现分布式锁：使用基于Redis的分布式锁（如通过redis-py实现），或者Celery的锁扩展，保证同一时间只有一个任务执行模型加载/修改操作，其他请求要么等待锁释放，要么直接返回"服务忙，请稍后再试"的提示。
• 优化模型管理逻辑：
  • 如果是多Worker架构，可以让每个Worker进程维护自己的模型实例，通过消息队列传递模型切换指令，Worker收到指令后在本地加载新模型；
  • 或者单独部署一个模型管理进程，负责加载/切换模型，Worker进程仅负责预测，需要时从管理进程获取当前可用的模型实例。
• Django API层前置检查：在Django的API视图中，先查询共享存储中的忙闲状态，若服务处于"加载模型"状态，直接返回提示，避免将任务提交到Celery队列；若状态空闲，再提交预测或模型加载任务。

内容的提问来源于stack exchange，提问作者Karol Borkowski