对于跨internet (即100+ ms延迟)和跨组织边界访问WebSphere MQ消息队列,推荐的体系结构是什么?
我们正在考虑的两种方法是直接从我们的客户端访问其他组织的队列管理器,另一种方法是在本地拥有一个队列管理器,该管理器将从远程队列中提取消息,然后本地客户端将访问它。我认为这两种架构都有优点,但我不确定这两种架构之间的权衡。
我们必须处理的数据量是每秒600个,消息大小约为50字节。另一个组织的队列管理器是不可更改的(它是WebSphere MQ)。消息必须按顺序处理。也许可以将它们拆分到不同的队列中,然后每个队列由单独的客户端处理,但在每个队列中,顺序仍然非常重要。通常,只有一个事务处理客户端。可能会有一个额外的商业智能客户端来处理消息的副本。
有谁有MQSeries到MQSeries队列管理器吞吐量的任何性能指标,以及WebSphere MQ队列管理器和客户端吞吐量的比较?
发布于 2011-12-17 13:53:12
从安全的角度来看,推荐的答案是,其他组织应该要求您使用完整的QMgr,而不是客户端。来自外部QMgr的通道连接将仅发出CONNECT
、INQUIRE
和PUT
命令。客户端连接可以访问整个WMQ API,并可以在任何对象上执行任何API调用。例如,如果另一方在其队列名称中使用结构化数据(例如帐号),则客户端应用程序可以遍历所有可能的名称以枚举所有帐号。如果调用返回2035,则对象存在,但授权失败。如果调用返回2085,则该对象不存在。除了允许各种类型的枚举外,陷入连接循环的客户端每秒可以在QMgr上抛出数百次重新连接尝试,这将完全占用侦听器。因此,客户端接受来自QMgr上的连接本身就更加危险,而来自第三方的客户端更是如此。但是,客户端是免费的,而且成本通常大于风险,特别是当应用程序不移动高价值事务或敏感数据时。如果我负责连接到供应商的QMgr,并且他们允许选择客户端连接或QMgr连接,并且应用程序是高可见性的或任务关键型的,我会选择完整的QMgr。
要考虑的另一个方面是,QMgr到QMgr通道对网络连接问题的恢复能力更强。这是因为两个QMgrs跟踪消息序列号,将批保持在同步点下直到确认,并且能够自动协商通道恢复,而不会丢失或复制任何持久消息。由于客户端通道为开发人员提供了对API的完全访问权限,包括编写牺牲可靠性以换取性能的程序的自由,因此编写丢失或重复消息的客户端应用程序是可能的。事实上,网络上异步消息的一个固有问题是会话恢复问题可能会产生不明确的结果,从而导致重复的消息。这并不是特定于JMS的,事实上,WebSphere规范讨论了这个问题,并指出应用程序有责任正确地说明会话恢复所产生的“功能上重复的”消息。您可以通过始终使用事务会话来消除消息丢失的可能性,但要消除发送复制消息的可能性需要做一些工作。两个QMgrs通话使用消除任何这种歧义的协议。
至于性能指标,请查看您的平台的性能报告。这些都可以从SupportPacs landing page获得。查找名称类似MP**
的SupportPacs,例如Windows的SupportPac MP71或Linux的SupportPac MPL5。
发布于 2011-02-04 02:27:46
有一些我不清楚的重要细节。
您是否希望每个本地客户端都获取整个消息队列?如果是这样,那么http://code.google.com/p/pubsubhubbub/可能会很有用。
或者,您是否希望队列中的消息在您的客户端之间进行划分?如果是这样的话,我会有一个本地队列管理器,这样您的客户端获取下一条消息的往返时间完全在您的网络内部,而不是必须通过可能较慢的internet连接。
https://stackoverflow.com/questions/4889570
复制相似问题