在没有本地队列管理器的情况下使用IBM是否可行和明智？

Question

我的团队正在构建一个应用程序，该应用程序将部署在AWS EC2上，并将通过IBM (以前称为WebSphere MQ，以前称为MQSeries)与本地遗留系统进行通信。

我们已经有了IBM队列管理器。我们还需要在EC2中部署一个吗？我们是否需要将它们部署到应用程序将运行的EC2框上？

我是IBM的新手，尽管我对RabbitMQ有一些经验。公司中有些人对IBM有丰富的经验，但没有任何云应用程序。他们曾多次告诉我，我们需要在盒子上运行一个队列管理器，然后它可以转发给其他队列管理器，但是在一个带有临时磁盘的云机器上，这对我来说没有任何意义--它没有增加任何可靠性。

我们可以在带有EBS卷的EC2机器上部署一个队列管理器，这样做会更有意义，并让我们的应用程序对此进行讨论。但这是否真的比直接在我们自己的楼宇内与现有的队列管理人员交谈更好呢？

为了增加一些额外的乐趣，我们不是直接在EC2上部署应用程序，而是在部署在EC2上的Cloud上部署应用程序，因此应用实例在容器中运行，我们对这些容器没有太大影响。

Answer 1

担心队列管理器将被部署到的卷类型不是您应该担心的问题。IBM有关于支持哪些卷和不支持哪些卷的特定指南。有关更多信息，请查看MQ知识中心。

MQ应用程序可以在本地或远程(到队列管理器)运行。

(1)将本地(绑定模式)连接到队列管理器的MQ应用程序可以使应用程序开发和支持更加容易，因为获取和/放置消息不涉及网络。

(2)远程连接(客户端模式)到队列管理器的MQ应用程序要复杂得多。最近有人在MQ ListServer上发布了一个类似的问题，下面是T.Rob Wyatt的出色回答。

从独立的QMgrs整合到共享的集线器有很多问题。你问的那个是最机械的，也是最无趣的。正如FJ指出的那样，存在一些安全问题，而且您自己也遇到了一些连接问题。让我给你做一些高级别的准备。你在多大程度上感受到了这些因素，这取决于环境目前的独立程度以及它目前的共享程度。在切换到客户端时，例外是数据完整性，所以我将首先讨论这个问题。没有消息丢失或重复，订单基本上是确定的:这需要XA事务。XA强加了它自己的一套设计约束，其中之一就是这个应用程序不能转到另一个QMgr上。MQ的行为通常与每个人所期望的一样，因为在正常情况下，消息不会被复制、丢失或无序。欺骗消息，可能出现无序:这至少需要单阶段提交。如果在syncpoint下从队列中获取消息，而客户端应用程序在下一个API调用中获得2059，则可以确保消息将回滚而不会丢失。但是这个应用程序会再次看到它，如果它第一次被正确处理的话，它将看起来是一个欺骗。此外，如果应用程序在PUTting消息之后在提交上获得2059，它别无选择，只能假设提交失败并再次发出PUT。与GET中的“功能复制”不同，这会生成多个相同的消息。持有一个或多个GET事务的通道代理在MQ或TCP超时并杀死孤立连接之前不会释放消息。由于回滚不一定发生在应用程序重新连接之前，因此很可能会得到不位于同步点的后续消息。当孤立通道被杀死，消息重新出现在队列中时，它们将被传递，但命令将被中断。Dupe，缺少消息，可能是无序:不使用XA和不使用单阶段提交的客户端连接可能会丢失或复制消息，或者由于上述原因而使它们混乱。