Websphere MQ集群

Question

我是websphere MQ的新手，所以如果我没有使用正确的条款，请原谅我。我们正在开展一个项目，我们需要为高可用性设置MQ集群。

客户端应用程序为订阅者和发布者维护与队列管理器的连接池。假设我们在托管具有相同名称的队列的集群中有两个队列管理器。每个队列都有自己的一组订阅者和发布者，这些订阅者和发布者由客户端应用程序缓存。假设其中一个队列管理器出现故障，该队列管理器上的队列的订户和发布者将死于使客户端应用程序上的对象无法使用。

在这种情况下，可以采取以下方案吗？

1]当第一个QueueManager崩溃时，其队列中的消息将被转移到集群中的其他队列管理器

2]当QueueManager再次出现时，是否有任何恢复发布者和订阅者的机制。目前，我们已在客户端应用程序中编写了一个自动恢复线程，该线程尝试重新连接失败的发布者和订阅者。但是在群集设置的情况下，我们担心发布者和订阅者将重新连接到另一个正在运行的qmanager。当崩溃的队列管理器恢复时，将不会有发布者和订阅者。

有人可以解释如何处理以上两种情况吗？

Answer 1

WMQ群集是一个高级主题。您必须首先对WMQ进行大量读取，并在尝试任何操作之前了解WMQ世界中的聚类。

WMQ群集在很多方面与传统群集有所不同。与传统集群不同，例如在主动/被动集群中，数据将在应用程序的主动和被动实例之间共享。在任何时间点，应用程序的活动实例都将处理数据。当活动实例关闭时，被动实例接管并开始处理。在WMQ集群中不是这种情况，其中集群中的队列管理器是唯一的，因此不共享由这些队列管理器托管的队列/主题。您可能在两个队列管理器中具有相同的队列/主题，但由于队列管理器不同，因此不会共享消息，主题，订阅等。

回答你的问题。
1）否。消息，如果持久，将保留在崩溃的队列管理器中。它们不会被转移到其他队列管理器。由于队列管理器本身不可用，因此在队列管理器启动之前无法执行任何操作 2）没有。队列管理员不能这样做。应用程序的职责是检查队列管理器的可用性并重新连接。 WMQ提供自动客户端重新连接功能，其中WMQ客户端库在检测到连接中断错误时自动重新连接到队列管理器。 WMQ v7.x及更高版本的C和Java客户端可以使用此功能。 C＃客户端支持v7.1中的功能。

对于高可用性要求，您可以查看使用WMQ的多实例队列管理器功能。此功能允许在两台不同的计算机上运行相同队列管理器的主动/被动实例。队列管理器的活动实例将处理客户端连接，而被动实例将处于睡眠模式。这两个实例都将共享数据和日志。活动实例关闭后，被动实例将变为活动状态。在活动队列管理器关闭之前，您将可以访问队列中的所有持久性消息。

阅读WMQ信息中心，了解有关多实例队列管理器的更多信息。

Answer 2

要添加Shashi的答案，要充分利用WMQ群集，您需要在消息的发送者和接收者之间建立网络跳跃。 WMQ聚类是关于QMgrs如何相互交谈的。它与客户端应用程序与QMgrs的通信方式无关，也不会复制消息。在消息必须从一个QMgr到另一个QMgr的集群中，集群会找出将其路由到何处的集群。如果单个目标队列有多个群集实例，则该消息可以路由到其中任何一个。如果发送者和接收者之间没有网络跳跃，则消息不需要离开本地QMgr，因此永远不会调用WMQ群集行为，即使所涉及的QMgrs可能参与群集。

在传统的WMQ集群架构中，接收器都监听同一队列的多个实例，这些实例具有相同的名称，分布在多个QMgrs上。发件人有一个或多个QMgrs，他们可以连接并发送请求（即发即忘），可能等待回复（请求 - 回复）。由于消息的接收者提供了一些服务，我称他们的QMgrs为“服务提供商QMgrs”。消息发送者所在的QMgrs是“服务消费者”QMgrs，因为这些应用程序是服务的消费者。

以下幻灯片来自我在WMQ Architecture咨询活动中使用的演示文稿。

请注意，服务的使用者 - 发送请求消息的内容 - 会进行故障转移。监听服务端点队列和提供服务的事情不会故障转移。这是因为需要确保始终提供每个活动服务端点队列。通常，每个应用程序实例都在两个或多个队列实例上保存输入句柄。这样，QMgr可以关闭，所有应用程序实例都保持活动状态。如果应用程序实例出现故障，其他一些应用程序实例将继续为其队列提供服务。服务提供商对特定QMgrs的这种亲和力还可以在需要时启用XA事务性。

我发现解释WMQ HA的最佳方式是来自IMPACT会议的幻灯片：

WebSphere MQ集群可确保服务保持可用，即使群集队列的实例可能不可用。群集中的新消息将路由到其余的队列实例。硬件集群或多实例QMgr（MIQM）提供对现有消息的访问。当主动/被动对的一侧发生故障时，在发生故障转移时，仅在QMgr 上发生短暂的中断，然后辅助节点接管并使队列上的任何消息再次可用。结合WMQ群集和硬件群集/ MIQM的网络提供最高级别的可用性。

请记住，这些配置都不是跨节点复制的消息。 WMQ消息始终具有单个物理位置。有关此方面的更多信息，请参阅Thoughts on Disaster Recovery。