1

我有以下 rabbitmq 的配置

prefetchCount：1 确认模式：自动。

我有一个交换器，一个队列连接到该交换器，一个消费者连接到该队列。根据我的理解，如果队列有多条消息，将执行以下步骤。

  1. 在通道上排队写入数据。
  2. 由于 ack-mode 是自动的，一旦队列在通道上写入消息，消息就会从队列中删除。
  3. 消息到达消费者，消费者开始对该数据执行。
  4. 由于 Queue 已获得对先前消息的确认。Queue 将下一个数据写入 Channel。

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

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

4

1 回答 1

2

您描述的场景是 RabbitMQ 文档中提到的场景，并在此博客文章中进行了详细说明。具体来说，如果您设置了足够大的预取计数，并且发布率相对较小，那么您的 RabbitMQ 服务器就会变成一个花哨的网络交换机。当确认模式设置为自动时，有效地禁用了预取限制，因为从来没有未确认的消息。使用自动确认，消息一经发送即被确认。这与具有任意大的预取计数相同。

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

因此，这里有一些要点：

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

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

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

于 2017-06-14T19:14:07.927 回答