RabbitMQ：Celery 提供了 Pika 不提供的什么？答案

【问题标题】：RabbitMQ: What Does Celery Offer That Pika Doesn't?RabbitMQ：Celery 提供了 Pika 不提供的什么？
【发布时间】：2014-07-09 02:52:44
【问题描述】：

我一直致力于让一些分布式任务通过 RabbitMQ 工作。

我花了一些时间试图让 Celery 做我想做的事，但没能成功。

然后我尝试使用 Pika，结果一切正常，完美无缺，并且在几分钟内完成。

使用 Pika 代替 Celery 有什么遗漏的吗？

【问题讨论】：

您尝试过哪些无法上班的事情？您能否向我们展示代码或描述您尝试使用的分布式算法？

标签： python rabbitmq celery task-queue pika

【解决方案1】：

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

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

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

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

Celery 通过消息进行通信，通常使用代理进行调解客户和工人之间。为了启动一个任务，客户端放置一个队列中的消息，然后代理将消息传递给工人。

一个 Celery 系统可以由多个工人和经纪人组成，给实现高可用性和水平扩展的方法。

Celery 内置了一大堆超出 pika 范围的功能。您可以查看Celery docs 以了解它可以做什么，但这里有一个示例：

>>> 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 解决方案一起使用，则必须手动实施。

【讨论】：

【解决方案2】：

我将在这里添加一个答案，因为这是今天第二次有人根据我怀疑的这个答案在不需要的时候推荐芹菜。所以分布式任务队列和代理的区别在于代理只是传递消息。不多也不少。 Celery 建议使用 RabbitMQ 作为 IPC 的默认代理，并在该适配器之上使用守护进程管理任务/队列。虽然这对于您需要非常快速通用的分布式任务特别有用。它只是为发布者/消费者流程构建的。您定义了需要逐步完成的工作流程并根据您的特定需求确保消息持久性的实际任务，您最好编写自己的发布者/消费者而不是依赖 celery。显然你仍然需要做所有的持久性检查等。对于大多数与 web 相关的服务，一个不控制实际的“工作”单元，而是将它们传递给一个服务。因此，分布式任务队列几乎没有意义，除非您根据 IP/地理区域或帐号达到任意 API 调用限制......或类似的东西。因此，使用 celery 不会阻止您编写或处理状态代码或工作流管理等，并且它以一种使您可以轻松避免编写发布者/消费者代码结构的方式公开 AMQP。

因此，简而言之，如果您需要一个简单的任务队列来处理工作，并且您并不真正关心性能的细微差别、工作流程中持久性的复杂性或实际的发布/使用过程。芹菜的作品。如果您只是将消息传递给您实际上无法控制的 api 或服务，当然，您可以使用 Celery，但您也可以在几分钟内使用 Pika 轻松创建您自己的发布者/消费者。如果您需要一些健壮的东西或符合您自己的持久性方案，请像其他人一样编写您自己的发布/消费者代码。

【讨论】：