RabbitMQ：Celery提供了什么，Pika没有的？

Question

我一直在努力通过RabbitMQ使一些分布式任务得以运行。

我花了一些时间尝试让Celery完成我想做的事情，但无法使其工作。

然后我尝试使用Pika，事情就顺畅地在几分钟内解决了。

如果使用Pika而不是Celery，是否会有什么遗漏呢？

- Jason Champion

---

你曾经尝试过什么却无法让它运作起来？你能展示给我们代码，或者描述一下你试图使用的分布式算法吗？ - wheaties

Answer 1

Pika提供的仅是Celery所做工作的一小部分。Pika是Python库，用于与RabbitMQ交互。RabbitMQ是一个消息代理；在其核心，它只是将消息发送到/从队列中接收消息。它可以用作任务队列，但也可以仅用于在进程之间传递消息，而不实际分发“工作”。

Celery实现了分布式任务队列，可选择使用RabbitMQ作为IPC代理。它不仅提供了在进程之间发送消息的方式，还提供了在进程之间分配实际任务/作业的系统。以下是Celery网站对其描述的方式：

任务队列用作机制以跨线程或机器分发工作。

任务队列的输入是称为任务的工作单元，专用工作进程随后不断监视队列以执行新工作。

Celery通过消息进行通信，通常使用代理来调解客户端和工作进程之间的关系。要启动任务，客户端将消息放入队列中，代理然后将消息传递给工作进程。

Celery系统可以由多个工作进程和代理组成，从而实现高可用性和水平扩展。

Celery内置了许多功能，超出了pika的范围。您可以查看Celery文档以了解其可以执行的操作类型，这里是一个示例：

>>> from proj.tasks import add

>>> res = add.chunks(zip(range(100), range(100)), 10)()
>>> res.get()
[[0, 2, 4, 6, 8, 10, 12, 14, 16, 18],
 [20, 22, 24, 26, 28, 30, 32, 34, 36, 38],
 [40, 42, 44, 46, 48, 50, 52, 54, 56, 58],
 [60, 62, 64, 66, 68, 70, 72, 74, 76, 78],
 [80, 82, 84, 86, 88, 90, 92, 94, 96, 98],
 [100, 102, 104, 106, 108, 110, 112, 114, 116, 118],
 [120, 122, 124, 126, 128, 130, 132, 134, 136, 138],
 [140, 142, 144, 146, 148, 150, 152, 154, 156, 158],
 [160, 162, 164, 166, 168, 170, 172, 174, 176, 178],
 [180, 182, 184, 186, 188, 190, 192, 194, 196, 198]]

这段代码想要将所有x+y（其中x在range(0, 100)，y在range(0,100)）相加。它通过使用一个名为add的任务来实现，该任务将两个数字相加，并将1+1、2+2、3+3等的相加工作分成10个一组，并将每个组分配给可用的Celery工作进程。每个工作进程将在其10个项目块上运行add，直到完成所有工作。然后通过res.get()调用收集结果。我相信您可以想象出使用pika进行此操作的方法，但我也相信您可以想象出需要多少工作量。您可以通过使用Celery获得这些功能。

如果您愿意，当然可以使用pika实现分布式任务队列，特别是如果您有一个相当简单的用例。 Celery只是提供了一个“带电池”的解决方案，用于任务调度、管理等，如果您决定在pika解决方案中使用它们，则必须手动实现它们。

- dano

Answer 2

我会在这里添加一个答案，因为今天有人已经根据这个答案推荐了两次不必要的celery。分布式任务队列和broker之间的区别在于，broker只是传递消息，没有更多也没有更少。Celery建议使用RabbitMQ作为IPC的默认broker，并在此基础上放置适配器以管理任务/队列和守护进程。尽管这对于需要快速得到通用解决方案的分布式任务非常有用，但它只是发布者和消费者进程的构造。实际上，在具有定义的工作流程并且需要根据特定需求确保消息可靠性的实际任务中，您最好编写自己的发布者/消费者而不是依赖于celery。显然，您仍然需要执行所有耐久性检查等操作。

在大多数与Web相关的服务中，人们不能控制实际的“工作”单元，而是将它们传递给服务。因此，除非您达到一些基于ip /地理区域或账户号码的任意API调用限制，否则使用分布式任务队列就没有多少意义。因此，使用celery并不能免除您编写或处理状态代码或工作流程管理等问题，并且它以一种方式公开了AMQP，使您可以轻松避免编写发布者/消费者代码的构造。

简而言之，如果您需要一个简单的任务队列来处理工作，并且您并不真正关心性能的细微差别、工作流程的耐久性或实际的发布/消费过程，那么Celery适用。如果您只是将消息传递到您没有实际控制的API或服务中，当然，您可以使用Celery，但是您也可以在几分钟内轻松使用Pika创建自己的发布者/消费者。如果您需要内容强大且符合您自己的耐久性方案，请像其他人一样编写自己的发布/消费者代码。

- Christopher Warner at mdsol