XA 分布式事务协议学习笔记

1.同步阻塞问题

全局事务内部包含了多个独立的事务分支，这一组事务分支要不都成功，要不都失败，各个事务分支的 ACID 特性共同构成了全局事务的 ACID 特性。也就是将单个事务分支的支持的 ACID 特性提升一个层次（up a level）到分布式事务的范畴。即使在非分布式事务中（即本地事务），如果对操作读很敏感，我们也需要将事务隔离级别设置为 SERIALIZABLE。而对于分布式事务来说，更是如此，可重复读隔离级别不足以保证分布式事务一致性。也就是说，如果我们使用 mysql 来支持 XA 分布式事务的话，那么最好将事务隔离级别设置为 SERIALIZABLE。地球人都知道，SERIALIZABLE（串行化）是四个事务隔离级别中最高的一个级别，也是执行效率最低的一个级别。

2.单点故障

由于协调者的重要性，一旦协调者 TM 发生故障，参与者 RM 会一直阻塞下去，尤其在第二阶段，协调者发生故障，那么所有的参与者还处于锁定事务资源的状态中，而无法继续完成事务操作。（如果协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调宕机导致的参与者处于阻塞状态的问题）。

3.数据不一致

在二阶段提交的阶段二中，当协调者向参与者发功 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，这回导致只有一部分参与者接收到了 commit 请求，而在这部分参与者接到 commit 请求之后就会执行 commit 操作。但是其他部分未接到 commit 请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致的现象。