119

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

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

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

4

2 回答 2

177

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

简而言之，RQ 被设计得更简单。芹菜被设计得更健壮。他们都很优秀。

  • 文档。RQ 的文档全面而​​不复杂，并且反映了项目的整体简单性——您永远不会感到迷茫或困惑。Celery 的文档也很全面，但是当你第一次设置时，你会经常重新访问它，因为有太多的选项需要内化

  • 监测。Celery 的 Flower和RQ 仪表板都非常易于设置，并为您提供至少 90% 的您想要的所有信息

  • 经纪人支持。Celery 是明显的赢家，RQ 只支持 Redis。这意味着关于“什么是代理”的文档更少，但也意味着如果 Redis 不再适合您，您将来无法切换代理。例如，Instagram 考虑了 Redis 和 RabbitMQ 与 Celery。这很重要，因为不同的代理有不同的保证，例如 Redis不能（在撰写本文时）保证 100% 的消息被传递。

  • 优先队列。RQs 优先队列模型简单而有效——工作人员按顺序从队列中读取。Celery 需要启动多个工人以从不同的队列中消费。两种方法都有效

  • 操作系统支持。Celery 是明显的赢家，因为 RQ 只在支持forkUnix 系统的系统上运行

  • 语言支持。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% 可靠的消息保证以及轻松切换消息代理的能力等特性为代价的。

于 2015-04-24T02:54:53.267 回答
0

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

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

于 2012-11-18T16:05:53.590 回答