Shashi 是 WMQ .Net 大师,所以我将按照他在 cmets 中的链接来了解 .Net 的具体答案。
架构的答案是你可能把这件事复杂化了太多。如果有问题的队列被通告到集群并且应用程序正在向它发送消息,那么应用程序只需要连接到集群中的任何 QMgr 并放入该队列。它可以动态创建一个回复队列并使用该句柄来指定请求消息的回复地址。理想情况下,服务请求者应用程序是远离目标队列的网络跃点,以便它们可以利用 WMQ 集群来实现您描述的目的。
有一个不太理想的场景,客户端连接到托管目标队列实例的 QMgr 实例之一。可以配置队列的CLWLUSEQ 属性,以便在本地和远程队列实例之间分发消息。
在应用发送请求消息的任何情况下,都可以向它提供一个CONNAME,其中包含一个可以连接的合格 QMgrs 的逗号分隔列表。现代版本的 WMQ 允许您使用 MQCONNX API 在 CONNAME 中指定多个连接点。当前和旧客户端都可以使用包含多个连接定义并允许客户端在它们之间切换的CCDT 文件。
如果应用在请求队列中侦听,情况就不同了。如果该应用程序是事务性的,则无法将其配置为故障转移到另一个 QMgr。这是因为 XA 事务只能在同一个 QMgr 实例上解析。但即使撇开事务问题不谈,您通常也不希望侦听请求的应用程序发生故障转移。这样做会使队列的本地实例得不到服务,并且消息会在那里堆积。更好的答案是运行服务器端应用程序的多个实例,以便每个队列实例至少有两个应用程序实例为其提供服务。这样一来,您就可以中断其中一个应用程序实例,而不会出现未提供服务的队列。同样,如果 QMgr 出现故障,消息会自动路由到集群中由其他应用程序实例提供服务的剩余队列实例。
还有许多其他架构原因适用于请求/回复场景并导致集群解决方案。其他注意事项适用于不同类型的消息传递,但一般来说,答案是肯定的,可以通过多种方式配置客户端以故障转移到另一个队列管理器。所有这些都是基于 QMgr 变得不可用,而不是队列本身。如果您尝试捕获的事件是队列已满或有人 PUT(DISABLE) 它,则最佳答案是检测和监控,第二好的答案是应用程序逻辑。