问题描述
让我们假设 2 个银行系统（假设它们是 A 和 B）使用 IBM MQ 通过发送消息来相互通信，假设有一个场景，A 有 RecordA，B 有 RecordB。当在 RecordA 需要的地方发起交易时当且仅更新 RecordB 时才会更新。 MQ 如何实现这一目标？
例如，一笔资金转账从 A 的账户 A 中扣除 100 美元，并在 B 的账户 B 中增加 100 美元，
一种可能性是： A 首先启动事务并向 B 发送一条消息，一旦 MQ 保证消息的传递，它就会执行推导，此时 B 也将执行添加。如果 MQ 无法保证消息的传递，而实际上它可能已经传递了怎么办？在这种情况下，A 会怎么做？ （会发生这种情况的一种情况是，由于通信介质故障，消息已送达，但确认在传输过程中丢失，当然我们可以确认确认，但同样的问题再次出现）
我无法想象 IBM MQ 正在使用的那个问题的解决方案。我错过了什么？问题是否存在解决方案？
解决方法
MQ 并不真正操作确认，而是事务。 为了缓解你描述的问题，你需要在 B 上做这样的事情：
- 在同步点下获取消息
- 流程转移
- 提交消息
- 在您的系统上提交传输
这样，如果在您提交获取消息之前 MQ 失败，您可以回滚您的本地处理。 （同样的，如果你的本地处理失败，可以回滚获取消息。）并且在MQ恢复后，你可以尝试再次处理消息（前提是它是一条持久消息）。
当然，A 需要以类似的方式发送传输，因此您的本地更改始终与放置/获取消息保持一致。当消息在 MQ 上时，MQ 保证只传递一次。
为了进一步改进事务处理，MQ 还支持 XA 协调事务。因此，您可以在 QM 和您的应用程序之间启动协调事务，确保同时提交或回滚用于放置/获取消息和更改数据库的事务。