我刚开始在我的Django项目中使用Celery，却不禁怀疑：这是开始为项目启动Celery工人的最优雅的方法吗？
让我解释一下这个问题的原因。
当前，推荐的启动Celery的方法似乎是在更简单的设置中使用python manage.py celeryd，在更复杂的设置中使用类似/etc/init.d/celeryd start的方法。但是，在第一种情况下，此过程感觉很脆弱，因为该过程不会自动启动，而在第二种情况下，则需要大量项目特定的配置（virtualenv，settings等）。尤其是后者展示了我的一般感觉Celery工人与它的代码库紧密相关，并且也与主项目流程紧密相关，因为实际上没有任何东西可以在其中创建任务的Celery工人实际上是无用的（celerybeat是一个例外）。 init.d脚本的另一个问题是，它们需要一些高级逻辑来处理每台服务器的多个项目（具有单独的虚拟环境，设置，路径等）。
因此，我认为与我的主要流程一起启动celeryd可能是一种非常优雅的配置方式。使用Apache从mod_wsgi生成它（其他设置选项与此类似），从而在主进程关闭时将其杀死（/etc/init.d/apache2 stop）。但是，我不太确定在这种推理中是否存在考虑性能和/或安全性的技术陷阱-既然我尝试使用Google搜索，但实际上什么也没发现，那么情况可能就是这样。
考虑到Celery体系结构，我的推理是否有缺陷？
我能以某种方式从celeryd内的某个地方生成mod_wsgi吗？
您如何在项目中启动Celery工人？
最佳答案
我先使用manage.py celeryd来启动celery，然后通过主管进行管理。在每次修改任务的部署中，我只需在部署并重新启动apache之后重新启动celery。\
编辑：
我们使用厨师来管理我们的主管和其他流程的配置，因此这可能有点过时。我们有一个主supervisor.conf，其中为我们运行的每个站点都包含一个单独的配置文件。其中之一可能看起来像这样：
[program:celery_newproject]
command = /srv/www/.virtualenvs/newprojectenv/bin/python /srv/www/projects/newproject/manage.py celeryd --concurrency=2 --settings=settings.alpha --pidfile=/var/run/celery/celery_newproject.pid
user = wsgiuser
environment = PYTHON_EGG_CACHE="/tmp/.python-eggs"
部署后，我们就可以运行
sudo supervisorctl restart celery_newproject
这将重新启动芹菜管理程序，并接管您定义的所有新任务。
还有其他非优雅的方法也可以做到这一点。在我的个人站点上，我只运行了一个cron作业，该作业检查.pid文件是否存在，如果不存在，请重新启动celery。一点都不优雅，但是它适用于可靠性较低的站点。