我正在尝试在django中做一些消耗大量时间的任务。为此，我将运行后台任务。
经过一番研发，我找到了两种解决方案：
-
芹菜配兔子MQ。
-
Django 后台任务。
这两个选项似乎都符合标准，但设置 Celery 需要一些工作。现在就第二个选项而言，设置相当简单，在相当短的时间内，我可以继续编写后台任务。现在，如果我采用第二个选项，我的问题是：
- Django 后台任务执行得如何？(生产环境中的可扩展性明智(。
- 我可以在数据库中轮询任务(一段时间后(以检查任务的状态吗？
- Django-Background-tasks的架构？找不到关于它架构的任何明确解释(或者我错过了一些资源？
- 再次来到第一点，Django 后台任务在生产环境中的表现如何。(谈谈在生产中使用它的先前经验。
设置芹菜需要工作(尽管使用 Redis 时较少(。它也是一个严肃的工具，拥有近十年的投资和广泛的行业采用。
至于性能，由队列支持的任务系统的扩展行为与由RDBM支持的任务系统的扩展行为是很好的理解 - 但可能与您无关，因为"可伸缩性"是一个非常主观的术语。这个线程提供了一些关于主题和问题的良好框架。
比较GitHub上的星星(bg tasks的3XX和Celery的13XXX(，你应该意识到Django-Background-tasks的用户群较小，你可能需要进入内部来理解架构和精确的机制。这不应该阻止你 - 只要准备好在没有答案时DIY。
-
Django 后台任务的表现如何？ - 这将取决于您实现的方式和内容。需要注意的一点是，Django-background-tasks是基于数据库的，其中celery可以将redis/rabbitmq作为后端，因此我们很可能会在这里看到相当大的性能差异。
-
我可以在数据库中轮询任务(一段时间后(以检查任务的状态吗？ - 在芹菜中是可能的，也许你可以通过检查 django-background-tasks 内部代码找到解决方案。但有一点是，我们可以中止芹菜任务，这在 Django-Background-tasks 中可能是不可能的。
-
Django-Background-tasks的架构？找不到任何关于它的架构的明确解释(或者我错过了一些资源？ - 这是一个简单的基于 Django 的项目。你可以看看代码。这似乎很简单。
-
再次来到第一点，Django 后台任务在生产环境中的表现如何。 - 尚未在生产中使用。但是由于Django-Background-tasks是基于数据库的，并且芹菜可以配置为使用redis/rabbitmq - 我认为芹菜在这里有一个优点。
对我来说，这种比较似乎是将手枪与高端自动机枪进行比较的链接。两者都做同样的工作。但是一个简单的简单 - 其他有点复杂，但有很多选择和范围。
根据您的使用案例进行选择。
我决定使用 Django-Background-Tasks。让我澄清一下我的动机。
Django-Background-Tasks 将要处理的任务不需要快速处理。顾名思义，它们是后台任务。我接受延误。
Django-Background-Tasks的架构非常简单。当你在代码中调用一个方法在后台处理时，任务记录会插入到数据库中的 Django-Background-Tasks 表中。并且您调用的方法实际上并未执行。它是代理的。然后，您应该触发另一个进程来执行作业。然后，在此过程中执行您的方法。
执行作业的进程可以由服务器中的 cron 条目执行。
由于这个设置非常简单且有效，我决定使用 Django-Background-Tasks。但是，如果我需要响应更快、速度更快的东西，我会使用 Celery，因为它正在使用内存，并且有一个活动进程来处理作业。在Django-Background-Tasks中并非如此。