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

Question

我们最近遇到了由RabbitMQ支持的应用程序的意外行为。RabbitMQ版本为3.6.12，我们使用的是.NET客户端5.0.1

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

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

注我们注意到，当应用程序只订阅一个队列时，这个问题不会发生，当涉及多个队列时，这个问题就变成了一个问题。

下面的示例最好地说明了这一点：

>

我们有一个简单的消费应用程序，它订阅两个队列，一个用于命令，一个用于事件。这个应用程序有7个消费者，每个消费者都有自己的通道和EventingBasicConsumer我们启动一个简单的发布应用程序，每隔一秒发布20条消息。每条消息都是一个事件，因此会发布到事件队列中，但第5条和第10条消息除外，这两条消息是命令并发送到命令队列中。请注意，每个事件的处理都没有延迟，而命令需要30秒

因此，在我们看来，通道的分配是每个队列独立完成的--这意味着，如果某些消息需要很长时间来处理，您可能会延迟执行。

有没有可能，当多个消费者正在订阅多个队列时，RabbitMQ可以分配一条消息给一个忙的消费者处理，即使有当前空闲的消费者？

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

Answer 1

我们已经解决了这个问题。

在RMQ文档(https://www.rabbitmq.com/api-guide.html#consument)中，我们遇到了以下内容：“每个通道都有自己的分派线程。对于每个通道一个使用者的最常见用例，这意味着使用者不会阻止其他使用者。如果每个通道有多个使用者，请注意，长时间运行的使用者可能会阻止对该通道上其他使用者的回调分派。”

在我们的代码中，每个通道有2个消费者，这意味着消费者可以阻止其他消费者。我们改为每个渠道有一个消费者，这就解决了这个问题。