分布式事务
分布式环境下为了保证跨服务、跨数据库数据的正确性，通常有两种方案，第一种是通过补偿机制实现弱一致性，另外一种就是通过分布式事务来实现强一致性。
下面就来探一探分布式事务的前世今生。
目录
定义
分布式事务也称全局事务，参与全局事务的各本地事务称作分支事务。
分布式事务是为实现分布式环境下，跨数据库、跨服务的多个数据库之间的数据的完整性（本地事务我们通常叫做 ACID ）。
XA
XA 是指由 X/Open 组织提出的分布式事务两阶段提交的规范（协议），主流的数据库都支持该协议。
XA 通过协调一个事务访问多个关系型数据库来保证数据的完整性。
协议定义了两个角色，以及两者之间通信的接口。
-
事务管理器（TM, 也被称为协调者）：管理全局事务
-
资源管理器（RM）：全局事务的参与者，可以是一个数据库或者一个 JMS 系统
XA 两阶段提交过程：
1. TM 询问 所有的 RM 提交事务会不会有问题；
2. 如果没问题，TM 向所有的 RM 发送 commit() 指令，否则发送 rollback() 指令
具体过程可以往下看。
两阶段提交
-
TC 发送 prepareCommit 到 RM, RM 执行提交操作并响应 TC；
2. TC 根据所有RM 的响应，发送 commit/rollback 指令,RM 操作根据指令本地事务
存在的问题：
1. TC 提供了超时重试机制，所以即使 RM 宕机了，事务仍然能正确执行；
但是 TC 一旦宕机了，RM 就会一直阻塞等待，本地资源也会一直被锁住。
2. 数据不一致风险：极端情况下会发生数据不一致， 比如第二阶段出现网络分区一部分RM 收到了指令正确执行 ，另一部分RM没收到会一直等待。
3. 第二阶段成功执行前，所有的分支事务会锁住对应的资源，所以性能不如单机的本地事务好。
为了解决两阶段提交存在的问题，提出了三阶段提交的方式。
三阶段提交
与两阶段提交相比，三阶段在开始增加了一个询问阶段：
-
TC 询问 TM 可以提交吗，做些业务判断，是否具备事务操作的条件；
三阶段提交与两阶段提交相比，除了增加了第一步的询问，还增加了参与者超时机制，即使 TC 挂了，参与者会在一定时间后自动 commit 。
之所以三阶段提交可以增加超时机制，是因为多了一个询问阶段，询问阶段通过后，才会进入 prepare 阶段，TC 同时会记录全局事务的状态，超时后，RM 自动提交，TC 恢复后，能根据全局事务的状态执行补偿操作。
存在的问题：
-
性能比两阶段提交还要差；
-
仍然有数据不一致风险：比如还是第二阶段出现网络分区一部分RM 收到了 rollback 指令正确执行 ，另一部分RM没收到超时后，自动 commit；
总体来说，分布式事务设计到全局事务和多个分支事务协调，会因为各种不可靠问题，带来性能问题，并且会出现一些数据不一致的风险，因此使用需要谨慎！
如果觉得还不错的话，交个朋友， 原创不易，且看且珍惜~
