我们有一个 IBM MQ v8 设置设置，其中包含 1 个高容量非持久队列和该队列上的许多使用者 (50+(。需要大量的使用者才能处理队列上发布的消息量。
我们现在注意到的是，队列管理器没有将消息均匀地分布在 X 使用者上。少数使用者每分钟最多收到 300 条消息，而许多其他使用者每分钟仅收到几条消息 (<10(。而且，队列中有许多消息，队列深度正在稳步增加。消费者端的CPU和内存不是问题，两者的利用率<50%。
有人可以解释一下 IBM MQ 队列管理器如何在多个使用者之间分发消息吗？是否有可能在服务器端或消费者端对此产生影响，以便消息更均匀地分布在可用的消费者上？
在马克·泰勒回应后添加
我们面临的挑战是，每分钟有>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)
如何实现更高的消息消费性能？例如，如果在一个容器中我们连接到队列管理器一次，然后让多个线程使用相同的队列管理器连接到队列并获取消息，这会有所帮助吗？或者我们甚至应该在多个线程上重用队列？
问候
下吕
MQ 的默认行为是向最新的获取者提供消息。这通常会提高性能，因为该进程最有可能是"热"的(在处理器缓存中(。因此，您不应该期望消息的均匀分布。如果您看到一个应用程序获取了大多数消息，这意味着它正在定期处理一条消息，然后再处理另一条消息以供检索。在下一条消息可用之前，它将重新加入服务员队列。
影响整体性能的方面有很多，包括事务性、检索标准、争用等，所以实际上不可能说出你的问题是什么，或者改变默认分配算法(有一个未记录的调优参数可以逆转服务员队列(会有所帮助。并且，在等待实际上由"代理"svrconn 进程和线程完成的客户端连接中，使其更加复杂。