为什么我的集群不支持 CLWLPRTY？

Question

我有以下设置：

• 一个集群中的四个 MQ 队列管理器（QM1（完整存储库）、QM2（完整存储库）、QM3（部分存储库）、QM4（部分存储库））
• 所有集群发送方/接收方通道具有相同的等级和优先级
• 每个队列管理器都有一个非集群别名队列 (ALIAS.TO.CLQ)
• ALIAS.TO.CLQ 有一个基础对象ALIAS.TO.FLOW，它是一个集群别名队列
• ALIAS.TO.FLOW 有一个基础对象L.TO.FLOW，它是一个本地队列。
• 四个队列管理器中的每一个都配置为CLWLUSEQ(ANY)。
• 集群别名队列有一个DEFBIND 或NOT FIXED。消息是由 IIB（MQ 输出节点）编写的，我相信它尊重这一点 - 尽管我也看到使用 MQ Explorer 或 RFHUtil 的相同行为。
• 消息由 MQ 输出节点放置而不指定队列管理器名称
• 四个集群别名队列中的每一个都有不同的CLWLPRTY，但相同的CLWLRANK。

此配置的目的是强制消息由同一个本地队列接收，无论消息最初放入哪个队列管理器。如果该队列管理器不可用，则应使用第二高优先级，等等。

我发现的问题是，对于四个队列管理器中的三个，CLWLPRTY 正在被兑现，并且消息被路由到最高优先级的队列管理器。但是，在具有最高优先级的队列管理器本身上，消息被路由到第二高优先级；而不是在同一个队列管理器上使用队列，该队列管理器具有最高优先级。

如果我更改具有第二高优先级的队列管理器，消息总是从具有最高优先级的队列管理器路由到那里 - 所以这不仅仅是巧合。如果两个队列实例共享最高优先级，它永远不会选择与自己在同一个队列管理器上的那个；它似乎总是更喜欢去集群。

这里发生了什么，无论消息放在哪里，我怎样才能让它始终尊重优先级？我查看了 IBM 文档 (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ref.con.doc/q082390_.html) 中的“集群工作负载管理算法”页面，但看不出哪里出错了。

--更新--

我尝试创建一组新的队列，格式相同，但只在一个集群队列管理器上 - 所以，ALIAS.TEST -> AL.TEST（集群但只存在一个实例） -> @987654340 @。当我输入ALIAS.TEST 时，我收到一条错误消息：

已发出 MQOPEN 或 MQPUT1 调用，将别名队列指定为目标，但别名队列定义中的 BaseObjectName 解析为不是本地队列或远程队列的本地定义的队列。 (AMQ4480) 已发出 MQOPEN 或 MQPUT1 调用，将别名队列指定为目标，但别名队列定义中的 BaseObjectName 解析为不是本地队列或远程队列的本地定义的队列。 (AMQ4480)

严重性：20（错误）

响应：更正队列定义。

但我可以毫无问题地加入AL.TEST 队列。

--编辑--

好的，它发生的原因出现在这里：https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.pro.doc/q003120_.html

一个别名不能直接解析为同一个队列管理器上的另一个别名。

那么我怎样才能得到我想要的行为呢？

Answer 1

基于将每个 IIB 实例放入本地队列管理器的以下流程：

IIB1 -> QM1 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(4) CLWLUSEQ(ANY)
IIB2 -> QM2 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(3) CLWLUSEQ(ANY)
IIB3 -> QM3 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(2) CLWLUSEQ(ANY)
IIB4 -> QM4 -> QLOCAL(L.TO.FLOW) CLWLRANK(0) CLWLPRTY(1) CLWLUSEQ(ANY)

*假设所有CLUSRCVR 通道上的CLWLRANK、CLWLPRTY 和NETPRTY 在所有四个队列管理器上都相同。

四个 IIB 实例中的任何一个的 PUT 消息将始终流向具有最高 CLWLPRTY 的可用队列。

从集群工作负载管理算法的角度来看，队列实例不可用的原因有很多。我在这篇文章的末尾引用了知识中心，它提供了算法的详细解释。两个常见的原因是：

1. 队列管理器已关闭

2. 队列为PUT(DISABLED)

---

每个 IIB 实例将仅来自与 IIB 实例连接的同一队列管理器上的本地队列中的 GET。在上面描述的设置中，这意味着在正常情况下，如果所有四个队列管理器都已启动，则只有连接到 QM1 的 IIB 实例会接收消息。

---

在 IBM MQ v9.0 知识中心页面“Reference>Configuration reference>IBM MQ cluster commands>Workload balancing in clusters>The cluster workload management algorithm”中可以找到使队列实例不可用的原因，我提供了可能适用于您问题中描述的设置的内容：

算法通过以下规则逐步消除 目的地列表中的目的地。

1. 如果指定了队列或主题名称：

   一个。尽可能消除未启用的队列 目的地。

1. 选择队列时，如果生成的队列集包含队列的本地实例，则通常使用本地实例。这 如果这三个条件之一，则使用队列的本地实例 是真的：

   • 对于使用 CLWLUSEQ(ANY) 定义的本地定义队列，或 从队列管理器继承相同的设置，以下 在更广泛的适用条件范围内，点是正确的：

     一个。根据与队列在同一集群中本地定义的 CLUSRCVR 通道的状态选择本地队列。 此状态与 CLUSSDR 通道的状态进行比较 会将消息带到远程定义的同名队列。

     例如，与队列在同一个集群中有一个 CLUSRCVR。 CLUSRCVR 处于 STOPPING 状态，而其他队列 集群中的同名具有 RUNNING 或 INACTIVE 状态。

     在这种情况下，将选择远程通道，并且不使用本地队列。

     b.本地队列是根据 CLUSRCVR 通道的数量来选择的，在任何与相同状态的 CLUSSDR 通道的比较中， 这会将消息带到远程定义的相同队列 名字。

     例如，与队列在同一个集群中有 4 个 CLUSRCVR 通道，以及 1 个 CLUSSDR 通道。所有频道都一样 INACTIVE 或 RUNNING 的状态。

     因此有五个通道可供选择，还有两个队列实例。五分之四（80%）的信息发往 本地队列。

6. 如果仅保留队列或主题的远程实例，则优先选择恢复的队列管理器而不是暂停的队列管理器。

7. 如果保留多个队列或主题的远程实例，则包括所有不活动或正在运行的通道。国家 列出了常量：

   • MQCHS_INACTIVE

   • MQCHS_RUNNING

8. 如果没有保留队列或主题的远程实例，则所有处于绑定、初始化、启动或停止状态的通道都将 包括。列出了状态常量：

   • MQCHS_BINDING

   • MQCHS_INITIALIZING

   • MQCHS_STARTING

   • MQCHS_STOPPING

9. 如果没有保留队列或主题的远程实例，则包括所有再次尝试的通道。列出状态常量：

   • MQCHS_RETRYING

10. 如果没有保留队列或主题的远程实例，则包括处于请求、暂停或停止状态的所有通道。状态常数 已列出：

    • MQCHS_REQUESTING

    • MQCHS_PAUSED

    • MQCHS_STOPPED