分布式事务 Java JMS答案

【问题标题】：Distributed Transactions Java JMS分布式事务 Java JMS
【发布时间】：2013-03-16 22:54:51
【问题描述】：

我想知道我是否可以就如何处理我面临的设计问题获得一些想法。为简单起见，假设我有 3 个端点在 Tomcat 上的 3 台不同的机器/jvm 上运行。端点具有以下职责：

端点 1 - 接收需求数据并将此数据转换为订单请求

端点 2 - 接受订单请求，保存订单并返回订单

端点 3 - 接收订单，格式化为供应商特定的 xml，然后将其发送到队列。

编辑：这些端点作为当前服务存在，通过 REST 提供给其他客户端。我可以选择将 Atomikos 用于 JTA 事务管理器，我们正在使用 ActiveMQ。

话虽如此，我有一个接收需求数据消息的队列设置。对于每个收到的需求数据消息，我基本上想通过 XA 将它们汇集到一个工作单元中的 3 个端点中的每一个。我完全控制了 3 个端点中的每一个，因此我在它们可以使用的通信协议方面具有一定的灵活性。此外，最终每天将有大约 50 万到 100 万条此类消息进入。你们会使用什么通信协议在分布式事务中将这些端点联系在一起？

我有一些使用 Camel 的经验，但我不知道如何将它们整合到一个工作单元中。 RMI 是否会比 JMS 更合适，因为这在本质上似乎是同步的？提前感谢您提供的任何帮助。

【问题讨论】：

这些事务需要运行多长时间？它们需要多久回滚一次？
从我的角度来看，一方面说我想解耦并采取异步方法是没有意义的，另一方面我想通过说 step 来高度耦合它们只有当第 3 步成功时，第 1 步才成功。而且您应该意识到，长时间运行的事务会损害此类系统的吞吐量。所以对于你的最后一个问题：是的，像 RMI 或具有单个控制器的 WebServices 这样的同步协议将减轻你的工作，并有助于保持交易的简短，因为它们同步良好。
@Sir RotN，感谢您的回复和想法。尽管我试图将这些端点组合到一个事务中，但这些端点当前作为其他客户端的服务存在。它们具有 UI 可以使用的 REST 服务接口。
@flup 感谢您的快速回复。事务需要运行不超过 5 分钟，尽管每个进程单独完成的时间不应超过几秒钟。这些事务只需要在数据库不可用或完整流程无法在 5 分钟内完成等问题时回滚。总体而言，每天需要回滚的希望不到 1%。
太好了。 REST 服务同时是最重要的“WebServices”组。因此，您只需让它们支持 XA 事务 id 和（如果尚未完成）json 或 xml 作为结果。然后编写一个控制器来打开事务，触发三个 REST 调用并提交。听起来很简单。

标签： jms apache-camel distributed-computing jta xa

【解决方案1】：

来自the Apache Camel documentation fusesource：

分布式交易 分布式事务是指分布式系统中的事务，其中事务范围跨越多个网络节点。支持分布式事务的基本先决条件是支持以规范格式传输事务上下文的网络协议（另请参见分布式事务管理器）。 分布式事务不在 Apache Camel 事务的范围内。

分布式事务管理器 通常，服务器直接连接到事务中涉及的资源。然而，在分布式系统中，有时需要通过 Web 服务或通过 CORBA IDL 接口连接到仅间接公开的资源。在这种情况下，您需要一个能够支持分布式事务的 TP 监视器。有几种标准描述了如何支持各种分布式协议的事务——例如，用于 Web 服务的 WS-AtomicTransactions 规范和用于 CORBA 应用程序的 CORBA 对象事务服务 (OTS) 规范。

所以难怪你会被踩到。 Apache Camel 不涵盖您的用例。

我认为你可以走两条路：

大分布式事务
通过补偿措施协调较小的交易

tomcat 中的 JTA JTA 是一个全局事务管理器。您可能在两种解决方案中都需要这个。（尽管有一些聪明的摆弄，如果你选择第二个选项，你可能会不用。）Tomcat 不能运行 JTA 事务，但在事务管理器的帮助下它可以。见Atomikos vs JOTM vs Bitronix vs?。添加 Spring JtaTransactionManager 将有助于使其更易于配置。并非所有 JMS 实现都支持 JTA / 都是 XA 资源。你必须检查你的是否有。

分布式交易 您的事务的持续时间不是很长，但是您仍然会锁定资源很长一段时间，并且您有很多事务。性能会受到影响。

JTA 建立在 JTS 和 OTS 之上。 JTA 服务器应该能够通过 OTS 与其他 JTA 服务器协调事务。这不是简单的设置，首先你必须找到一个支持它的实现。然后你必须弄清楚如何启动和运行它。

在更高级别上，您有 WS-Transactions 和 WS-Coordination。见the metro guide。

补偿行动 Transaction in SOA 建议最好使用一组协调的较小事务，这些事务不会回滚，但可以采取补偿措施来清理步骤失败时发生的混乱。

在超时时发送通知就是这样一种操作。如果您发现无法满足订单请求，则取消您在端点一中发出的订单请求可能是另一种补偿操作。

如果你能走这条路，我会接受。

【讨论】：

我不确定我是否敢称这是一个答案，但至少它比评论大，所以这里是。我意识到您真正的问题是如何设置分布式事务管理器，这并不能回答这个问题。我确实希望它能改进问题并提供另一种解决方法。
感谢您提供非常详细的回答。我没有提到我确实尝试利用 Atomikos 作为 Camel 的 JTA 事务管理器。请除了我的道歉。我已经更新了问题以反映这一点。在补偿事务方面，我对这种方法的问题是，某人对您对数据所做的更改以及在您回滚后立即采取行动。或者，如果您发送了一些 jms 消息并且该过程的下一步导致错误怎么办？您将如何撤消 jms 消息。话虽如此，我可能不得不使用 WS 或 CORBA 对吧？
好吧，取端点二。您在数据库中创建订单。你继续前进。在此过程的后期，您发现不应处理订单，因为客户没有足够的信用。您无法回滚订单，因为您没有打开交易。但是您可以取消它。如果其他人已经采取了行动，他们也会取消他们的行动。如果这不好、发生得太频繁且成本太高，请将订单创建为订单预订。当您准备好提交时，再次调用端点 2。这次是确认预订。
感谢您的帮助。我会投票，但我的声望不够高。