问跨多个队列的RabbitMQ多个使用者-被处理的消息延迟

EN

我们最近经历了由RabbitMQ驱动的应用程序的意外行为。RabbitMQ版本为3.6.12，我们使用的是.NET客户端5.0.1

应用程序订阅两个队列，一个用于命令，另一个用于事件--我们还使用手动确认。我们的应用程序被配置为有7个使用者。每个通道都有自己的通道(IModel)，每个通道都有自己的EventingBasicConsumer，当EventingBasicConsumer.Received被触发时，我们最终会处理消息。

当消息被路由到队列时，我们的应用程序必须处理尽可能接近的消息，到目前为止，我们还没有遇到问题。然而，最近我们已经看到，当我们正在处理的一条消息需要很长时间才能完成时，当另一条消息被处理时，它会延迟，尽管有许多可用的用户(6)并不忙。

注意，当应用程序只订阅单个队列时，这个问题不会发生，当涉及多个队列时，它就会成为一个问题。

最好用以下示例说明这一点：

• 我们有一个简单的消费应用程序，它订阅两个队列，一个用于命令，另一个用于事件。这个应用程序有7个使用者，每个用户都有自己的频道和EventingBasicConsumer，我们启动了一个简单的发布应用程序，该应用程序发布20条消息，间隔1秒钟。除第5条和第10条消息外，每条消息都是一个事件，因此被发布到事件队列，这些消息是命令并发送到命令队列。请注意，每个事件都是毫不延迟地处理的，而命令则需要30秒。
• 下表描述了我们在为跨多个队列的消息分配多个通道方面所观察到的情况：

​

​

• 一旦Message5用C1在30秒后完成，那么Messaqe9立即被分配给C1，并且在Message10与C2一起完成30秒后立即被处理，然后Messaqe11被立即分配给C2，并被立即处理。
• 因此，在我们看来，通道的分配似乎是独立于每个队列完成的--这意味着如果某些消息需要很长时间处理，您就可以延迟执行。

当多个消费者订阅多个队列时，RabbitMQ是否可以分配一条消息，以便在当前空闲的消费者的情况下由繁忙的使用者处理？

是否有任何文档解释了RabbitMQ算法，该算法从消费者集合中选择哪些消费者EventingBasicConsumer.received？