<p>这是我在回答同样的问题时发现的。它可能不全面,甚至在某些方面可能不准确。</p>
<p>简言之,RQ的设计要更简单。芹菜被设计得更结实。他们都很优秀。</p>
<ul>
<li>文件。<a href="http://python-rq.org/" rel="noreferrer">RQ's documentation</a>全面而不复杂,反映了项目的整体简单性—您永远不会感到迷失或困惑。<a href="https://celery.readthedocs.org/en/latest/getting-started/brokers/redis.html" rel="noreferrer">Celery's documentation</a>也很全面,但是当您第一次设置时,希望能够经常重新访问它,因为有太多的选项需要内部化</li>
<li><p>监测。<a href="https://github.com/mher/flower" rel="noreferrer">Celery's Flower</a>和<a href="https://github.com/nvie/rq-dashboard" rel="noreferrer">RQ dashboard</a>都是非常简单的设置,并为您提供至少90%的所有信息</li>
<li><p>经纪人支持。芹菜是明显的赢家,RQ只支持Redis。这意味着关于“什么是代理”的文档较少,但也意味着如果Redis不再适合您,您以后就不能切换代理。例如,<a href="https://blogs.vmware.com/vfabric/2013/04/how-instagram-feeds-work-celery-and-rabbitmq.html" rel="noreferrer">Instagram considered both Redis and RabbitMQ with Celery</a>。这一点很重要,因为不同的代理有不同的保证,例如Redis<em>无法</em>(从编写之日起)保证100%地传递消息。</p></li>
<li><p>优先队列。RQs优先级队列模型简单有效-<a href="http://python-rq.org/docs/workers/" rel="noreferrer">workers read from queues in order</a>。芹菜需要把多个工人从不同的队列中分出来食用。两种方法都有效</p></li>
<li><p>操作系统支持。芹菜显然是胜利者,因为RQ只在支持<code>fork</code>的系统上运行,例如Unix系统</p></li>
<li><p>语言支持。RQ只支持Python,而芹菜允许您将任务从一种语言发送到另一种语言</p></li>
<li><p>美国石油学会。芹菜是非常灵活的(多个结果后端,良好的配置格式,工作流程画布支持),但自然这个权力可以混淆。相比之下,RQ api很简单。</p></li>
<li><p>子任务支持。芹菜支持子任务(例如,从现有任务中创建新任务)。我不知道RQ是否有效</p></li>
<li><p>社区和稳定。芹菜可能更成熟,但它们都是积极的项目。撰写本文时,Celery在Github上拥有约3500颗星星,而RQ拥有约2000颗星星,两个项目都显示出了积极的发展</p></li>
</ul>
<p>在我看来,芹菜并不像它的名声能让你相信的那么复杂,但你必须相信它。</p>
<p>那么,为什么有人愿意用芹菜(可以说功能更全)来换取RQ呢?在我看来,一切都归结于简单。通过将自身限制为Redis+Unix,RQ提供了更简单的文档、更简单的代码库和更简单的API。这意味着您(以及项目的潜在贡献者)可以专注于您关心的代码,而不必在工作内存中保留有关任务队列系统的详细信息。我们都有一个限制,一次可以在我们的头脑中包含多少细节,并且通过消除在其中保留任务队列细节的需要,RQ让我们回到您关心的代码。这种简单性是以牺牲诸如跨语言任务队列、广泛的操作系统支持、100%可靠的消息保证以及轻松切换消息代理的能力等功能为代价的。</p>