分布式事务的几种实现方式

      目前大部分的互联网公司在设计整体架构的时候，都会按照业务模块，将系统拆分成很多小系统，例如订单系统、卡券系统、支付系统等等，简单来说，就是分而治之，这样每个人可以专注维护自己的代码。然后不同的小系统自己开发、测试和上线，都不会跟别人耦合在一起，可以自己独立进行，非常的方便，大大简化了大规模系统的开发成本。      

      然而有了多个子系统之后，分布式事务应该怎么来实现？下面就介绍一下分布式事务的几种实现方式。

一、分布式事务的概念

      分布式事务指的是一个请求在多个系统的调用链当中如何确保数据一致。例如，一个支付请求，支付成功后，会回调请求订单系统修改订单状态，会回调请求卡券系统修改卡券状态。那么如果回调请求因为网络原因丢失了，可能出现用户支付了，订单仍然显示为未支付状态，卡券仍然在冻结中，无法置为已使用状态。

二、2PC/3PC/TCC等分布式事务协议

2PC两阶段提交协议

      2PC是非常经典的强一致、中心化的原子提交协议，协议中定义了两类节点：一个中心化协调者节点和多个参与者节点。2PC分为两个阶段：

准备阶段：

1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。

2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。

3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。

提交阶段：

（所有参与者均反馈YES）

1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。

2、参与者执行Commit请求，并释放整个事务期间占用的资源。

3、各参与者向协调者反馈Ack完成的消息。

4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。

（任何一个参与者反馈NO）

1、协调者向所有参与者发出回滚请求（即Rollback请求）。

2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。

3、各参与者向协调者反馈Ack完成的消息。

4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。

2PC两阶段提交过程中会遇到一些问题：

1、性能问题。从流程上我们可以看得出，其最大缺点就在于它的执行过程中间，节点都处于阻塞状态。各个操作数据库的节点此时都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局提交，参与者进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大。

2、协调者单点故障问题。事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，会导致参与者收不到提交或回滚的通知，从而导致参与者节点始终处于事务无法完成的中间状态。

3、丢失消息导致的数据不一致问题。在第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就会导致节点间数据的不一致问题。

3PC三阶段提交协议

      2PC的改进版本，其在两阶段提交的基础上增加了CanCommit阶段，并引入了超时机制。一旦事务参与者迟迟没有收到协调者的Commit请求，就会自动进行本地commit，这样相对有效地解决了协调者单点故障的问题。。

阶段1：CanCommit
1、协调者向所有参与者发出包含事务内容的CanCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2、参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈YES并进入预备状态，否则反馈NO。

阶段2：PreCommit
事务预提交：（所有参与者均反馈YES时）
1、协调者向所有参与者发出PreCommit请求，进入准备阶段。
2、参与者收到PreCommit请求后，执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
3、各参与者向协调者反馈Ack响应或No响应，并等待最终指令。
中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、协调者向所有参与者发出abort请求。
2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。

阶段3：do Commit

提交事务：（所有参与者均反馈Ack响应时）

1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。

2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。

3、各参与者向协调者反馈Ack完成的消息。

4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。

中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）　　

1、如果协调者处于工作状态，向所有参与者发出abort请求。　　

2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。　　

3、各参与者向协调者反馈Ack完成的消息。　　

4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。

TCC补偿事务协议

TCC 将事务提交分为 Try - Confirm - Cancel 3个操作。

1、Try：预留业务资源/数据效验

2、Confirm：确认执行业务操作

3、Cancel：取消执行业务操作

TCC事务处理流程和 2PC 二阶段提交类似，不过 2PC通常都是在跨库的DB层面，而TCC本质就是一个应用层面的2PC。

三、分布式事务使用场景