我正在尝试配置连接到集群 MQ 的集群 websphere 应用程序服务器。
但是，我所掌握的信息是属于同一 MQ 集群名称的具有不同主机名、服务器通道和队列管理器的两个 MQ 实例的详细信息。
在 websphere 控制台上，我可以看到主机名、队列管理器和服务器通道的输入字段，我找不到可以指定多个 MQ 详细信息的任何内容。
如果我选择 MQ 详细信息之一，MQ 集群仍然有效吗？如果没有，根据我的详细信息，我将如何启用 MQ 集群？
【问题讨论】：
WebSphere MQ 集群会影响队列管理器之间的对话行为。它确实不会改变应用程序连接或与队列管理器对话的方式，因此所提出的问题似乎是假设某种 WMQ 中不存在的集群行为。
要使用两个地址设置应用服务器，请参阅 WAS v7 知识中心中的 Configuring multi-instance queue manager connections with WebSphere MQ messaging provider custom properties，了解有关如何使用多实例 CONNAME 值配置连接工厂的说明。
如果您在连接工厂中指定了有效的 QMgr 名称，而应用程序连接到的 QMgr 没有该特定名称，则连接将被拒绝。通常使用多实例CONNAME 连接到多实例QMgr。这是一个高度可用的队列管理器，它可以位于两个不同的 IP 地址之一，因此在这种情况下使用真正的 QMgr 名称是可行的。但是，如果您的应用程序连接到的 QMgrs 是两个不同且名称不同的队列管理器，正如您所描述的，您应该指定一个星号（* 字符）作为连接工厂中的队列管理器名称，如所述 @ 987654322@。这样应用程序在获得连接时就不会检查 QMgr 的名称。
如果我选择 MQ 详细信息之一，MQ 集群仍然有效吗？如果不， 鉴于我的详细信息，我将如何启用 MQ 集群？
取决于您所说的“集群”是什么意思。如果您认为应用程序将看到一个由两个队列管理器托管的逻辑队列，那么不会。这不是 WMQ 集群的工作方式。每个托管集群队列的队列管理器都会获取发送到该队列的消息子集。因此，从该队列获取的任何应用程序都只会看到本地子集。
但是，如果您打算通过“集群”交替连接到两个队列管理器中的一个或另一个，并将消息传输到同一集群中但不在您连接的两个 QMgrs 中的任何一个上托管的队列，那么是的，它会正常工作。如果您的连接工厂只知道两个 QMgr 之一，您将只连接到该 QMgr，并且向集群发送消息仍然可以工作。但是按照我提供的链接中的描述进行设置，您的应用程序将能够连接到两个 QMgrs 中的任何一个，您可以通过停止它连接到的通道并观察它连接到另一个来轻松测试它一个。
祝你好运！
更新：
要清楚，提供的详细信息类似于 hostname01、qmgr01、 队列A，服务器通道01。另一个是hostname02，qmgr02，queueA， serverchannel02.
WMQ 客户端将使用多实例CONNAME 连接到两个不同的 QMgrs，仅当...
* 字符）或空格作为 QMgr 名称。可以使用客户端连接定义表（也称为 CCDT）将 WMQ 连接到多个不同的队列管理器之一，其中每个队列管理器的通道名称不同。 CCDT 是您使用MQSC 命令创建的编译工件，用于定义CLNTCONN 通道。它包含客户端有资格连接到的每个 QMgrs 的条目。每个都可以有不同的 QMgr 名称、主机、端口和通道。但是，在定义CCDT 时，管理员定义了所有条目，以便将 QMgr 名称替换为应用程序高级限定符。例如，Payroll 应用程序想要连接到 3 个不同 QMgrs 中的任意 1 个。 WMQ 管理员定义了一个包含三个条目的 CCDT，但使用 PAY01、PAY02 和 PAY03 作为 QMgr 名称。请注意，这不需要匹配实际的 QMgr 名称。然后应用程序将 QMgr 名称指定为 PAY*，这会选择 CCDT 中的所有三个 QMgr。
有关 CCDT 的更多详细信息，请参阅Using a client channel definition table with WebSphere MQ classes for JMS。
MQ 集群与应用服务器集群不同吗？
不，一点也不。
其中两个子节点连接到一个集群。 F5 URL 将 用于将负载分配到每个节点。 WMQ 不自带 我们刚刚发送消息的集群 url / f5 和分区 消息是透明的？
没有。 WMQ 集群提供了一个命名空间，应用程序和 QMgrs 可以在其中解析非本地对象，例如队列和主题。唯一连接到 WebSphere MQ 集群的是队列管理器。应用程序和人类用户总是连接到特定的队列管理器。可能有一组可互换的队列管理器，例如 CCDT，但每个都是独立的。
使用 WAS，消息传递引擎可以在多个节点上运行，但它提供了一个逻辑队列，应用程序可以从中获取消息。使用 WMQ，每个托管该队列的节点都会获取消息的子集，而任何使用这些消息的应用程序只能看到该子集。
HTTP 是无状态的，因此 F5 URL 非常有效。当它确实维护一个会话时，该会话的存在主要是为了优化连接开销并且往往是短暂的。 WMQ 客户端通道是有状态的，并协调单阶段和两阶段工作单元。如果应用程序在 UOW 期间故障转移到另一个 QMgr，则无法协调该 UOW。
由于 WMQ 连接的性质，在 QMgrs 之间从不使用 F5。它仅用于客户端和 QMgr 之间的连接平衡，而不是消息流量平衡。此外，MQ 集群的存在与否对于应用程序来说是完全透明的，在任何一种情况下，应用程序都只需连接到 QMgr 以获取和/或放置消息。使用多实例 CONNAME 或 CCDT 文件通过提供客户端可以连接的多个等效 QMgrs 使连接更加健壮，但这与 WMQ 集群无关。
这有帮助吗？
请看：
【讨论】：