我有以下 rabbitmq 的配置
预取计数：1 确认模式：自动
我有一个交易所，一个队列附加到该交易所，一个消费者附加到该队列。根据我的理解，如果队列有多个消息，将发生以下步骤。
- 在通道上排队写入数据。
- 由于 ack 模式是自动的，一旦队列在通道上写入消息，消息就会从队列中删除。
- 消息传给消费者，消费者开始对该数据执行。
- 由于队列已获得上一条消息的确认。队列在通道上写入下一个数据。
现在，我的疑问是，假设消费者还没有完成以前的数据。下一个数据队列写入通道会发生什么？
另外，假设预取计数是 10，而我只有一个消费者附加到队列，这 10 条消息将驻留在何处？
您描述的场景是 RabbitMQ 文档中提到的场景，并在此博客文章中进行了详细说明。 具体来说，如果您设置了足够大的预取计数，并且发布速率相对较低，那么您的 RabbitMQ 服务器就会变成一个花哨的网络交换机。当确认模式设置为自动时，预取限制将有效禁用，因为永远不会有未确认的消息。通过自动确认，消息在传递后立即得到确认。这与具有任意大的预取计数相同。
使用预取>1，消息存储在客户端库的缓冲区中。确切的数据结构将取决于所使用的客户端库，但据我所知，所有实现都将消息存储在 RAM 中。此外，通过自动确认，您无法知道特定消费者何时实际阅读和处理消息。
因此，这里有一些要点：
- 预取限制与自动确认无关，因为永远不会有任何未确认的消息，因此
- 使用使用者时，自动确认没有多大意义 当
- 自动确认关闭时，足够大的预取，或者任何使用 autoack = on 都会导致消息代理不执行任何队列，而只执行路由。
现在，这里有一点专家意见。我发现"推送"消息的消息代理的整个概念有点倒退，正是由于这个原因 - 很难正确配置，并且不清楚有什么好处。队列系统非常适合基于拉动的系统。处理器可以在处理完当前消息后向代理请求下一条消息。这种方法将确保负载自然平衡，并且在处理器断开连接或被淘汰时消息不会丢失。
因此，我的建议是完全放弃使用消费者，转而使用basic.get。