python - 使用 Celery 与 RQ 的优缺点

Question

关闭。这个问题需要更多 focused .它目前不接受答案。

---

想要改进这个问题吗？ 更新问题，使其只关注一个问题 editing this post .

关闭 5 年前。

Improve this question

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

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

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

Answer 1

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

简而言之，RQ 的设计宗旨是在所有方面都更简单。 celery 被设计得更健壮。他们都很优秀。

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

• 监控。 Celery's Flower和 RQ dashboard设置起来都非常简单，并且可以为您提供至少 90% 的您想要的所有信息

• 代理支持。 Celery 是明显的赢家，RQ 只支持 Redis。这意味着关于“什么是代理”的文档更少，但也意味着如果 Redis 不再适合您，您将来无法切换代理。例如，Instagram considered both Redis and RabbitMQ with Celery .这很重要，因为不同的经纪人有不同的保证，例如Redis 不能(在撰写本文时)保证 100% 地传递您的消息。

• 优先队列。 RQs 优先队列模型简单有效 - workers read from queues in order . Celery 需要启动多个 worker 以从不同的队列中消费。两种方法都有效

• 操作系统支持。 Celery 是明显的赢家，因为 RQ 仅在支持 fork 的系统上运行，例如Unix系统

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

• API。 Celery 非常灵活(多个结果后端、漂亮的配置格式、工作流 Canvas 支持)，但这种能力自然会令人困惑。相比之下，RQ api 很简单。

• 子任务支持。 Celery 支持子任务(例如，从现有任务中创建新任务)。不知道RQ有没有

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

在我看来，Celery 并不像它的名声可能让您相信的那么复杂，但您必须使用 RTFM。

那么，为什么会有人愿意用(可以说功能更全的)Celery 来换取 RQ？在我看来，这一切都归结为简单。通过将自身限制为 Redis+Unix，RQ 提供了更简单的文档、更简单的代码库和更简单的 API。这意味着您(以及您项目的潜在贡献者)可以专注于您关心的代码，而不必将有关任务队列系统的详细信息保存在您的工作内存中。我们所有人都对一次可以在脑海中存储多少细节有限制，通过消除在其中保留任务队列细节的需要，RQ 可以让您回到您关心的代码。这种简单性是以牺牲诸如跨语言任务队列、广泛的操作系统支持、100% 可靠的消息保证以及轻松切换消息代理的能力等特性为代价的。