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

  • Z时代
  • 2024-01-10
  • 分类：问答

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

  1. 使用Celery vs.RQ有什么优缺点。

  2. 适合使用Celery vs. RQ的项目/任务的任何示例。

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

回答：

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

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

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

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

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

  • 优先级队列。RQ的优先级队列模型简单有效，工作人员按顺序从队列中读取。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让您回到您关心的代码。这种简单性是以语言间任务队列，广泛的OS支持，100％可靠的消息保证以及轻松切换消息代理的功能为代价的。

以上是 使用Celery vs. RQ的利弊[关闭] 的全部内容， 来源链接： utcz.com/qa/433321.html

回到顶部