Architecture WebSphere MQ连接体系结构

跨internet（即100毫秒以上的延迟）和跨组织边界访问WebSphere MQ消息队列的推荐体系结构是什么

我们正在考虑的两种方法是直接从我们的客户机访问另一个组织的队列管理器，另一种方法是在本地使用队列管理器，从远程队列中抽取消息，然后本地客户机将访问它。我认为两者都有优点，但我不确定这两种架构之间的权衡

我们必须处理的卷为每秒600个，消息大小约为50字节。另一个组织的队列管理器是不可更改的（它是WebSphereMQ）。必须按顺序处理这些消息。也许它们可以在不同的队列之间拆分，然后每个队列由单独的客户机处理，但在每个队列中，顺序仍然非常重要。通常会有一个事务处理客户端。可能还有一个额外的商业智能客户端将处理消息的副本

---

是否有人拥有MQSeries到MQSeries队列管理器吞吐量的任何性能指标，以及WebSphere MQ队列管理器到客户端吞吐量的比较？

有一些我不清楚的重要细节

是否希望本地客户端都获得整个消息队列？如果是这样的话，那么它可能是有用的

---

还是希望队列中的消息在客户端之间进行分配？如果是这样的话，我希望有一个本地队列管理器，这样您的客户端获取下一条消息的往返时间完全在您的网络内部，而不必通过可能较慢的internet连接。

从安全角度来看，建议的答案是，另一个组织应该要求您使用完整的QMgr，而不是客户端。来自外部QMgr的通道连接只会发出

CONNECT

、

INQUIRE

和

PUT

命令。客户端连接可以访问整个WMQ API，并且可以对任何对象执行任何API调用。例如，如果另一方在其队列名称（例如帐号）中使用结构化数据，则客户端应用程序可以循环遍历所有可能的名称以枚举所有帐号。如果调用返回2035，则对象存在，但授权失败。如果调用返回2085，则对象不存在。除了允许各种类型的枚举外，陷入连接循环的客户机每秒可以在QMgr上抛出数百次重新连接尝试，这将完全阻塞侦听器。因此，客户机接受来自QMgr的连接本质上更危险，而来自第三方的客户机更危险。但是，客户端是免费的，而且成本往往超过风险，特别是当应用程序不移动高价值事务或敏感数据时。如果我负责连接供应商的QMgr，并且他们允许选择客户端连接或QMgr连接，并且应用程序是高可见性或任务关键型的，我会选择完整的QMgr

另一个要考虑的方面是QMGR到QMGR信道对网络连通性问题更有弹性。这是因为两个QMGR跟踪消息序列号，将批保持在syncpoint下直到确认，并且能够自动协商通道恢复，而不会丢失或复制任何持久消息。由于客户端通道使作为开发人员的您能够完全访问API，包括自由编写程序以牺牲性能的可靠性，因此有可能编写丢失或复制消息的客户端应用程序。事实上，网络上异步消息的一个固有问题是会话恢复问题可能会产生不明确的结果，从而导致重复消息。这并不特定于WebSphere MQ，事实上，JMS规范讨论了这个问题，并指出应用程序有责任正确解释由于会话恢复而产生的“功能上重复”的消息。您可以通过始终使用事务性会话来消除消息丢失的可能性，但消除发送重复消息的可能性需要一些工作。两个QMGR使用消除任何此类歧义的协议

---

至于性能指标，请查看您平台的性能报告。这些都可以从网站上获得。查找名称为

MP**

的SupportPac，例如Windows的SupportPac MP71或Linux的SupportPac MPL5。

更新了原始问题的一些细节。最低要求是在我们的组织中有一个客户机，如果我没有看错的话，这意味着有一个队列管理器。您是否对通过较慢的连接直接访问QM与通过QM->QM，然后在QMs之间连接较慢的客户端进行性能比较？性能比较是增加的往返时间，这完全取决于所讨论的网络。我实际上没有使用MQSeries，所以我无法具体说明。很抱歉，我的回复太晚了，但由于标签和产品名称的原因，这篇文章没有引起我的注意。我已重新标记并重命名为WebSphere MQ。