Windows下Celery处理高CPU负载任务应选什么池搭配Redis做状态追踪？

• 完全串行处理，排队直接堵死：solo池是单进程单线程模型，同一时间只能跑1个任务，几百上千用户提交的话，后面的任务全在队列里排队等待，资源密集型任务本身执行周期就长，用户可能等几个小时都拿不到结果，服务基本等于不可用。
• 硬件资源完全浪费：高CPU任务本来就要利用多核性能，solo池最多只能用1个CPU核心，其余核心全部闲置，服务器性能利用率连10%都达不到，硬件成本完全浪费。
• 依然满足不了终止运行中任务的核心需求：就算用solo池，已经启动执行的任务调用默认revoke方法也终止不了，只有还没进入worker的排队任务能被撤销，正在运行的任务还是会占满资源直到执行结束。
• 完全没有扩展能力：后续用户量增长需要加服务器时，每个节点也只能同时跑1个任务，横向扩展成本是prefork池的数倍，完全不具备应对业务增长的能力。

• 方案1：修复prefork池的状态查询问题
  你遇到的prefork池查询任务状态一直是PENDING的问题，本质是Celery 4.x版本在Windows下的兼容性缺陷，不是prefork池本身的问题，调整配置即可解决：
  1. 把Celery升级到5.2+版本，该版本修复了大量Windows下prefork池的状态同步bug，同时兼容Python 3.9
  2. 在Celery配置中新增两个参数：task_track_started = True、task_acks_late = True，强制worker把任务启动、运行中、结束的全量状态同步到Redis结果后端
  3. 撤销任务时添加强制终止参数：revoke(task_id, terminate=True, signal='SIGTERM')，Windows下会直接杀掉对应prefork子进程，正在运行的任务也能正常终止
• 方案2：将AWS SQS替换为Redis作为消息中间件
  你原本就有备选方案是用Redis同时做消息中间件和结果后端，这个方案的兼容性更好：Celery对Redis作为broker的Windows支持度远高于SQS，替换后prefork池的状态查询、任务撤销功能基本可以正常运行，还能减少跨服务的兼容性问题。
• 方案3：生产环境切换为Linux系统
  你现在遇到的90%问题都来自Celery对Windows的不完善支持，Celery官方很早就明确不推荐将Windows作为生产运行环境。如果是上线的生产项目，直接切换到Linux系统部署，prefork池的状态查询、任务撤销、高并发处理能力全部原生正常，不需要做任何兼容性适配，是长期成本最低的方案。
• 方案4：自行实现任务终止逻辑，不依赖Celery原生功能
  完全绕开Celery的状态查询和revoke功能的兼容问题，自己在Redis中为每个用户存储当前生效的唯一任务ID，你的任务代码每执行一个关键步骤就校验一次，当前Redis存储的任务ID是否和自身ID一致，如果不一致就主动退出执行，不管用什么池都能实现终止旧任务的需求，完全规避Celery的Windows兼容问题。

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