芹菜与RQ的利弊比较

Question

目前，我正在从事python项目，该项目需要实现一些后台作业（主要用于发送电子邮件和大量数据库更新）。我使用Redis作为任务代理。在这一点上，我有两个候选者：Celery和RQ。我对这些工作队列有一些经验，但我想请你们分享一下使用这些工具的经验。所以。

1. 用芹菜对RQ有什么利弊。
2. 任何适合使用芹菜和RQ的项目/任务示例。

芹菜看起来很复杂，但它是功能齐全的解决方案。实际上，我不认为我需要所有这些功能。另一方面，RQ非常简单（例如配置、集成），但它似乎缺少一些有用的特性（例如任务撤销、代码自动重新加载）

Answer 1

这是我在回答同样的问题时发现的。它可能不全面，甚至在某些方面可能不准确。

简言之，RQ的设计要更简单。芹菜被设计得更结实。他们都很优秀。

• 文件。RQ's documentation全面而不复杂，反映了项目的整体简单性—您永远不会感到迷失或困惑。Celery's documentation也很全面，但是当您第一次设置时，希望能够经常重新访问它，因为有太多的选项需要内部化

• 监测。Celery's Flower和RQ dashboard都是非常简单的设置，并为您提供至少90%的所有信息

• 经纪人支持。芹菜是明显的赢家，RQ只支持Redis。这意味着关于“什么是代理”的文档较少，但也意味着如果Redis不再适合您，您以后就不能切换代理。例如，Instagram considered both Redis and RabbitMQ with Celery。这一点很重要，因为不同的代理有不同的保证，例如Redis无法（从编写之日起）保证100%地传递消息。

• 优先队列。RQs优先级队列模型简单有效-workers read from queues in order。芹菜需要把多个工人从不同的队列中分出来食用。两种方法都有效

• 操作系统支持。芹菜显然是胜利者，因为RQ只在支持fork的系统上运行，例如Unix系统

• 语言支持。RQ只支持Python，而芹菜允许您将任务从一种语言发送到另一种语言

• 美国石油学会。芹菜是非常灵活的（多个结果后端，良好的配置格式，工作流程画布支持），但自然这个权力可以混淆。相比之下，RQ api很简单。

• 子任务支持。芹菜支持子任务（例如，从现有任务中创建新任务）。我不知道RQ是否有效

• 社区和稳定。芹菜可能更成熟，但它们都是积极的项目。撰写本文时，Celery在Github上拥有约3500颗星星，而RQ拥有约2000颗星星，两个项目都显示出了积极的发展

在我看来，芹菜并不像它的名声能让你相信的那么复杂，但你必须相信它。

那么，为什么有人愿意用芹菜（可以说功能更全）来换取RQ呢？在我看来，一切都归结于简单。通过将自身限制为Redis+Unix，RQ提供了更简单的文档、更简单的代码库和更简单的API。这意味着您（以及项目的潜在贡献者）可以专注于您关心的代码，而不必在工作内存中保留有关任务队列系统的详细信息。我们都有一个限制，一次可以在我们的头脑中包含多少细节，并且通过消除在其中保留任务队列细节的需要，RQ让我们回到您关心的代码。这种简单性是以牺牲诸如跨语言任务队列、广泛的操作系统支持、100%可靠的消息保证以及轻松切换消息代理的能力等功能为代价的。

Answer 2

芹菜没那么复杂。其核心是从^{}进行逐步配置，创建一个celery实例，用@celery.task装饰函数，然后用my_task.delay(*args, **kwargs)运行任务。

从你自己的评价来看，似乎你必须在缺少（关键）特征或是有一些多余的特征之间做出选择。这在我的书中不是很难选择的。