使用gevent池从Python内部启动Celery Worker后无法运行的问题咨询

问题原因 #

直接调用app.Worker().start()启动gevent worker时，Celery不会自动执行gevent的猴子补丁——而命令行启动celery worker时，Celery的底层脚本会自动触发这个补丁，替换标准库中的IO、线程相关模块，让gevent的协程机制能正常接管任务调度。没有补丁的话，gevent无法正确处理异步IO，任务能被队列接收，但无法被协程调度执行，表现为进程冻结。

解决方案 #

在启动Worker之前手动执行gevent的猴子补丁，并且要确保补丁在Celery app初始化、其他模块导入之前执行（至少要早于Worker实例化）。

示例代码 #

import gevent.monkey
# 先打猴子补丁，替换所有能替换的模块（socket, threading等）
gevent.monkey.patch_all()

from celery import Celery
import settings

app = Celery('your_app')
app.config_from_object(settings)

# 初始化并启动Worker
worker = app.Worker(
    name=f"{settings.APP}_{pool}_{concurrency}_@%h",
    queues=queues,
    pool=pool,
    concurrency=concurrency,
    loglevel="INFO",
    task_events=True,
)
worker.start()

额外注意事项 #

• 如果你的代码中还有其他第三方库（比如数据库驱动、HTTP客户端），要确保它们支持gevent的猴子补丁，或者使用gevent兼容的版本。
• 可以调整worker_prefetch_multiplier参数，gevent场景下建议设为1，避免预取过多任务导致内存占用过高：

  app.conf.worker_prefetch_multiplier = 1
  

为什么worker.start()会失效？ #

Celery的命令行启动流程（celery worker）会经过一系列初始化步骤，其中就包括针对gevent池的猴子补丁逻辑。而直接实例化app.Worker并调用start()，相当于跳过了Celery命令行入口的初始化钩子，没有触发gevent补丁的自动执行，导致gevent协程无法正常调度任务，进程看起来冻结但能接收任务（因为RabbitMQ的连接可能还能工作，但任务执行的协程无法被调度）。

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