java - 当消费者从rabbitmq中的 channel 获取消息时，预取消息驻留在哪里

Question

我有以下rabbitmq配置

预取次数:1确认模式:自动。

我有一个交换器，一个队列附加到该交换器，一个消费者附加到该队列。根据我的理解，如果队列有多个消息，将会发生以下步骤。

1. 在 channel 上对写入数据进行排队。
2. 由于 ack-mode 为自动，一旦队列在 channel 上写入消息，消息就会从队列中删除。
3. 消息到达消费者，消费者开始对该数据执行操作。
4. 由于队列已收到上一条消息的确认。队列在 channel 上写入下一个数据。

现在，我的疑问是，假设消费者还没有完成之前的数据。下一个数据队列写入 channel 后会发生什么？

此外，假设 prefetchCount 为 10，并且我只有一个消费者附加到队列，这 10 条消息将驻留在哪里？

Answer 1

您所描述的场景是 RabbitMQ 文档中提到的场景，并在 this blog post 中进行了详细说明。 。具体来说，如果您设置足够大的预取计数，并且发布速率相对较小，那么您的 RabbitMQ 服务器就会变成一个奇特的网络交换机。当确认模式设置为自动时，预取限制实际上被禁用，因为永远不会有未确认的消息。通过自动确认，消息一送达就会得到确认。这与具有任意大的预取计数相同。

预取 >1 时，消息将存储在客户端库的缓冲区内。确切的数据结构取决于所使用的客户端库，但据我所知，所有实现都将消息存储在 RAM 中。此外，通过自动确认，您无法知道特定消费者何时实际读取并处理消息。

因此，这里有一些要点:

1. 预取限制与自动确认无关，因为永远不会有任何未确认的消息，因此
2. 使用消费者时自动确认没有多大意义
3. 当自动确认关闭或任何使用 autoack = on 时，足够大的预取将导致消息代理不执行任何排队，而仅执行路由。

现在，这里有一些专家的意见。我发现消息代理“推送”消息的整个概念有点倒退，正是因为这个原因 - 很难正确配置，并且不清楚好处是什么。队列系统非常适合基于拉动的系统。当处理完当前消息后，处理器可以向代理询问下一条消息。这种方法将确保负载自然平衡，并且当处理器断开连接或被淘汰时消息不会丢失。

因此，我的建议是完全放弃消费者的使用，转而使用 basic.get .