IBM MQ QM 如何在多个消费者之间分发消息

Question

我们有一个 IBM MQ v8 设置，其中包含 1 个大容量非持久队列和该队列上的许多使用者（50 多个）。需要大量消费者才能处理在队列上发布的大量消息。

我们现在注意到的是，队列管理器没有将消息均匀地分配给 X 个使用者。少数消费者每分钟最多收到 300 条消息，而许多其他消费者每分钟只能收到几条消息 (<10)。并且，队列上有很多消息，队列深度在稳步增加。消费端的 CPU 和内存都不是问题，两者的利用率都小于 50%。

有人可以解释 IBM MQ 队列管理器如何在多个消费者之间分发消息吗？是否有可能在服务器或消费者端影响这一点，以便消息在可用消费者上更均匀地分布？

在 Mark Taylors 回应后添加

我们面临的挑战是每分钟有超过 10.000 条消息添加到队列中，我们无法足够快地使用它们。我们当前的设置是我们有一个在 Docker 容器中运行的简单使用者，我们通过运行多个容器进行扩展。运行 12 个消费者（Docker 容器）确实会增加整体吞吐量，运行 50 多个消费者不会增加任何吞吐量。每个消费者都很简单：

1. connect to queue manager
2. Connect to queue
3. While true
   - Get message from queue
   - Process message (commenting this out does not increase overall performance)

我们怎样才能获得更多的消息消费性能？例如，如果在一个容器中我们连接到队列管理器一次，然后让多个线程使用同一个队列管理器连接到队列并获取消息，这会有所帮助吗？或者我们甚至应该在多个线程上重用队列？

问候，

下吕

Answer 1

MQ 的默认行为是向 MOST RECENT getter 提供消息。这通常会提高性能，因为该进程最有可能是“热的”（在处理器缓存中）。所以你不应该期望消息的平均分配。如果您看到一个应用程序获得了最多的消息，这意味着它在另一条消息可用于检索之前定期处理一条消息。它在下一条消息可用之前重新加入等待队列。

有许多方面会影响整体性能，包括事务性、检索标准、争用等，因此实际上不可能说出您的问题是什么，或者更改该默认分发算法（有一个未记录的调整参数可以反转服务员队列）是否会帮助。并且在等待真正由“代理” svrconn 进程和线程完成的客户端连接使其变得更加复杂。