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

目前,我正在从事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

回到顶部