我的团队正在构建一个应用程序，该应用程序将部署在 AWS EC2 上，并将通过 IBM MQ（以前称为 WebSphere MQ，以前称为 MQSeries）与内部部署的遗留系统进行通信。
我们的场所内已经有 IBM MQ 队列管理器。我们还需要在 EC2 中部署一个吗？我们需要将它们部署在应用程序将要运行的 EC2 机器上吗？
我是 IBM MQ 的新手，尽管我对 RabbitMQ 有一些经验。公司里有些人对 IBM MQ 很有经验，但没有云应用程序经验。他们曾多次告诉我，我们需要在装有我们应用程序的机器上运行一个队列管理器，然后可以将其转发给其他队列管理器，但在装有临时磁盘的云机器上，这对我来说没有任何意义 - 它不会增加任何可靠性。
我们可以在具有 EBS 卷的 EC2 机器上部署队列管理器，这样更有意义，并且我们的应用程序可以与之通信。但这真的比直接与我们自己场所的现有队列管理器通信更好吗？
为了增加一些额外的乐趣，我们不是直接在 EC2 上部署应用程序，而是在部署在 EC2 上的 Cloud Foundry 上部署，因此应用程序实例在我们没有太大影响的容器内运行。
答案1
您无需担心队列管理器将部署到的卷类型。IBM MQ 对哪些卷受支持以及哪些卷不受支持有具体的指导原则。请查看MQ 知识中心了解更多信息。
MQ 应用程序可以在本地或远程运行（对于队列管理器）。
（1）本地连接（绑定模式）到队列管理器的 MQ 应用程序可以使应用程序开发和支持变得更加容易，因为在获取和/或放置消息时不需要任何网络。
(2) 远程（客户端模式）连接到队列管理器的 MQ 应用程序要复杂得多。最近有人在 MQ ListServer 上发布了类似的问题，T.Rob Wyatt 对此给出了出色的回答。
从独立 QMgrs 整合到共享集线器时，会出现一系列问题。您问到的问题是最机械和最无趣的问题之一。正如 FJ 指出的那样，您自己也遇到了一些安全隐患和连接问题。让我为您概述一下其他一些问题。您遇到这些问题的程度取决于环境当前的独立程度以及当前共享程度。切换到客户端时的数据完整性是例外，所以我将首先讨论这个问题。
没有消息丢失或重复，订单基本有保证：
这需要 XA 事务性。XA 施加了一套自己的设计约束，其中包括相关应用程序不能故障转移到不同的 QMgr。MQ 的行为通常符合每个人的预期，即在正常情况下不会出现消息重复、丢失或混乱的情况。
重复消息，可能造成混乱：
这至少需要单阶段提交。如果您从同步点下的队列中获取消息，并且客户端应用程序在下一次 API 调用时收到 2059，那么您可以确保该消息将被回滚而不会丢失。但应用程序将要再次查看，如果第一次处理正确，则看起来是重复的。此外，如果应用程序在 PUT 消息后在 COMMIT 上收到 2059，则它别无选择，只能假设 COMMIT 失败并再次发出 PUT。与 GET 中的“功能重复”不同，这会生成多个相同的消息。
持有一个或多个 GET 事务的通道代理不会释放消息，直到 MQ 或 TCP 超时并终止孤立连接。由于回滚不一定在应用程序重新连接之前发生，因此它可能会获取不在该同步点下的后续消息。当孤立通道被终止并且消息重新出现在队列中时，它们将被传递，但顺序将被打乱。
可能出现重复、丢失消息、混乱的情况： 不使用 XA 和单阶段 COMMIT 的客户端连接可能会因上述原因而丢失、重复或扰乱消息。