问题描述
关于
前 2 个操作在我们的源代码中可见.这是当我们启动事务做一些工作然后说提交.一旦我们从源代码发送提交消息，事务协调器和事务参与者就会接管并做一些工作.
XID 参数用作识别交易的唯一键.每个事务协调器和每个参与者在任何时候都可以参与多个事务，因此需要这样做以识别它们.XID 有两部分，一部分标识全局事务，第二部分标识参与者.这意味着同一交易中的每个参与者都将拥有自己的子标识符.一旦我们到达事务准备阶段，每个事务参与者将其工作写入事务日志，并且每个事务参与者(XARersource)对它的部分是 OK 还是 FAILED 进行投票.一旦收到所有投票，交易就会被提交.如果断电，事务协调器和事务参与者都会保持他们的事务日志持久并可以假设他们的工作.如果在事务提交期间参与者之一投票失败，则将启动后续回滚.
对性能的影响
根据 CAP 定理，每个应用程序(功能)介于一致性、分区和可用性所定义的三角形之间.XA/分布式事务的主要问题是它需要极端的一致性.
此要求导致非常高的网络和磁盘 IO 活动.
磁盘活动 事务协调者和事务参与者都需要维护事务日志.此日志保存在磁盘上，每个事务都需要强制使用此磁盘日志的信息，此信息不是缓冲信息.具有较大的并行度将导致在每个事务日志中强制将大量小消息写入磁盘.通常，如果我们将一个 1GB 文件从一个硬盘复制到另一个硬盘，这将是非常快的操作.如果我们将文件分成 1 000 000 个部分，每个部分都有几个字节，则文件传输将非常缓慢.
磁盘强制随着参与者数量的增加而增长.
1 个参与者被视为正常交易
2 参与者磁盘强制为 5
3 等于 7
网络活动为了绘制分布式 XATransaction 的并行，我们需要将它与某些东西进行比较.正常交易期间的网络活动如下.3 次网络行程 - 登记事务，发送一些 SQL，提交.
对于 XA 事务，这是一个更复杂的想法.如果我们有 2 个参与者.我们在事务 2 网络旅行中征集资源.然后我们发送准备消息另外 2 趟，然后我们再提交 2 趟.
您在交易中招募的参与者越多，针对 2 个资源发生的实际网络活动就越多.
关于如何快速获得分布式事务的结论
- 要做到这一点，您需要确保您拥有一个具有最低延迟的快速网络
- 确保您的硬盘具有最小延迟和最大随机写入速度.一个好的 SSD 可以创造奇迹.- 尝试在事务中获取尽可能少的分布式资源
- 尽量将您的数据划分为对一致性和可用性要求较高的数据(实时数据)和对一致性要求较低的数据.实时数据使用分布式事务.对于离线数据，使用普通事务，如果您的数据不需要，则不使用事务.
我的回答基于我在XA 暴露"(以及个人经验)中所读到的内容，这些内容似乎不再在 Internet 上提供，这促使我写了这篇文章.
In relation to another post of mine, I realized that there is more we can say on stackoverflow in relation to the Distributed, XA transactions and its internals. Common opinion is that distributed transactions are slow.
What are the XA transactions internals and how can we tune them ?
First lets put some common vocabulary. We have two or more parties
- Transaction Coordinator this is where our business logic resides. This is the side that orchestrates the distributed transaction.
- Transaction Participant (XAResource) this can be any Dababase supporting distributed transactions or some other entity supporting the XA protocol like messaging service.
Lets highlight the main API functions performed during XA transaction. - start(XID) - end(XID) - prepare(XID) - commit(XID)
The first 2 operations are visible in our source code. This is when we initiate the transaction do some work and then say commit. Once we send the commit message from the source code the Transaction Coordinator and the transaction Participant take over and do some work.
XID parameter is used as a unique key identifying the transaction. Each transaction coordinator and each participant at any time can participate in more than one transaction so this is needed in order to identify them. The XID has two parts one part identifies the global transaction, the second part identifies the participant. This mean that each participant in the same transaction will have its own sub identifier.Once we reach the transaction prepare phase , each transaction participant writes its work to the transaction log and each Transaction Participant(XARersource) votes if its part is OK or FAILED. Once all votes are received the transaction is committed.If the power goes down the both the Transaction Coordinator and the Transaction Participant keep their transaction logs durable and can presume their work. If one of the participant vote FAILED during transaction commit then subsequent rollback will be initiated.
Implications in terms of performance
According to the CAP theorem each application(functionality) falls somewhere in between the triangle defined by Consistency, Partitioning and Availability. The main issue with the XA/ Distributed transaction is that it requires extreme consistency.
This requirement results into very high network and disk IO activity.
Disk activity Both the transaction coordinator and the transaction participant need to maintain a transaction log. This log is held on the disk each transaction needs to force information withing this disklog, this information is not buffered information. Having large parallelism will result in high amount of small messages forced to the disk in each transaction log. Normally if we copy one 1GB file from one hard disk to another hard disk this will be very fast operation. If we split the file into 1 000 000 parts of couple of bytes each the file transfer will be extremely slow.
Disk forcing grows with the number of participants.
Network ActivityIn order to draw a parallel for distributed XATransaction we need to compare it to something. The network activity during normal transaction is the following. 3 network trips -enlist transaction, send some SQLs, commit.
For a XA transaction it is one idea more complicated. If we have 2 Participants.We enlist the resources in a transaction 2 network trips. Then we send prepare message another 2 trips then we commit with another 2 trips.
The actual network activity that is happening for 2 resources grows even more the more participants you enlist in the transaction.
The conclusion on how to get a distributed transaction fast
- To do this you need to ensure you have a fast network with minimum latency
- Ensure you have Hard drives with minimum latency and maximum random write speed. A good SSD can do miracle.-Try to enlist as minimum as possible distributed resources in the transaction
- Try to divide your data into data that has strong requirement for Consistency and Availability (Live data) and data that has low consistency requirements. Live data use Distributed transaction. For offline data use normal transaction, or no transaction if your data does not require it.
My answer is based on what I have read in "XA exposed" (and personal experience) which appears to be no longer available on internet which triggered me to write this.
这篇关于分布式 (XA) 事务的性能调优 - 如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！