我们正在使用 IBM MQ，并且在控制其向接收者的异步传递方面遇到了一些严重问题。我们配置了一些 java 侦听器，现在问题是我们需要控制到达侦听器的消息，因为消息进入服务器的数量以百万计，服务器机器没有那么多容量一次处理这么多线程，那么有没有什么方法可以像在 IBM MQ 端进行节流一样，我们可以像 Apache MQ 那样配置 preetch 限制？
或者有没有其他方法可以做到这一点？
目前，当侦听器达到某个 X 限制时，我们正在关闭与 IBM MQ 的连接，但这似乎不是一种有效的方式。
请大家帮我们解决这个问题。
【问题讨论】：
通常使用像 MQ 这样的消息队列技术，队列的重点是发送者与接收者分离。如果您在处理消息量时遇到问题，那么答案是让它们在接收者队列中排队并尽可能地处理它们，而不是限制发送者。
显而易见的答案是限制允许侦听器占用的最大线程数。我假设您正在使用某种 MQ 线程池？您正在使用哪个平台提供无限的侦听器线程？
根据您的描述，听起来您似乎有一些进程正在运行——一旦它检测到队列中的消息——它就会读取消息，启动一个新线程并返回并再次查看队列。这是错误的方法。
您应该有一个定义数量的进程线程正在运行（从一个开始并根据需要扩展，并且在您的服务器的限制范围内）从队列本身读取。如果您获得 MQRC 2033（队列中没有消息），它们将各自以共享模式打开队列，然后等待获取或立即获取睡眠。
希望对您有所帮助。
【讨论】：
如果您在应用程序服务器环境中运行，则 activationSpec 上的 maxPoolDepth 属性将定义 MDB 的最大 ServerSessionPool 大小 - 减小这将限制同时传递的消息数量。
当然，如果您的 MDB（或 JSE 环境中的 javax.jms.MessageListener）什么都不做，只是将消息交给其他东西（或者，更糟糕的是，只是生成一个非托管线程并启动它），onMessage 将快速旋转，而您仍然会遇到问题。因此，在这种情况下，您也需要限制其他资源，例如通过线程池配置。
关闭与 QM 的连接从来都不是一种有效的方法，因为 MQCONN/MQDISC 周期很昂贵。
【讨论】：