分布式事务
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
DTP
最早的分布式事务模型是 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing（DTP）模型，也就是大家常说的 X/Open XA 协议，简称XA 协议。
X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由各个厂商进行具体的实现。 X/Open DTP 定义了三个组件： AP，TM，RM
AP(Application Program)：也就是应用程序，可以理解为使用DTP的程序
RM(Resource Manager)：资源管理器，这里可以理解为一个DBMS系统，或者消息服务器管理系统，应用程序通过资源管理器对资源进行控制。资源必须实现XA定义的接口
TM(Transaction Manager)：事务管理器，负责协调和管理事务，提供给AP应用程序编程接口以及管理资源管理器
DTP通过两阶段提交协议来控制事务。
第一阶段：准备阶段 TM事务管理器通知RM资源管理器准备分支事务，RM资源管理器告之TM事务管理器准备结果
第二阶段：提交阶段 TM事务管理器通知RM资源管理器提交分支事务，RM资源管理器告之TM事务管理器结果
XA的ACID特性
原子性：XA议使用2PC原子提交协议来保证分布式事务原子性
隔离性：XA要求每个RMs实现本地的事务隔离，子事务的隔离来保证整个事务的隔离。
一致性：通过原子性、隔离性以及自身一致性的实现来保证“数据库从一个一致状态转变为另一个一致状态”；通过MVCC来保证中间状态不能被观察到。
2PC的问题
实现简单，但是相应问题多，实际使用的很少
- 性能问题：在提交阶段所有事务参与者处于同步阻塞状态，容易导致性能瓶颈，大幅度限制分布式性能
- 可靠性：单点故障问题，一旦协调者宕机了，所有事务参与者将阻塞，将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
- 数据一致性：协调者在网络异常或者是发送完所有commit请求之前发生崩溃，部分事务参与者收到了commit消息，另一部分参与者没有收到commit消息，那么导致节点之间的数据不一致问题。
在参与者和协调者提交阶段，有参与者节点崩溃导致无法与协调者正常通信，这时协调者将只能依赖协调者自身的超时机制来生效。但往往超时机制生效时，协调者都会指示参与者进行回滚操作，这样的策略显得比较保守。
3PC
三阶段提交是为解决两阶段提交协议的缺点而设计的
与两阶段提交不同的是，三阶段提交是“非阻塞”协议。三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
阶段1： can Commit 协调者向参与者发送commit请求，参与者如果可以提交就返回yes响应(参与者不执行事务操作)，否则返回no响应
阶段2：pre Commit 协调者根据阶段1 canCommit参与者的反应情况来决定是否可以基于事务的preCommit操作。根据响应情况，有以下两种情况发生。
阶段3：do Commit 该阶段进行真正的事务提交
3PC的问题
优点 相比二阶段提交，三阶段贴近降低了阻塞范围，阶段2在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。
缺点 数据不一致问题依然存在，当在参与者收到preCommit请求后等待do commite指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
TCC（Try-Confirm-Cancel）
TCC是服务化的二阶段编程模型，其Try、Confirm、Cancel 3个方法均由业务编码实现；
- Try操作作为一阶段，负责资源的检查和预留。
- Confirm操作作为二阶段提交操作，执行真正的业务。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务有且只能成功一次。
- Cancel是预留资源的取消。释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。
TCC事务的Try、Confirm、Cancel可以理解为SQL事务中的Lock、Commit、Rollback。
TCC总结
优点:
- 性能提升 具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
- 数据最终一致性 基于Confirm和Cancel的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。
- 可靠性 解决了XA协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。
缺点： TCC的Try、Confirm和Cancel操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。