有很多讨论 IBM® WebSphere® MQ 共享队列的资料，特别是讨论其提供消息持续可用性方面的资料更是数不胜数。但在规划和实现期间出现了很多关于如何最好地使用共享队列及其对应用程序的影响方面的问题。其中一些问题得到了广泛的关注（如确保数据序列化的应用程序代码等），而其他问题却没有得到足够的重视。本文所给出的建议均以生产环境中的实现为基础，通常包含可应用于所有 WebSphere MQ 应用程序的最佳实践。除非应用程序可靠且具备高可用性，否则在保证基础设施可靠且具备较高可用性方面所作的努力将效果甚微，因此，应用程序最佳实践对共享队列实现的成功也至关重要。
一些共享队列的主题并未在本文中涉及。WebSphere MQ V6 包含了一个新功能，允许共享队列中存在大于 63K 的消息，但由于在撰写本文时并未在任何生产环境中实现 WebSphere MQ V6，因此并不讨论此类消息对应用程序和资源利用方面的影响。此外，也不会讨论共享通道和组内队列。
本文中所使用的示例应用程序名为 PTR。它所预期处理的消息量是每天 1,000,000 条消息（后文将讨论峰值速率），消息平均大小为 3.5K（含消息描述符——MQMD）。这些消息分布在两个队列中，两个队列中的消息量平均分配。这些消息将由一个名为 PTRC 的 CICS 事务进行处理。
问题 1：Coupling Facility 列表结构和队列大小
与私有队列不同（私有队列的大小受页集大小（根据 WebSphere MQ 不同，最大为 4G 或 64G）的限制），共享队列的大小受到应用程序列表结构大小的限制。此结构是 Coupling Facility (CF) 中的已分配存储区域。CF 是一个公共资源，由系统本身使用：DB2、CICS、IMS 和其他 WebSphere MQ 结构。该结构的大小是由 z/OS 系统管理员通过 IXCMIAPU 设置的。每个 WebSphere MQ 队列共享组 (QSG) 都至少需要使用两个结构，一个用于进行管理的结构，以及一个或多个应用程序结构。
在实际中，大部分队列共享组都定义为一个管理结构和至少两个应用程序结构，一个用于持久性信息，一个用于非持久性消息。WebSphere MQ 管理员需要知道持久性消息是否会进入共享队列。可以容纳持久性和非持久性消息的混合的队列必须在持久性列表结构中定义。
CF 所施加的大小限制使得一些客户询问这样的问题：它们的大容量应用程序是否适合使用共享队列。在某些情况下，CF 容量并不妨碍共享队列的使用，例如，在批处理作业中就是这样（此类作业中数百万消息长时间处于一个队列中）。但在大多数情况下，这个问题被估计过高了，而实际如何使用队列（例如，消息通常在队列中保持多长时间）对于确定使用共享队列是否恰当更为重要。
与 WebSphere MQ 一起提供的示例应用程序设置的初始大小为 266 MB，最大大小为 512 MB。这一部分将向您演示如何计算按照定义可以将多少 PTR 消息放入该结构中。
关于应用程序组的讨论应该可以帮助确定在峰值期间预期的最大深度、消息的大小以及队列上的预期持续时间。在知道消息处理速率和实际用户使用系统之前，进行这些评估可能有些困难。但和进行容量规划工作一样，您需要一个基准。
假定应用程序开发人员要求队列上应该有足够容纳每天预期消息量的 20% 的空间，以便能处理峰值期间大量消息涌入系统或较慢的事务处理无法跟上请求提交的速度时的情况。此行为属于例外，仅会在网络或应用程序停工期间出现。要求仅容纳 PTR 消息的 CF 结构大小应为：
- 1M 消息的 20% = 200,000
- 平均消息大小 = 3.5K = 3584
- 消息数量 * 大小 = 200,000 * 3584 = 716,800,000
- 加上 30% 的系统开销 = 931,840,000（请参阅下面的注释）
- 所需的 1K 大小页面的数量 = 910,000 = 889 MB = 近 1GB
注:30% 的系统开销允许量是基于 Coupling Facility Control Code (CFCC) 第 12 级确定的。如果您的 CFCC 级别不同，此值可能会有变化。有关更多信息，请参阅 WebSphere MQ SupportPac MP16: Capacity Planning and Tuning for WebSphere MQ for z/OS。
889 MB 的要求可能并不现实；事实上，这比 WebSphere MQ V5.3 所定义的缺省应用程序结构大小还要大。当与 z/OS 系统程序员进行讨论时，提出这个值可能会让他们觉得好笑。如果此值过高，那么预期日消息流量的 5% 如何呢？如果 1,000,000 MPD 为一个非常准确的速率，那么这个值就为一个多小时内的消息量。计算过程如下：
- 1M 消息的 5% = 50,000
- 平均消息大小 = 3.5K = 3584
- 消息数量 * 大小 = 50,000 * 3584 = 179,200,000
- 加上 30% 的系统开销 = 232,960,000
- 所需的 1K 大小页面的数量 = 227,500 = 223 MB
此值也可能不太现实，因为其大小几乎占据了整个初始结构大小。如果 PTR 队列已填满，则在该结构中定义了队列的其他应用程序可能会受到影响。
1% 的最低容量要求可能是唯一可行的选项：
- 1M 消息的 1% = 10,000
- 平均消息大小 = 3.5K = 3584
- 消息数量 * 大小 = 10,000 * 3584 = 35,840,000
- 加上 30% 的系统开销 = 46,592,000
- 所需的 1K 大小页面的数量 = 45,500 = 45 MB
文章来源于领测软件测试网 https://www.ltesting.net/
