我目前正在从事一个项目，我需要与 IBM 系统进行交互，该系统通过 WebSphere MQ 与外部世界进行通信。我需要使用队列以“请求-响应”方式查询系统，我将通过队列管理器执行此操作。
但是，我不太清楚这在实际中是如何工作的。
假设我有同一个应用程序的多个实例，它们将一条消息放入请求队列。消息得到一个 CorrelationId和 MessageId离开应用程序时，还有一个 ReplyToQueue在每条消息上设置属性以确保队列管理器知道将响应放入哪个队列。
但是，队列管理器是如何操作响应队列的呢？关于响应的时间没有保证，那么正确的响应是如何返回到发出相应请求的应用程序实例的呢？
我一直认为消息队列是一个 FIFO 队列，其中的消息必须一一选择。但是，这意味着实例 A 可以选择对实例 B 的响应。显然，这不可能是它的工作方式。
然后，当我查看 API ( com.ibm.mq.MQQueue ) 时，我看到要选择一条消息，我有机会提供 CorrelationId和 MessageId的请求消息。这是否意味着当我向队列管理器查询消息(设置了这些 ID)时，队列管理器会遍历队列中的消息并返回匹配的消息？另一方面，这是否意味着我们不是在谈论 FIFO 队列？
最佳答案
通常的做法是使用 CorrelationId 关联请求和响应消息。它是这样工作的:
1) 假设有两个队列，一个 REQQ - 请求队列，其中放置消息请求另一个应用程序、服务应用程序接收和处理，以及一个 RESPQ，服务应用程序向其发送回复。
2) 请求者应用程序(我们称其为 REQAPP)将请求消息 (REQMSG) 放入请求队列 (REQQ)。在发送消息之前，REQAPP 将消息的 ReplyToQ 属性设置为 RESPQ。发送请求消息时，JMS 提供程序使用唯一的 MessageId 更新发送的消息。请求者应用程序缓存这个唯一的 MessageId 以备后用。
3) 在世界的另一端，服务应用程序从 REQQ 检索 REQMSG，从该消息读取 MessageId 和 ReplyToQ 属性，处理请求并准备适当的响应消息 RESPMSG。然后，它将 RESPMSG 的 CorrelationId 属性设置为从 REQMSG 读取的 MessageId，并将回复放入 ReplyToQ。
4) 请求者应用程序在阅读回复时，使用缓存的 MessageId 并设置如下选择标准来阅读回复消息
GET MESSAGE FROM RESPQ WHERE RESPMSG.CORRELATIONID==REQMSG.MESSAGEID
此选择标准确保检索到正确的响应消息。这里的关键是服务应用程序必须将响应消息上的 CorrelationId 设置为请求消息的 MessageId。
尽管 Queue 是 FIFO 类型，但 MQ 实现提供了基于优先级的消息传递，即首先传递具有高优先级的消息，或者优先传递队列顶部的消息的 FIFO 基础。也可以使用选择标准检索消息，如上例所述。
希望这有帮助
关于jms - IBM WebSphere MQ 请求/回复场景，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23342116/