使用Celery与RQ的利弊

Question

目前我正在研究需要实现一些后台工作的python项目（主要用于电子邮件发送和大量数据库更新）。我使用Redis作为任务经纪人。所以在这一点上我有两个候选人：Celery和RQ。我对这些工作队伍有一些经验，但我想请大家分享一下使用这些工具的经验。如此。

1. 使用Celery与RQ的优缺点。
2. 任何适合使用Celery与RQ的项目/任务示例。

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

Answer 1

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

简而言之，RQ的设计更加简单。芹菜的设计更加坚固。他们都很优秀。

• 文档。 RQ's documentation是全面而不复杂的，反映了项目的整体简洁性 - 你永远不会感到迷茫或困惑。 Celery's documentation也是全面的，但是当你第一次进行设置时，期望重新访问它，因为内部化的选项太多了

• 监视。 Celery's Flower和RQ dashboard设置非常简单，至少可以提供您想要的所有信息的90％

• 经纪人支持。 Celery是明显的赢家，RQ只支持Redis。这意味着关于“什么是经纪人”的文档较少，但也意味着如果Redis不再适合您，您将来不能转换经纪人。例如，Instagram considered both Redis and RabbitMQ with Celery。这很重要，因为不同的经纪人有不同的保证，例如Redis 不能（写作时）保证100％您的邮件已发送。

• 优先队列。 RQ优先队列模型简单有效 - workers read from queues in order。芹菜需要让多个工作人员从不同的队列中消费。两种方法都有效

• 操作系统支持。 Celery在这里是明显的赢家，因为RQ仅在支持fork的系统上运行，例如Unix系统

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

• API。 Celery非常灵活（多个结果后端，漂亮的配置格式，工作流画布支持），但自然这种能力可能会令人困惑。相比之下，RQ api很简单。

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

• 社区与稳定。 Celery可能更为成熟，但它们都是活跃的项目。截至撰写时，Celery在Github上有3500颗星，而RQ有〜2000颗，两个项目都显示出积极的发展

在我看来，Celery并不像它的声誉可能让你相信那么复杂，但你必须要进行RTFM。

那么，为什么有人愿意为RQ交易（可以说是功能更全面的）Celery？在我看来，这一切都归结为简洁。通过将自己限制在Redis + Unix，RQ提供了更简单的文档，更简单的代码库和更简单的API。这意味着您（以及项目的潜在贡献者）可以专注于您关心的代码，而不必在工作内存中保留有关任务队列系统的详细信息。我们对可以同时处理多少细节有一个限制，并且通过消除在那里保留任务队列细节的需要，RQ让我们回到你关心的代码。这种简单性是以牺牲语言间任务队列，广泛的操作系统支持，100％可靠的消息保证以及轻松切换消息代理的能力为代价的。

Answer 2

芹菜并不复杂。从核心开始，您从tutorials进行逐步配置，创建celery实例，使用@celery.task修饰您的函数，然后使用my_task.delay(*args, **kwargs)运行任务。

从您自己的评估来看，似乎您必须在缺乏（关键）功能或有一些多余的问题之间做出选择。在我的书中，这不是一个难以选择的选择。