IBM® WebSphere® MQ（以下称为MQ）是IBM的面向消息的中间件产品。它支持异构系统上的独立和可能非并发的应用程序彼此通信。MQ在80多个不同的平台和环境中受到支持。MQ的优点之一是对于多样性的客户环境和数据传输需要，它能够变得高度可配置和可自定义。然而，这个优点可能使配置糟糕的系统泛滥成灾，这样的系统不支持将来的扩展、不断变化的开发标准和协议，以及可靠的安全性。本文描述有关设计、构建、运行和维护MQ解决方案的最常见最佳实践，以便实现MQ的全部好处。务必记住，并非所有的建议都适合于所有情形，并且这些建议是作为指导原则而不是作为硬性规则来提供的。大型的复杂企业可能通常有背离这些建议的充分理由。本文是基于MQ V6编写的，并假设您具备MQ的基础知识。

　　MQ使得应用程序设计人员能够构造长期有效的体系结构。其通用性、灵活性以及广泛的实现和环境，使得描述能涵盖所有情况的过程非常困难。本最佳实践列表应该使架构师、系统管理员和应用程序开发人员能够避免常见的错误，并在他们的解决方案中最优地利用MQ。该列表是按照解决方案的设计、构建、运行和维护这四个阶段来进行组织的。

　　设计

　　对队列管理器和MQ对象使用短名称

　　有时，仅只是给队列命名也会充满挑战。在其他情况下，您已经创建了如此多的队列和其他对象，以致您的命名约定不再有效，或者没有您预期的那样具有描述性。一般来讲，除了通道名称不能超过20个字符以外，MQ对象的名称最多可以有48个字符。您可以使用大写和小写的字母A-Z、数字0-9、下划线(_)、句点(.)和两个特殊字符：正斜杠(/)和百分号(%)。如果使用了两个特殊字符中的任何一个，则必须将名称包括在双引号中。

　　除了一般规则以外，下面是一些建议用于对队列管理器和MQ对象命名的指导原则：
 
　　对所有对象全部使用大写，包括队列管理器，以防止在异构环境中出现可移植性问题。

　队列管理器名称在MQ网络中应该是唯一的，并反映队列管理器的位置、功能和环境（dev、test等）。通道名称应该反映它们的功能和源/目标队列管理器连接流；对所有发送方和接收方通道使用FROMQUEUEMANAGERNAME.TOQUEUEMANAGERNAME，对所有集群通道使用TO.QUEUEMANAGERNAME。如果有多个通道连接到同一个管理器，可以在名称中使用不同的优先级或协议来扩展该约定，但是要保持在20个字符以内。另一个常见的最佳实践是使用SOURCEQUEUEMANAGERNAME.TO.DESTQUEUEMANAGERNAME。
将队列管理器名称保持简短，不要超过8个字符。

　　队列的名称中不应该具有单词QUEUE（因为它做出了暗示），也不应该在名称中具有拓扑（本地、远程、别名等等）。

　　应用程序应该具有高级限定符，其中包含几个字符，后面跟着某个分隔符（例如句点），以便于对名称排序并明确队列的用途（例如 APPXYZ.SERVICE1.REQUEST）。

　　不要在任何MQ对象的名称中使用空格，包括系统主机名称。

　　对于MQ授权，尽管组名称和用户ID的最大长度是20个字符，还是要将名称保持在12个字符以下以防止复杂化。

　　尽管允许使用特殊字符正斜杠(/)和百分号 (%)，但是应该避免使用它们，因为它们会导致跨平台难题。

　　始终为队列管理器分配死信队列（dead letter queue，DLQ）

　　DLQ是一个本地队列，也称为未送达消息队列。为每个队列管理器创建和分配一个死信队列，并使用它来捕获由于网络或目的地问题而未发送的消息，这是一个很好的实践。如果不定义 DLQ，应用程序中的错误可能导致通道关闭。如果发生这种情况，不仅队列将停止接收消息，而且可能影响MQ的正常操作——例如，可能不接收和执行管理命令。在必须保证确切地按顺序处理消息的严格应用程序环境中，可以省略DLQ以强制关闭消息的处理。建议为应用程序做好设计以避免这种场景。 此外，应该对DLQ进行监视，因为到达该队列的消息可能是错误。DLQ应该已定义、可用，并为系统预期要处理的最大消息做好尺寸调整。在要求最可靠的环境中，将死信处理程序设置为触发器，以便自动重试死消息而无需人工介入。如果重试失败，则应该使用自定义的DLQ规则，根据需要转发或删除消息。MQ提供了一个示例DLQ处理程序 (runmqdlq/amqsdlq)，以供您学习和试验。

　　如果您还没有将某个DLQ与现有的队列管理器关联，可以使用MQSC ALTER命令将DLQ添加到队列管理器对象。

　　尽可能使用诸如JMS等标准

　　当今的动态业务需要正在驱使IT部门实现基于标准的计算。JMS是基于J2EE的消息标准，并提供了一个标准API，应用程序可以在执行企业消息时使用该API以实现应用程序可移植性。尽管JMS是与供应商无关的Java消息API，但是不同JMS提供者的实现可能有所不同，了解不同实现之间的变化是非常重要的。在解决方案中使用诸如JMS等标准将促进应用程序可移植性，并减少对特定于供应商的API的依赖。这又会减轻集成挑战，并减少供应商绑定。SOAP/JMS消息正日益成为支持Web服务的平台，从而将帮助客户完成基于SOA的实现。

　　在当今市场上，MQ是J2EE应用程序的较为流行的 JMS 提供者之一。MQ JMS实现无需桥接即可与其他MQ程序互操作。MQ JMS实现同时支持点对点和发布/订阅消息模型。MQ V5.3 Fix Pack 8或更高版本中为MQ提供了一个集成的代理。使用标准化的JMS API，无需重新开发应用程序或接口即可升级到其他JMS代理，例如WebSphere Message Broker。

　　运行

　　使用安全最佳实践

　　在分布式系统上，mqm组提供了对系统上所有MQ资源的管理访问权限。因此，要限制mqm组中的成员资格。MQ中的安全性可划分为两大类：MQ使用者和MQ管理员。使用者通常以ID的形式存在，这些ID用于执行连接到MQ的应用程序。管理员是需要通过所包括的工具（例如runmqsc）来交互式地查询或修改MQ配置的用户。在某些环境中，为简单起见，有时将应用程序帐户ID（使用者）放在mqm组中。在这些情况下，应该锁定这些ID，以防止将它们用于交互式登录，因为获得这些ID访问权限的任何用户都将拥有对MQ的完全管理控制。一种替代方法是使用WMQ OAM setmqaut工具，为每个资源或MQ对象（例如对列）指定API级别的详细权限。这项技术提供了更细粒度的控制，是可行情况下的首选方法。

　　关于管理权限，在需要考虑安全性和审核的情况下，应该使用诸如免费可用的SupportPac MS0E等第三方安全和配置工具来访问和修改MQ配置。在缺乏此类工具的情况下，只有MQ管理团队的成员才应该属于mqm组。应该为其他用户提供较低级别的权限，这些权限可通过OAM级别的setmqaut命令或通过使用诸如MS0E等MQ SupportPacs来授予。

　　在生产级别（受限制的访问）的计算机上使用SYSTEM.ADMIN.SVRCONN通道来限制远程管理权限。

　　在MQ V5.3或更低版本中，基于Windows的MQ Explorer管理工具使用SYSTEM.ADMIN.SVRCONN通道连接到队列管理器。不存在进一步保护该通道的工具，从而为要求限制访问权限的系统带来安全风险，因为了解队列管理器的任何人都可以在具有完全管理权限的情况下建立连接，并且在使用Explorer时没有任何审核跟踪。不过，此通道在缺省情况下是没有创建的，而是必须手动添加。在MQ V6.0或更高版本中，可以使用任何客户端通道进行管理访问，因此在生产系统上启用远程访问时，应考虑采用诸如SSL等附加措施。

　　不要将示例get/put实用工具用于生产目的

　　MQ附带了演示如何获取和放置消息的示例程序。这些示例程序同时以已编译和未编译的形式提供。不要将这些程序一成不变地用作生产级应用程序以获取或放置消息，因为它们具有缓冲区限制，并且可能没有生产级应用程序所需要的可靠性或功能。

　　使用runmqlsr代替inetd侦听器

　　在MQ V5.3或更高版本中，runmqlsr网络侦听器程序允许多线程连接。使用多线程进程而不是通过amqcrsta为每个连接发起新进程的优点是减少系统资源使用，以及消除潜在的管理中断。如果您有具有大量连接的系统（例如集成中心或ESB），以及通过基于UNIX的inetd侦听服务（与amqcrsta程序相结合）来运行的现有侦听器，可以考虑将那些侦听器迁移到runmqlsr。

　　将侦听器端口放在qm.ini文件的TCP节中（或Windows注册表中），以便那些端口与队列管理器很好地关联。然后，当侦听器启动时，将不需要引用任何命令行端口号。

　　使用SupportPacs来扩展MQ功能

　　MQ提供了许多称为MQ SupportPacs的免费可下载插件，以扩展功能。

　　MS03：savequeue 管理器——提供代码将所有MQ对象设置从runmqsc中导出，其导出格式允许以后被重用来导入（并重新创建）队列管理器配置。取决于您的环境，备份和恢复可能至关重要。

　　MS0E：runmqadm——提供一个管理包装，其中为不属于mqm组成员的用户提供了runmqsc和管理级别的访问权限，从而使您能够以更加细粒度的方式授予权限。

　　MA01：q实用工具——允许您浏览消息并在队列之间移动它们。

　　MO03：qload实用工具——允许您针对文件来回移动消息，以便传输到不同的系统或以后重用。

　　MS81：MQIPT——与MQ协同工作的附加产品，其采用SSL或HTTP(S)来通过防火墙建立连接隧道。可将其用于跨单个传输和端口聚集来自多个队列管理器的连接。

　　MC91：高可用性——提供用于在诸如HACMP和Sun Cluster等高度可用的UNIX系统上配置MQ的脚本和说明。

　　维护

　　在未使用第三方配置工具时，通过MQSC脚本来自动化所有的配置和更改。

　　养成以脚本的形式将任何队列管理器更改编写到runmqsc命令中的习惯。可以输入runmqsc编辑器中的任何命令还可以写到文件中以便以后执行。脚本可以在执行前使用runmqsc -v <文件名开关进行验证。在执行时，脚本的输出可容易地捕获到日志文件中以便以后审核。这个习惯将帮助避免代价高昂的输入错误，并在执行时加速更改的执行。

　　使用适当的日志记录机制

　　MQ社区中的一个常见误解是以为线性日志记录更适合于生产级别的系统。除了循环日志记录优点以外，线性日志记录仅渐进地提供了对象恢复能力，并伴随着定期维护以防止文件系统装满的代价。如果将MS03 SupportPac设置为定期运行，则可以通过那些脚本重放对象的副本，从而最小化对线性日志记录的需要。循环日志记录队列管理器只需要较少的维护，并且由于磁盘空间用尽而导致的崩溃风险更低。

　　配置自动化的队列管理器维护

　　考虑创建脚本来自动化队列管理器的定期维护。维护应该包括定期的savequeue队列管理器(MS03)、安全设置备份(amqoamd)、线性日志清理（如适用的话），以及诸如.ini文件等其他重要设置的备份。此外，考虑审核FDC错误目录的内容，检查其中较旧并且应该删除、以及较新并且应该检查的FDC文件，因为它们指示了MQ系统中的关键错误。

　　许多第三方产品可以帮助提供此功能。在编写和维护您自己的脚本之前，应考虑这些供应商产品和免费可用的SupportPacs，因为您自己的脚本在每个新的MQ版本推出时都需要进行维护。

　　定期计划安排和应用修复程序包

　　IBM Support接到的许多求助电话都是由于已经在某个IBM修复程序包中解决的问题而发生的。因此，我们建议管理员定期计划、安排和应用MQ维护。