使用 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% 的消息已送达。

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

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

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

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

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

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

在我看来，Celery 并不像它的名声让你相信的那么复杂，但你必须使用 RTFM。

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

Answer 2

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

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