一、分布式事务解决方案
1.两阶段提交 two phase commit
角色分为协调者、参与者。协调者负责协调所有的参与者。
第一阶段 prepare
协调者发送prepare请求，参与者锁定资源之后返回ready或者not ready。如果存在not ready或者超时的，则发送请求rollback请求回滚释放资源。否则进入第二阶段。
第二阶段 commit
协调者收到所有参与者的ready请求，则发送commit请求。参与者开始提交事务并回复ack。
两阶段提交存在的问题
同步阻塞效率不高。协调者存在单点故障。数据不一致。
###2.三阶段提交 three phase commit角色依旧分为协调者，参与者。
第一阶段canCommit
只是检查资源，不锁资源
第二阶段 preCommit
第一阶段存在con't commit 的参与者的话，则发送rollback.第一阶段参与者全部回复ok,则协调者开始进行预提交请求，参与者收到请求之后锁定资源。
第三阶段 doCommit
协调者若收到所有参与者的ok，则发送doCommit请求。若超时时间到了，协调者未收到所有preCommit，发送rollback。若超时时间到了，参与者未收到doCommit请求，也进行提交。
相对于两阶段提交，三阶段提交主要引入了参与者的超时机制，如果参与者未收到doCommit请求，则默认提交，不会一直持有事务锁定资源。至于协调者的超时机制就是在preCommit阶段超时时间过了还未收到回复，则进行回滚。这个机制其实两阶段也有，非三阶段独有。所以只能说三阶段提交引入了参与者的超时机制。
二、分步式事务的实现
1.XA
XA协议基于2PC实现的，是由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。这里直接画图表示。
XA在prepare阶段到commit前会持续的锁定资源，效率比较低，对于高并发并不合适
2.TCC
TCC基于2PC，最终一致性，属于应用服务维度的实现方案，由服务方自己实现try、commit、cancle。
相对于XA，TCC是最终一致性，属于服务维度的实现，由服务方自由实现try,commit,cancle接口的时候，自由控制锁的粒度范围
这里举一个使用TCC的例子:使用余额支付100+红包支付10。
try：
SystemA创建订单SystemB余额宝账户冻结100SystemC红包冻结10
commit:
SystemA更新订单状态为成功SystemB余额账户冻结扣除100SystemC红包冻结扣除10
cancle：
SystemA更新订单状态为失败SystemB余额账户冻结恢复SystemC红包冻结恢复