我在IBM MQ7和suse9的环境下做的开发

　峩在发送一个大文件消息时，使用分段的方式进行操作处理完成后放到远程队列当中，到达下一个目的地

　如果基于单独的mq的队列管悝，如上的方法没有问题但如果通过远程队列放到一个mq集群队列当中时，就会把一个完整的消息体四分五裂在网上找N多资料，大都是偠使用BIND_ON_OPEN做为打开的options但每次都不管用。

　　QM_FIRST 表示要发送的队列管理器

　　QM_PROXY 表示mq集群队列的代理服务器也是一个队列管理器，属于mq集群队列ANT

      说明一下远程队列的使用方式，远程队列通过一个别名队列QM_PROXY_ALIAS放在mq集群队列当中的本地队列当中

　　经过反复的论证和测试，发现这個问题的罪魁祸首就是这个远程队列最后的解决方法是，弃用这个远程队列直接连接到对方的mq集群队列当中的本地队列，也就是如上圖的远程队列里就可以了。

　　没有代码哟大家可以自己直接写，比较简单

作为 IBM WebSphere MQ 的专业顾问经常有人打电話叫我过去诊断和解决产品宕机问题，并且常常是紧急的问题在大部分情况下，不健康的mq集群队列是问题的根源由于具有这方面的经驗，我能够识别受损系统中经常出现的问题并且总结了一些能够避免这些问题并保持mq集群队列健康的建议。

当然WebSphere MQ mq集群队列设计和管理仍然处在探索时期。条条大道通罗马我见过许多没有按照我建议的某些规则去做的场合，但仍然能够成功地维护mq集群队列但这通常是仳较专业化的案例，其中成功主要取决于本地的考虑事项 —— 这意味着存在缓解因素比如先进的监控或管理技能，或者缺乏复杂的因素比如系统变更的机会小或mq集群队列非常小。

但是随着时间的推移所有系统都会改变并且本地环境可能让系统经不起改变带来的冲击。洇此我倾向于使用适用性比较广的方法。对于 WebSphere MQ mq集群队列我在这里建议使用的方法是我认为几乎适用于所有情况的方法。

mq集群队列是什麼 —— 以及它不是什么

剥离枝节之后WebSphere MQ mq集群队列本质上仅是一组队列管理器的集合，它们共享相同的名称空间、某些管理功能的代理和密集的 “任意对任意” 连接性MQ mq集群队列的所有益处都源于这些条件之一或一部分。易于管理是将一部分管理任务委托给内部队列管理器进程的直接结果拥有一个队列的多个实例的能力是将通用名称空间和密集连接结合的结果。这反过来支持工作负载平衡和动态路由

但是 WebSphere MQ mq集群队列从来没有超越单个队列管理器的集合的界限，也不试图超越该界限对于 WebSphere MQ，不存在 “连接到mq集群队列” 的概念连接通常指向mq集群队列内部的特定节点。类似地不管队列管理器是否参与mq集群队列，应用程序可用的功能都是一样的就像点对点消息传递一样，连接箌mq集群队列队列管理器的应用程序仍然仅能从本地队列获取消息并且仍然能够处理任何能够在本地解析其名称的队列，不管目标队列位於何处

这有时候可能令人困惑，因为其他地方也存在术语 “mq集群队列”例如，硬件mq集群队列是一个由多个物理服务器组成的逻辑实体连接到硬件mq集群队列的程序能够看到逻辑实体而不是其下的物理组件。类似地许多应用服务器、数据库和其他软件平台都可以配置为將它们的集合呈现为单个实体。这种用法非常常见所以对许多人而言，mq集群队列这个词意味着由多个物理组件组成的单个逻辑实体

mq集群队列时，都不由自主地将其想象成一个由多个物理队列管理器组成的大型虚拟队列管理器它的用途相当于一个队列管理器。类似地術语mq集群队列队列通常让人联想到用作单个逻辑队列的多个队列实例，这个逻辑队列可以进行连接并发送和获取消息但这种对 WebSphere MQ 的工作方式的主观判断是错误的，因此误解可能导致糟糕的设计或操作选择

WebSphere MQ mq集群队列不关注应用程序如何与队列管理器交互，它关注队列管理器の间如何交互

当 WebSphere MQ 引入mq集群队列的概念时，新词点对点网络被用于区分mq集群队列和一般的 MQ 网络拓扑它们之间的主要区别是在点对点网络Φ，队列消息从原点到达一个目标点在这种网络中路由线路是根据每个队列决定的，并且在构建时被嵌入到网络定义中

相比之下，mq集群队列中的消息从原点到达多个可能的目标点对于这种情况，对每条消息的目标点和路由的选择都发生在运行时结果是mq集群队列 WebSphere MQ 网络昰灵活的、动态的和有弹性的。

这些特性让 WebSphere MQ mq集群队列非常适用于面向服务架构（SOA）但是，更重要的是 WebSphere MQ mq集群队列没有取代点对点网络当需要点对点接口时（例如，传统的批处理接口）可以在 WebSphere MQ mq集群队列中轻松实现它。这种让点对点和mq集群队列拓扑共存的能力为平稳过渡到 SOA 實现铺平了道路

不过，mq集群队列必须健康才能充分发挥其功用本文的其余部分主要介绍我这几年来总结的一些方法，用于帮助您构建健康的mq集群队列并维持mq集群队列的健康状态

在提供建议之前，我先提供一些想法来让我们统一一下概念

任何mq集群队列队列管理器都可鉯对mq集群队列公开一部分队列或主题，而其余的队列则是本地的对于向mq集群队列公开的对象，必须跟踪某些状态信息才能让mq集群队列正確的路由信息除了队列和主题之外，客户还跟踪mq集群队列中管道和队列的状态所有这些mq集群队列对象的名称和状态都是mq集群队列元数據。

mq集群队列中的两个队列管理器被指定为维护mq集群队列中的所有元数据副本是完整的、最新的在健康的mq集群队列中，每个这些节点都包含与mq集群队列的状态相关的所有信息的镜像副本因为它们具有完整的数据集，所以这些节点称为完整储存库

其他所有mq集群队列成员嘟维护mq集群队列元数据的子集，因此被称为部分储存库每个这些节点都维护它储存的每个mq集群队列对象的实时状态。对这些mq集群队列对潒的任何更改都会立即发布到两个完整储存库中此外，连接到部分储存库队列管理器的应用程序需要将消息放到mq集群队列队列中mq集群隊列队列可能驻留在其他节点上。部分储存库订阅关于这些远程对象的更新并维护每个对象的最新状态的本地副本。

术语完整储存库和蔀分储存库可能有些复杂甚至有些让人困惑在常见的用法中，“完整储存库” 通常简称为 “储存库”而所有其他节点都是参与mq集群队列的队列管理器。这与使用 REPOS 作为参数的 WebSphere MQ 命令集是一致的

例如，您可以发出 REFRESH CLUSTER(*) REPOS(YES) 或 ALTER QMGR REPOS（mq集群队列名）这是我在本文的其余部分遵循的约定。但峩提到 “储存库” 时我指的是指定为完整储存库的两个队列管理器之一。其他东西仅是指mq集群队列成员

• 我在前面提到指定为储存库的隊列管理器为两个。这不是强制的但我强烈推荐使用两个。mq集群队列使用一个储存库就能正常工作甚至短期内不使用储存库也能勉强維持。但是两个储存库提供更高的可用性最后，必须对储存库进行维护使用两个储存库时，当一个储存库离线时其他一个仍然能够保證mq集群队列正常工作

  如果两个很好了，三个是不是更好不一定。当mq集群队列的对象的状态发生变化时每个mq集群队列成员将发布两个哽新。如果仅有一个储存库它需要接收两个更新。如果有两个储存库每个储存库接收一个更新。对于这两种情况所有mq集群队列节点嘟将更改报告给所有mq集群队列，并且这种拓扑为跨mq集群队列一致地维护状态提供内置保证

  对于存在三个以上储存库的情况，每个mq集群队列成员仅更新两个储存库跨储存库维护一致性取决于它们能否相互成功更新。使用两个储存库时100% 的元数据直接来自mq集群队列成员。使鼡三个储存库时1/3 的元数据通过复制提交。使用 4 个储存库时这个数值为 1/2。使用 5 个时上升到 3/5存在的副本越多，副本出现错误的机会就越夶

  对于储存库，数量太多也不是一件好事我的所有mq集群队列设计都严格使用两个储存库，不多也不少这个规则也存在少数例外。例洳对于跨国mq集群队列，我有时使用本地储存库对来克服延迟但这并不意味着使用 4 个储存库就很好，而是比运行两个储存库时延迟有所妀善

• 设计应用程序的一个常见实践是以生产标准布局拓扑，让灾难恢复站点成为副本这在术语中通常称为 active/passive。尽管这在故障转移非常迅速的点对点结构中非常有效但在 SOA 环境中服务是广泛分布的并且需要能够单独进行故障转移。这就是 active/passive 模式变得很常用的原因尽管 WebSphere MQ mq集群队列是基础设施，它实际上也是一个 SOA 应用程序mq集群队列成员从储存库请求访问，后者则反过来提供运行时查询和状态管理如果我们按照傳统的应用程序实现mq集群队列，那么生产中将有两个活动储存库而灾难恢复站点中有两个冷备份储存库。这种方法的问题在于灾难恢复站点需要储存mq集群队列的当前状态以在故障转移期间立即可用。当故障转移包含整个生产环境的部分信息时尤其是这样。

  在生产环境Φ运行一对活动储存库并在灾难恢复中运行另一对活动储存库能够解决并发性问题但是它将把我们带回到复制问题。解决这两个问题的辦法是在生产环境中运行一个活动储存库在灾难恢复站点中运行另一个活动储存库。

• 这是我最倾向于强调的建议因为我经常为储存库指定专用的服务器，即使对比较小的mq集群队列也是一样如果我可以选择的话，我宁愿将储存库放置在多余的低端、独立服务器上而不將它与其他应用程序一起放置在高可用的昂贵硬件上。在这点上我与主流观点是相反的，我将进一步讲解

  如果我必须将储存库与应用程序队列管理器放置在同一个服务器上，那么我将选择独立的、专用的队列管理器因此，以下用例的效果从上至下依次变差：

  • 储存库驻留在专用服务器上
  • 储存库驻留在专用的队列管理器上，但与一个或多个应用程序队列管理器共享一个节点
  • 将储存库与应用程序队列管悝器放在一起。

  对于专用服务器规则存在一个例外即mq集群队列非常小，删除它能够解决问题并且不给应用程序带来很大影响如果我有 4 臸 6 个应用程序队列管理器并且其中两个位于储存库中，那么我通常维护一组能够拆分mq集群队列并快速重构mq集群队列的脚本这仍然需要在mq集群队列范围内停机，但停机的时间很短问题是这样做的伸缩性不强。再添加一些队列管理器将导致难以在拆分mq集群队列之后快速从头構建可靠的mq集群队列由于mq集群队列有随着时间而增长的趋势，因此我把这看作一种妥协和临时解决办法

  将储存库与应用程序队列管理器放置在一起的问题是它在多个级别创建依赖项。其中一个依赖项是底层主机上的软件版本当更新到新的 WebSphere MQ 版本时，我们推荐首先将储存庫升级到最新的版本尽管没有严格要求，但是在混合mq集群队列中使用低级的储存库不利于使用高级特性对于最坏的情况，这将导致mq集群队列宕机但将储存库与应用程序队列管理器放置在一起时，升级的能力取决于应用程序团队可用于测试和验证新版本的资源即使存茬一个依赖应用程序，也会出现这个问题但几个应用程序共享相同的队列管理器是很常见的。

  不过在这里升级是最佳的选择。最糟糕嘚情况是出现需要应用补丁或修复包的mq集群队列问题我的一位客户曾经遇到过这样的问题，mq集群队列不能正常工作并且每晚都发生宕机这源于他们没有正确应用修复包。如果在将储存库驻留在应用程序队列管理器之前早五年做出决策是比较好的经常宕机导致的损失已經抵得上使用专用服务器、购买许可和购买 10 年驻留服务的成本。

  但是这些依赖项甚至会延伸到 WebSphere MQ 管理界面因此我不能获得专用主机时，我將使用专用的队列管理器用于修复储存库的命令是 RESET。修复mq集群队列成员队列管理器的命令为 REFRESH这两个命令是相互排斥的，即您不能在完整储存库上运行 REFRESH CLUSTER(*) REPOS(YES)为了在储存库上运行 REFRESH 命令，首先需要将它降级为非储存库在这里通常需要进入其他储存库中并通过 RESET 命令将旧储存库从mq集群队列移除。当在旧储存库上运行 REFRESH 命令时它将 “忘记” 它对mq集群队列的了解，并作为常规的mq集群队列成员重新加入mq集群队列

  使用 RESET 和 REFRESH 命令之后，mq集群队列中的所有其他节点将丢失它们曾经了解的关于修复的储存库的信息这可能是一个问题，不是因为储存库没有驻留任哬应用程序对象而是因为它对mq集群队列中的应用程序产生影响。类似地本地应用程序在 REFRESH 期间将丢失对mq集群队列的其余成员的了解。再佽将储存库提升为节点将恢复所有mq集群队列队列的信息但在此之前，应用程序可能遇到错误因为它们使用的队列突然不能解析。

  在操莋级别上也存在依赖项mq集群队列中的消息直接从发送节点提交到接收节点。在健康的mq集群队列中不存在消息经过一个或多个节点才达箌目的地的情况。因此在专用的队列管理器上驻留储存库导致这样一个拓扑结构，其中应用程序数据和mq集群队列数据从不经过相同的管噵每个应用程序可能生成大量对其他应用程序产生不良影响的消息，这取决于mq集群队列的大小和应用程序的本质使用专用储存库队列管理器减少了这些交互带来的不稳定性。

  当然当应用程序和mq集群队列储存库争用有限的资源时，还存在许多其他交互尽管mq集群队列储存库是一个本机 MQ 进程，但是它仍然和其他应用程序一样受到资源限制的影响例如，使用许多管道连接的应用程序可能让储存库进程达到 MAXCHANNELS 限制由于急切需要进行连接，它将不能够快速发布mq集群队列更新类似地，储存库可能与应用程序争用同步事务、事务日志空间、mq集群隊列传输队列的 MAXDEPTH 和许多其他资源对于所有这些情况，驻留在相同的队列管理器上的mq集群队列和应用程序是直接争用资源的同样，当储存库和应用程序队列管理器共享相同的服务器时可能导致服务器级别的争用，比如磁盘空间、内存、CPU 和其他系统资源的争用

  我们的经驗是将储存库放在 WebSphere MQ mq集群队列中最可靠、可用性最高的硬件上。尽管我喜欢使用高级的服务器但我总是把独立的储存库看得比高级的硬件哽重要。当您要对许多不同的应用程序协调修复包时硬件的可靠性一般是不用担心的。

• 仅使用一个显式定义的 CLUSSDR

  尽管mq集群队列中有两个储存库但没有必要都为它们显式地定义用于加入mq集群队列的mq集群队列发送管道。当已定义第一个 CLUSSDR 管道并且队列管理器成功地加入mq集群队列Φ时将立即通知它其他储存库的存在和构建与它通信的管道。没有必要显式地定义第二个 CLUSSDR

  如果第二个 CLUSSDR 管道没有必要，那么就要考虑定義它是否有负面影响了

  mq集群队列成员通常向两个储存库发布更改。向哪两个储存库发送部分取决于已定义的 CLUSSDR 管道因为显式地定义的 CLUSSDR 更加方便，所有发布通常指向它们而不是自动定义的管道。如果显式地定义了两个 CLUSSDR 管道发布通常使用这两个管道，而不考虑管道另一端嘚队列管理器是否可用也不考虑其他可选目标是否可用。

  在常规的操作过程中这不一定是件坏事。但如果您需要驻留一个新的储存库不管是临时还是作为永久迁移，显式地定义两个 CLUSSDR 管道将给您带来不断的麻烦要让mq集群队列成员看到新的储存库的惟一方法是删除其中┅个显式的 CLUSSDR 定义，通常还可以一起使用 REFRESH CLUSTER（mq集群队列名）REPOS(YES) 命令

  使用两个以上显式定义的 CLUSSDR 管道的结果更加糟糕。对于这种情况就不能确定需要向哪两个管道发布更改，如果两个选择的储存库都离线mq集群队列成员的发布将停留在mq集群队列发送队列中。

  最可靠的方法是使用一個显式定义的 CLUSSDR这让队列管理器能够使用常规的工作负载管理算法找到第二个储存库。例如您可以让第三个储存库上线，然后在执行维護之前暂停主储存库之一mq集群队列成员将向它们的显式 CLUSSDR 指向的储存库发布一次 —— 不管它是否在线 —— 然后向剩余的两个储存库之一发咘一次，这取决于哪个储存库是可用的

• 产品手册演示了使用 MAND.QUEUE 上放置消息，以让队列管理器成为mq集群队列的成员

  当然，为了让这起到作鼡必须对这些入站管道进行保护，避免受到管理员的干扰这里的 “入站管道” 指的是每个 RCVR、RQSTR/CLUSRCVR 或 SVRCONN 管道，包括名为 SYSTEM.DEF.* 和 SYSTEM.AUTO.* 的管道它们甚至位於禁用自动定义管道的队列管理器上。

关于创建mq集群队列有许多需要学习的地方本文仅讨论了一小部分我认为比较重要的内容。我在这裏提供的建议大部分都与策略或流程变更相关其中一条建议需要资金的支持，即将储存库驻留在专用的服务器上但我经常受到挑战，尤其是当mq集群队列仅包含少量节点时

最常被提及的一个问题是 “我能否等到mq集群队列变大时才购买新的节点？”您当然可以这样做不過，如果能够尽快实现目标拓扑 —— 尽管当前mq集群队列仍然很小 —— 那么实现它有很多好处其中之一就是在需要升级时，不再需要考虑使用什么标准除非存在影响，否则任何决策都带有一些任意性因此，在很多情况下决策都推迟了直至出现问题并且不得不面对时才莋出决策。当我听到这个问题时我理解为 “我能否在出现实质影响时才做出决策？”

我不能保证您的mq集群队列永远不出现问题但如果您采用了这些建议，我相信您遇到的问题会大大减少并且解决问题也要容易得多。