为什么用芹菜代替RabbitMQ? [英] Why use Celery instead of RabbitMQ?

问题描述

据我了解，Celery是一个分布式任务队列，这意味着它唯一要做的就是将任务/作业分派到其他服务器并返回结果. RabbitMQ是一个消息队列，仅此而已.但是，当收到消息时，工作人员可以只听MQ并执行任务.这恰好实现了Celery所提供的功能，那么为什么根本需要Celery?

From my understanding, Celery is a distributed task queue, which means the only thing that it should do is dispatching tasks/jobs to others servers and get the result back. RabbitMQ is a message queue, and nothing more. However, a worker could just listen to the MQ and execute the task when a message is received. This achieves exactly what Celery offers, so why need Celery at all?

推荐答案

是的，您根本不需要芹菜.在设计分布式系统时，有很多选择，并且没有正确的方法来做适合所有情况的事情.

You are right, you don't need Celery at all. When you are designing a distributed system there are a lot of options and there is no right way to do things that fits all situations.

许多人发现，让消息使用者池等待消息出现在其队列中，进行一些工作并在工作完成后发送消息更为灵活.

Many people find that it is more flexible to have pools of message consumers waiting for a message to appear on their queue, doing some work, and sending a message when the work is finished.

Celery是一个框架，可以将很多东西包装在一个程序包中，但是如果您真的不需要整个程序包，那么最好设置RabbitMQ并实现您所需要的功能而没有所有复杂性.此外，除了Celery实施的任务队列方案之外，RabbitMQ还可用于更多方案.

Celery is a framework that wraps up a whole lot of things in a package but if you don't really need the whole package, then it is better to set up RabbitMQ and implement just what you need without all the complexity. In addition, RabbitMQ can be used in many more scenarios besides the task queue scenario that Celery implements.

但是，如果您选择Celery，请再三考虑RabbitMQ. Celery的消息队列模型非常简单，对于Redis这样的东西，它确实比RabbitMQ更适合. Rabbit拥有Celery基本上会忽略的丰富选项.

But if you do choose Celery, then think twice about RabbitMQ. Celery's message queueing model is simplistic and it is really a better fit for something like Redis than for RabbitMQ. Rabbit has a rich set of options that Celery basically ignores.

这篇关于为什么用芹菜代替RabbitMQ?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！