借助Rabbitmq作为经纪人，芹菜工作者是否可以使用push api或pull api？

Question

从Rabbitmq文档here中了解消费者，发现消费者有两种可能的方式来处理消息：

  

将消息存储在队列中是没有用的，除非应用程序可以使用   他们。在AMQP 0-9-1模型中，应用程序有两种方法可以   做到这一点：

Have messages delivered to them ("push API")
Fetch messages as needed ("pull API")

     

使用“推送API”时，应用程序必须表明对   消耗来自特定队列的消息。当他们这样做时，我们说   他们注册了消费者，或者简单地说，订阅了队列。

我只是想知道：

1. 芹菜工作者以哪种方式工作？
2. 是否可以选择/更改方式？

在Celery文档中找不到与此相关的任何特定内容。

Answer 1

1. Celery 使用推送方法，基于这样一个事实，它将消费者注册到队列，并维护与代理的长期连接。
2. 不，据我所知，Celery 的设计中从未真正适应 pull 方法。

RabbitMQ doc has been updated（在提出这个问题之后）指出推送方法是强烈推荐的选项，并且拉/轮询方法“效率非常低，在大多数情况下应该避免”。在 related doc 中，它说：

<块引用>

一条一条地获取消息非常不鼓励，因为与普通的长期消费者相比，它效率很低。与任何基于轮询的算法一样，在消息发布是零星的且队列可能长时间保持为空的系统中，它将极度浪费。

当不需要实时任务/消息时，这种关于极度浪费的说法可能不成立，这样队列就可以以数小时甚至更短的时间间隔轮询和排空，尽管像 Celery/RabbitMQ 这样的解决方案对于此类用例来说可能是过度的。

我快速（且有限地）浏览了 Celery 的源代码，我可以说，其架构的很大一部分似乎只是假设正在使用 push 方法。有一些复杂的组件，比如心跳机制，可以在长时间运行和不可避免的网络故障的情况下使系统更加健壮；在拉/轮询模式下根本不需要这些组件。