Java 分布式（XA）事务的性能调优-如何？

关于，我意识到，相对于分布式XA事务及其内部，我们可以对stackoverflow说得更多。普遍的看法是分布式事务处理速度很慢

---

XA事务的内部是什么？我们如何调整它们？

首先让我们介绍一些常用词汇表。我们有两个或两个以上的派对

• 事务协调器这是我们的业务逻辑所在。这是协调分布式事务的一方
• 事务参与者（XAResource）这可以是支持分布式事务的任何数据库，也可以是支持XA协议的其他实体，如消息服务

让我们突出显示XA事务期间执行的主要API函数。 -启动（XID） -完(XID) -制备（XID） -提交（XID）

前2个操作在我们的源代码中可见。这是当我们启动事务做一些工作，然后说提交。一旦我们从源代码发送了提交消息，事务协调器和事务参与者就会接管并做一些工作

XID参数用作标识事务的唯一密钥。每个事务协调员和每个参与者在任何时候都可以参与多个事务，因此需要这样才能识别它们。XID有两部分：第一部分标识全局事务，第二部分标识参与者。这意味着同一事务中的每个参与者都有自己的子标识符。 一旦我们到达事务准备阶段，每个事务参与者都会将其工作写入事务日志，并且每个事务参与者（XARersource）会对其部分是否正常或失败进行投票。一旦收到所有投票，交易即被提交。 如果断电，事务协调器和事务参与者都会保持其事务日志的持久性，并可以假定其工作正常。如果其中一个参与者投票在事务提交期间失败，则将启动后续回滚

对绩效的影响

根据CAP定理，每个应用程序（功能）都位于由一致性、分区和可用性定义的三角形之间。XA/Distributed事务的主要问题是它需要极端的一致性

这一要求导致网络和磁盘IO活动非常频繁

磁盘活动事务协调员和事务参与者都需要维护事务日志。此日志保存在磁盘上，每个事务都需要使用此磁盘日志强制执行信息，此信息不是缓冲信息。具有较大的并行性将导致在每个事务日志中向磁盘强制发送大量的小消息。通常，如果我们将一个1GB文件从一个硬盘复制到另一个硬盘，这将是一个非常快速的操作。如果我们将文件拆分为1000 000个部分，每个部分包含两个字节，那么文件传输将非常慢

磁盘强制随参与者数量的增加而增加

1名参与者被视为正常交易
2名与会者 磁盘强制为5
3等于7

网络活动 为了给分布式事务画一个平行线，我们需要将它与其他东西进行比较。正常交易期间的网络活动如下所示。3次网络旅行-登记事务、发送一些SQL、提交

对于XA事务，这是一个更复杂的想法。如果我们有两个参与者。 我们在事务2网络旅行中登记资源。然后我们再发送两次准备消息，然后再提交两次

在事务中登记的参与者越多，2个资源的实际网络活动就越频繁

关于如何快速获得分布式事务的结论

• 要做到这一点，您需要确保拥有一个具有最小延迟的快速网络
• 确保您的硬盘具有最小延迟和最大随机写入速度。好孩子能创造奇迹。 -尝试在事务中登记尽可能少的分布式资源
• 尝试将数据分为对一致性和可用性有强烈要求的数据（实时数据）和一致性要求较低的数据。实时数据使用分布式事务。对于脱机数据，请使用普通事务，如果您的数据不需要，请使用无事务

---

我的答案是基于我在“XA exposed”（和个人经验）中读到的内容，这似乎在互联网上不再可用，这促使我写了这篇文章。

什么是反对票？那么最后的请求呢？你实际上没有问任何问题，你只是发布了一份意向声明来介绍你的答案。此外，您还标记了java和.net（它们没有重叠），而您的答案并不具体，可以应用于任何语言/平台。这本适合于文档（）但不幸的是，它已被关闭。作为一个问题，它不是很合适，因为你没有问一个可回答的问题（除了要求资源）。也许有一个类似wiki的资源，你可以在那里发布这个？@ErwinBolwidt问题是，分布式事务的幕后算法是什么。我不确定这个问题有什么问题，你能解释一下吗？我发现只有一种资源可以提供关于这个主题的详细信息，现在它已经被删除了。很好，在你结束之前，我会用更精确的定义来改变这个问题。我的意图是将内容分为两个问题。您的图表是错误的——TC强制写入是在准备之后完成的，因为在此之前，您没有要记录的提交决策。