回答问题

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

1. 使用 Celery 与 RQ 的优缺点。

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

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

Answers

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

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

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

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

• 经纪人支持。 Celery 是明显的赢家,RQ 只支持 Redis。这意味着关于“什么是代理”的文档更少,但也意味着如果 Redis 不再适合您,您将来无法切换代理。例如,Instagram 使用 Celery同时考虑了 Redis 和 RabbitMQ。这很重要,因为不同的经纪人有不同的保证,例如Redis cannot (截至发稿时)保证 100% 地传递您的消息。

• 优先队列。 RQs 优先队列模型简单有效——worker 从队列中读取顺序为。 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 可以让您回到您关心的代码。这种简单性是以牺牲诸如跨语言任务队列、广泛的操作系统支持、100% 可靠的消息保证以及轻松切换消息代理的能力等特性为代价的。