Ibm mq IBM MQ QM如何在多个使用者上分发消息

我们有一个IBM MQ v8安装程序，其中有一个高容量非持久性队列和该队列上的许多使用者（50+）。需要大量使用者才能处理队列上发布的消息量

我们现在注意到的是，队列管理器没有在X消费者上均匀地分布消息。少数消费者每分钟最多收到300条消息，而许多其他消费者每分钟只收到几条消息（每分钟向队列添加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)

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

问候,

---

Gero

MQ的默认行为是将消息传递给最新的getter。这通常会提高性能，因为该进程很可能是“热的”（在处理器缓存中）。因此，您不应该期望消息的分布是相等的。如果您看到一个应用程序获得的消息最多，这意味着它在可以检索另一条消息之前定期处理一条消息。它是在下一条消息可用之前重新加入等待者队列

---

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

感谢您的解释。我添加了更多的细节，希望您能解释如何最好地扩大消息的使用吞吐量。您确定消息都是非持久性的吗？您声明为“非持久性队列”，但队列级别设置DEFPSIST只是一个默认值，消息的持久性是由应用程序在放置时确定的。当消息通过后续队列时，它不能更改。应用程序在放置时确实有很多选择：1.持久性，2.非持久性，3.使用队列默认持久性，4.在这种情况下，根本不指定任何内容行为与指定了#3时相同。如果将永久性消息放在syncpoint之外，则队列上可能存在锁争用，这可能会导致使用者行为缓慢，这就是为什么我询问您是否确定它们确实是非永久性的。我检查了从队列接收的消息的属性，并且消息不是永久性的（永久性：0）您使用什么API来访问MQ，例如：MQI、JMS等？您的应用程序是多线程的吗？如果是，每个容器中消耗了多少线程？一个可能的改进是在您连接到的

SVRCONN

通道上设置

SHARECNV（1）

，或者对客户端进行等效更改。