分布式 ( XA ) 事务的性能调整 - 如何？
Performance tuning of Distributed ( XA ) transaction - How?
关于 ，我意识到在 Whosebug 上我们可以说更多关于分布式、XA 事务及其内部的内容。普遍认为分布式事务很慢。
什么是 XA 事务内部机制以及我们如何调整它们？
首先放一些常用的词汇。我们有两个或更多派对
- 事务协调器这是我们的业务逻辑所在的地方。这是编排分布式事务的一方。
- 事务参与者 (XAResource) 这可以是任何支持分布式事务的数据库或支持 XA 协议（如消息服务）的其他实体。
让我们突出显示 XA 事务期间执行的主要 API 功能。
- 开始（XID）
- 结束（XID）
-准备（XID）
-提交（XID）
前两个操作在我们的源代码中可见。这是我们启动事务做一些工作然后说提交的时候。一旦我们从源代码发送提交消息，事务协调器和事务参与者就会接管并做一些工作。
XID 参数用作识别交易的唯一键。每个交易协调员和每个参与者在任何时候都可以参与多个交易，因此需要这样做才能识别他们。 XID 有两部分，一部分标识全局事务，第二部分标识参与者。这意味着同一交易中的每个参与者都将拥有自己的子标识符。
一旦我们到达交易准备阶段，每个交易参与者都会将其工作写入交易日志，并且每个交易参与者（XARersource）都会投票决定它的部分是 OK 还是 FAILED。一旦收到所有选票，交易就会被提交。
如果断电，事务协调器和事务参与者都会保持事务日志的持久性，并可以假定他们的工作。如果其中一位参与者在事务提交期间投票失败，则将启动后续回滚。
性能方面的影响
根据 CAP 定理，每个应用程序（功能）都介于一致性、分区和可用性定义的三角形之间。 XA/分布式事务的主要问题是它需要极端的一致性。
此要求导致非常高的网络和磁盘 IO activity。
磁盘activity事务协调者和事务参与者都需要维护一个事务日志。此日志保存在磁盘上，每个事务都需要使用此磁盘日志强制信息，此信息不是缓冲信息。具有大的并行性将导致在每个事务日志中将大量小消息强制写入磁盘。通常，如果我们将一个 1GB 的文件从一个硬盘复制到另一个硬盘，这将是非常快速的操作。如果我们将文件分成 1 000 000 个部分，每个部分几个字节，文件传输将非常慢。
磁盘强制随着参与者的数量而增长。
1 participant is treated as normal transaction
2 participants the
disk forcing is 5
3 equals 7
网络Activity
为了对分布式 XATransaction 进行比较，我们需要将其与某些东西进行比较。正常交易期间的网络activity如下。 3 次网络旅行 - 登记事务，发送一些 SQL，提交。
对于 XA 事务，这是一个更复杂的想法。如果我们有 2 个参与者。
我们在事务 2 网络行程中征用资源。然后我们再发送 2 次准备消息，然后再提交 2 次。
为 2 个资源发生的实际网络 activity 增长得更多，您在交易中招募的参与者越多。
如何快速获取分布式事务总结
- 要做到这一点，您需要确保您拥有一个具有最小延迟的快速网络
- 确保您的硬盘具有最小延迟和最大随机写入速度。一个好的 SSD 可以创造奇迹。
-尽量在事务中征用尽可能少的分布式资源
- 尽量把你的数据分成对一致性和可用性要求高的数据（Live data）和对一致性要求低的数据。实时数据使用分布式事务。对于离线数据，使用正常事务，如果您的数据不需要，则不使用事务。
我的回答是基于我在“XA exposed”（和个人经验）中读到的，它似乎不再在互联网上可用，这促使我写这篇文章。
关于
什么是 XA 事务内部机制以及我们如何调整它们？
首先放一些常用的词汇。我们有两个或更多派对
- 事务协调器这是我们的业务逻辑所在的地方。这是编排分布式事务的一方。
- 事务参与者 (XAResource) 这可以是任何支持分布式事务的数据库或支持 XA 协议（如消息服务）的其他实体。
让我们突出显示 XA 事务期间执行的主要 API 功能。 - 开始（XID） - 结束（XID） -准备（XID） -提交（XID）
前两个操作在我们的源代码中可见。这是我们启动事务做一些工作然后说提交的时候。一旦我们从源代码发送提交消息，事务协调器和事务参与者就会接管并做一些工作。
XID 参数用作识别交易的唯一键。每个交易协调员和每个参与者在任何时候都可以参与多个交易，因此需要这样做才能识别他们。 XID 有两部分，一部分标识全局事务，第二部分标识参与者。这意味着同一交易中的每个参与者都将拥有自己的子标识符。 一旦我们到达交易准备阶段，每个交易参与者都会将其工作写入交易日志，并且每个交易参与者（XARersource）都会投票决定它的部分是 OK 还是 FAILED。一旦收到所有选票，交易就会被提交。 如果断电，事务协调器和事务参与者都会保持事务日志的持久性，并可以假定他们的工作。如果其中一位参与者在事务提交期间投票失败，则将启动后续回滚。
性能方面的影响
根据 CAP 定理，每个应用程序（功能）都介于一致性、分区和可用性定义的三角形之间。 XA/分布式事务的主要问题是它需要极端的一致性。
此要求导致非常高的网络和磁盘 IO activity。
磁盘activity事务协调者和事务参与者都需要维护一个事务日志。此日志保存在磁盘上，每个事务都需要使用此磁盘日志强制信息，此信息不是缓冲信息。具有大的并行性将导致在每个事务日志中将大量小消息强制写入磁盘。通常，如果我们将一个 1GB 的文件从一个硬盘复制到另一个硬盘，这将是非常快速的操作。如果我们将文件分成 1 000 000 个部分，每个部分几个字节，文件传输将非常慢。
磁盘强制随着参与者的数量而增长。
1 participant is treated as normal transaction
2 participants the disk forcing is 5
3 equals 7
网络Activity 为了对分布式 XATransaction 进行比较，我们需要将其与某些东西进行比较。正常交易期间的网络activity如下。 3 次网络旅行 - 登记事务，发送一些 SQL，提交。
对于 XA 事务，这是一个更复杂的想法。如果我们有 2 个参与者。 我们在事务 2 网络行程中征用资源。然后我们再发送 2 次准备消息，然后再提交 2 次。
为 2 个资源发生的实际网络 activity 增长得更多，您在交易中招募的参与者越多。
如何快速获取分布式事务总结
- 要做到这一点，您需要确保您拥有一个具有最小延迟的快速网络
- 确保您的硬盘具有最小延迟和最大随机写入速度。一个好的 SSD 可以创造奇迹。 -尽量在事务中征用尽可能少的分布式资源
- 尽量把你的数据分成对一致性和可用性要求高的数据（Live data）和对一致性要求低的数据。实时数据使用分布式事务。对于离线数据，使用正常事务，如果您的数据不需要，则不使用事务。
我的回答是基于我在“XA exposed”（和个人经验）中读到的，它似乎不再在互联网上可用，这促使我写这篇文章。