使用芹菜和 RQ 的优缺点

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

  1. 使用芹菜和 RQ 的利弊。
  2. 任何适合使用芹菜和 RQ 的项目/任务的例子。

Celery looks pretty complicated but it's full featured solution. Actually I don't think that I need all these features. From other side RQ is very simple (e.g configuration, integration), but it seems that it lacks some useful features (e.g task revoking, code auto-reloading)

42095 次浏览
小开

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

从你自己的评估来看，似乎你必须在缺乏(关键)特性或有一些多余的功能之间做出选择。在我看来，这个选择并不难。

小开
最佳答案

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

简而言之，RQ 的设计就是为了使各方面都更简单。芹菜被设计得更结实。他们都很优秀。

  • 文件。RQ's documentation是全面而不复杂的，它反映了项目的整体简单性——您永远不会感到迷失或困惑。芹菜的文件也是综合性的，但是当你第一次设置的时候，有太多的选择需要内化，所以你应该经常重新访问它

  • 监察。Celery's Flower和 RQ 仪表盘都是非常简单的设置和给你至少90% 的所有信息，你会想要的

  • Broker support. Celery is the clear winner, RQ only supports Redis. This means less documentation on "what is a broker", but also means you cannot switch brokers in the future if Redis no longer works for you. For example, Instagram 同时考虑了 Redis 和 RabbitMQ 和芹菜. This is important because different brokers have different guarantees e.g. Redis 不能 (as of writing) guarantee 100% that your messages are delivered.

  • 优先排队。RQs 优先级队列模型简单有效-工作人员按顺序从队列中读取数据。芹菜需要旋转多个工人从不同的队列消费。这两种方法都有效

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

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

  • 空气污染指数。芹菜是非常灵活的(多个结果后端，良好的配置格式，工作流画布支持) ，但自然这种力量可以混淆。相比之下，RQapi 很简单。

  • Subtask support. Celery supports subtasks (e.g. creating new tasks from within existing tasks). I don't know if RQ does

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

在我看来，芹菜并不像它的名声可能会让你相信的那么复杂，但是你将不得不 RTFM。

So, why would anyone be willing to trade the (arguably more full-featured) Celery for RQ? In my mind, it all comes down to the simplicity. By restricting itself to Redis+Unix, RQ provides simpler documentation, simpler codebase, and a simpler API. This means you (and potential contributors to your project) can focus on the code you care about, instead of having to keep details about the task queue system in your working memory. We all have a limit on how many details can be in our head at once, and by removing the need to keep task queue details in there RQ lets get back to the code you care about. That simplicity comes at the expense of features like inter-language task queues, wide OS support, 100% reliable message guarantees, and ability to switch message brokers easily.


提交答案