使用Celery vs. RQ的利弊[关闭]

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

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

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

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

简而言之，RQ被设计为更简单。芹菜被设计为更坚固。他们俩都很棒。

• 文档。RQ的文档全面而又不复杂，并且反映了项目的整体简单性-您永远不会感到迷茫或困惑。Celery的文档也很全面，但是在您第一次进行设置时，由于有太多可供选择的内部化选项，因此希望能重新访问它

• 监控。Celery的Flower和RQ仪表板都很容易设置，并且至少为您提供了90％的所有信息

• 经纪人支持。芹菜无疑是赢家，RQ仅支持Redis。这意味着有关“什么是经纪人”的文档更少，但是也意味着，如果Redis不再为您服务，则您将来将无法切换经纪人。例如，Instagram在Celery中同时考虑了Redis和RabbitMQ。这很重要，因为不同的代理有不同的保证，例如，Redis 无法（截至撰写时）保证100％传递您的消息。

• 优先级队列。RQ的优先级队列模型简单有效，工作人员按顺序从队列中读取。芹菜要求纺纱多个工人从不同的队列消费。两种方法都有效

• 操作系统支持。Celery无疑是赢家，因为RQ仅在支持forkUnix系统的系统上运行

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

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

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

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

我认为，Celery并不像其声誉可能会让您相信的那么复杂，但是您将不得不使用RTFM。

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

芹菜并不那么复杂。从本质上讲，您可以从进行逐步配置tutorials，创建一个celery实例，用装饰您的功能，@celery.task然后使用来运行任务my_task.delay(*args, **kwargs)。

从您自己的评估来看，似乎您必须在缺少（关键）功能或有些多余的东西之间进行选择。在我的书中，这并不是很难选择的选择。