目前我正在开发python项目，该项目需要实现一些后台作业(主要用于发送电子邮件和大量数据库更新)。我使用Redis作为任务代理。因此，在这一点上，我有两个候选人：Celery和RQ。我对这些工作队列有一些经验，但我想请你们分享一下使用这些工具的经验。所以。
- 使用芹菜与RQ的利弊
- 适合使用Celery与RQ的任何项目/任务示例
芹菜看起来很复杂，但它是功能齐全的解决方案。事实上，我不认为我需要所有这些功能。从另一方面来说，RQ非常简单(例如配置、集成)，但似乎缺乏一些有用的功能(例如任务撤销、代码自动重新加载)
以下是我在试图回答这个完全相同的问题时发现的内容。它可能不全面，甚至可能在某些方面不准确。
简而言之，RQ在所有方面都被设计得更简单。芹菜的设计更健壮。他们都很优秀。
- 文档。RQ的文档全面而不复杂，反映了项目的整体简单性——你永远不会感到迷失或困惑。Celery的文档也很全面，但当你第一次设置时，由于有太多的选项需要内化，所以希望经常重新访问它
-
监控。Celery‘s Flower和RQ仪表板的设置都非常简单，可以为您提供至少90%的信息
-
经纪人支持。Celery是明显的赢家，RQ只支持Redis。这意味着减少了关于"什么是经纪人"的文档，但也意味着如果Redis不再为您工作，您将来就不能更换经纪人。例如，Instagram考虑了Redis和RabbitMQ与Celery的结合。这一点很重要，因为不同的代理有不同的保证，例如Redis不能(截至撰写之时)100%保证您的消息已送达。
-
优先级队列。RQs优先级队列模型简单有效——工作人员按顺序读取队列。Celery需要旋转多个工作人员以从不同的队列中消费。两种方法都适用
-
操作系统支持。Celery是明显的赢家，因为RQ只在支持
fork的系统上运行，例如Unix系统 -
语言支持。RQ只支持Python，而Celery允许您将任务从一种语言发送到另一种语言
-
API。Celery非常灵活(多个结果后端、良好的配置格式、工作流画布支持)，但这种能力自然会令人困惑。相比之下，RQ api很简单。
-
子任务支持。Celery支持子任务(例如，从现有任务中创建新任务)。我不知道RQ是否做
-
社区与稳定。Celery可能更成熟，但它们都是活跃的项目。截至本文撰写之时，Celery在Github上拥有约3500颗星，而RQ拥有约2000颗星，这两个项目都显示出活跃的开发
在我看来，芹菜并不像它的声誉让你相信的那样复杂，但你必须进行RTF M。
那么，为什么有人愿意用(可以说是功能更全的)芹菜来换取RQ呢？在我看来，这一切都归结为简单。通过将自身限制为Redis+Unix，RQ提供了更简单的文档、更简单的代码库和更简单的API。这意味着您(以及项目的潜在贡献者)可以专注于您关心的代码，而不必在工作内存中保留有关任务队列系统的详细信息。我们都有一个限制，一次可以在我们的脑海中有多少细节，通过消除在那里保留任务队列细节的需要，RQ让我们回到你关心的代码。这种简单性是以牺牲语言间任务队列、广泛的操作系统支持、100%可靠的消息保证以及轻松切换消息代理等功能为代价的。
芹菜并没有那么复杂。其核心是，从tutorials开始逐步配置，创建一个celery实例，用@celery.task装饰函数，然后用my_task.delay(*args, **kwargs)运行任务。
从你自己的评估来看，你似乎必须在缺乏(关键)功能或有一些多余的功能之间做出选择。在我的书中，这不是一个太难的选择。