拉比马克：芹菜有什么比比萨更好吃的呢？

Question

我一直在通过RabbitMQ实现一些分布式任务。

我花了一些时间想让芹菜做我想做的事，但没能成功。

然后我试着用皮卡，一切都很好，完美无瑕，几分钟内就完成了。

用比萨代替芹菜有什么我遗漏的吗？

Answer 1

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

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

Task queues are used as a mechanism to distribute work across threads or machines.

A task queue’s input is a unit of work, called a task, dedicated worker processes then constantly monitor the queue for new work to perform.

Celery communicates via messages, usually using a broker to mediate between clients and workers. To initiate a task a client puts a message on the queue, the broker then delivers the message to a worker.

A Celery system can consist of multiple workers and brokers, giving way to high availability and horizontal scaling.

芹菜有一大堆功能内置在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在range(0, 100)和y在range(0,100)中的每个x+y。它通过执行一个名为add（添加两个数字）的任务，将添加1+1、2+2、3+3等的工作分配到10个块中，并将每个块分配给尽可能多的芹菜工人。每个工作进程将对其10个项目块运行add，直到所有工作完成。然后通过res.get()调用收集结果。我相信你可以想象一种使用pika的方法，但我相信你也可以想象需要做多少工作。你可以用芹菜来实现这个功能。

如果需要的话，您当然可以使用pika来实现分布式任务队列，特别是如果您有一个相当简单的用例。芹菜只是为任务调度、管理等提供了一个“包含电池”的解决方案，如果您决定使用pika解决方案，则必须手动实现。

Answer 2

我要在这里补充一个答案，因为这是今天第二次有人推荐芹菜时不需要根据这个答案我怀疑。因此，分布式任务队列和代理之间的区别在于，代理只传递消息。没有更多，没有更少。芹菜建议使用RabbitMQ作为IPC的默认代理，并将其放在适配器的顶部，以便使用守护进程管理任务/队列。虽然这对于分布式任务特别有用，因为在分布式任务中，您很快就需要一些通用的东西。它只是为发布者/消费者流程构建的。在实际任务中，如果您定义了需要逐步完成的工作流，并根据您的特定需要确保消息的持久性，那么最好编写自己的发布者/消费者，而不是依赖芹菜。显然，你仍然需要做所有的耐久性检查等。对于大多数与web相关的服务，一个并不控制实际的“工作”单元，而是把它们传递给一个服务。因此，除非您基于ip/地理区域或帐号达到某个任意的API调用限制，否则对于分布式任务队列几乎没有意义。。。或者类似的东西。因此，使用芹菜并不能阻止您编写或处理状态代码或工作流管理等，它以一种便于您避免编写发布者/消费者代码结构的方式公开AMQP。

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