为什么使用 Celery 而不是 RabbitMQ?
问题描述
据我了解，Celery 是一个分布式任务队列，这意味着它唯一应该做的就是将任务/作业分派到其他服务器并取回结果.RabbitMQ 是一个消息队列，仅此而已.但是，worker 可以只监听 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?
解决方案
你是对的，你根本不需要 Celery.当你设计一个分布式系统时，有很多选择，没有适合所有情况的正确方法.
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.
相关文章