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

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

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

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

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

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

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

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