我们有一个IBM MQ v8安装程序设置，其中包含1个高容量非持久性队列和该队列上的许多使用者（50+）。需要大量的消费者才能处理队列中发布的消息量。
我们现在注意到，队列管理器没有在X个消费者上均匀地分发消息。一些消费者每分钟获得多达300条消息，而许多其他消费者每分钟只获得几条消息（<10）。并且，队列中有许多消息，并且队列深度正在稳步增加。消费者方面的CPU和内存不是问题，两者的利用率都是＆lt; 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)
我们如何才能获得更多的消息消费性能？例如，如果在一个容器中我们连接到队列管理器一次然后让多个线程使用相同的队列管理器连接到队列并获取消息，它会帮助吗？或者我们是否应该在多个线程上重用队列？
此致
格罗
答案 0 :(得分：2)
MQ的默认行为是向MOST RECENT getter发送消息。这通常会提高性能，因为该过程最有可能是“热”＆＃34; （在处理器缓存中）。所以你不应该期望消息的平等分配。如果您看到一个应用程序获取大多数消息，这意味着它经常处理一个消息，然后另一个消息可用于检索。在下一条消息可用之前，它将重新加入服务员队列。
影响整体性能的方面有很多，包括事务性，检索标准，争用等等，因此无法确定您的问题是什么，或者是否更改了默认分发算法（还有一个未记录的调优参数扭转服务员的队列）会有所帮助。并且拥有客户端连接，其中等待实际上是由＆＃34;代理＆＃34; svrconn进程和线程使它更复杂。