使用Celery与RQ的利弊

Question

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

1. 使用Celery与RQ有什么利弊.
2. 任何适合使用Celery与RQ的项目/任务示例.

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

Answer 1

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

简而言之,RQ的设计更加简单.芹菜的设计更加坚固.他们都很优秀.

• 文档.RQ的文档全面而不复杂,反映了项目的整体简洁性 - 您永远不会感到迷茫或困惑.Celery的文档也很全面,但是当你第一次设置时,期望重新访问它,因为内部化的选项太多了

• 监测.Celery's Flower和RQ仪表板设置非常简单,至少可以为您提供所需信息的90%

• 经纪人支持.Celery是明显的赢家,RQ只支持Redis.这意味着关于"什么是经纪人"的文档较少,但也意味着如果Redis不再适合您,您将来不能转换经纪人.例如,Instagram与Celery一起考虑了Redis和RabbitMQ.这很重要,因为不同的经纪人有不同的保证,例如Redis 不能(写作时)保证100%的消息被传递.

• 优先级队列.RQ优先队列模型简单有效 - 工作人员按顺序从队列中读取.芹菜需要让多个工人自动从不同的队列中消费.两种方法都有效

• OS支持.Celery在这里是明显的赢家,因为RQ仅在支持forkUnix系统的系统上运行

• 语言支持.RQ只支持Python,而Celery允许您将任务从一种语言发送到另一种语言

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

• 子任务支持.Celery支持子任务(例如,从现有任务中创建新任务).我不知道RQ是否这样做

• 社区与稳定.Celery可能更为成熟,但它们都是活跃的项目.在写作方面,Celery在Github上有3500颗星,而RQ有〜2000颗,两个项目都表现出积极的发展

在我看来,Celery并不像它的声誉可能让你相信那么复杂,但你必须要RTFM.

那么,为什么有人愿意为RQ交易(可以说是更全功能的)Celery？在我看来,这一切都归结为简洁.通过将自己限制在Redis + Unix,RQ提供了更简单的文档,更简单的代码库和更简单的API.这意味着您(以及项目的潜在贡献者)可以专注于您关心的代码,而不必在工作内存中保留有关任务队列系统的详细信息.我们对可以同时处理多少细节有一个限制,并且通过消除在那里保留任务队列细节的需要,RQ让我们回到你关心的代码.这种简单性是以牺牲语言间任务队列,广泛的操作系统支持,100%可靠的消息保证以及轻松切换消息代理的能力为代价的.