【问题标题】:When consumer gets message from channel in rabbitmq,where does pre-fetch messages reside当消费者从rabbitmq中的通道获取消息时,预取消息驻留在哪里
【发布时间】:2017-11-16 14:36:30
【问题描述】:

我有下面的 rabbitmq 配置

prefetchCount:1 确认模式:自动。

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

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

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

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

【问题讨论】:

    标签: java architecture callback rabbitmq system-design


    【解决方案1】:

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

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

    所以,这里有一些要点:

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

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

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

    【讨论】:

    • 很好的答案,清除了很多疑惑,将切换到pull。还有一件事,在我们当前的项目中,我们有以下场景,假设在队列中的任何时候我们都有如下A-> B的记录->C,并且记录C只能处理A已经处理。这个实现会一样吗?在消费者端处理一条记录时,如果我们发现它的前任尚未处理,我们再次将记录入队(而不是发送-nack,将通过交换将其入队)。这将使我们的队列记录为C->A->B,现在C将在A之后处理。
    • 感谢夸奖!如果您还有其他问题,我建议您将其作为新问题发布,以便更容易获得答案。我将评论说,所描述的场景对于单独的消息传递似乎有点令人费解。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-07-11
    • 1970-01-01
    • 1970-01-01
    • 2020-04-20
    • 1970-01-01
    • 2017-07-31
    • 1970-01-01
    相关资源
    最近更新 更多