技术复习-分布式事务

1、分布式事务解决方案

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阶段超时时间过了还未收到回复，则进行回滚。这个机制其实两阶段也有，非三阶段独有。因此只能说三阶段提交引入了参与者的超时机制。

2、分步式事务的实现

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余额宝帐户冻结100 SystemC红包冻结10

commit:

SystemA更新订单状态为成功 SystemB余额帐户冻结扣除100 SystemC红包冻结扣除10

cancle：

SystemA更新订单状态为失败 SystemB余额帐户冻结恢复 SystemC红包冻结恢复