分布式事务及其解决方案

分布式事务的解决方案

谈到事务的解决方案，我们先来分析一下什么是事务。

事务

事务： 访问并可能操作各种数据项的一个数据库操作序列，其包括ACID四个特性。

• 原子性：一个事务内的所有操作要么都执行，要么都不执行。
• 一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
• 隔离性：多个事务并发执行时互相不干扰
• 持久性：一个事务完成了之后数据就被永远保存下来了，之后的其他操作或故障都不会对事务的结果产生影响。

介绍完事务，在来介绍一下分布式事务。

分布式事务

分布式事务，就是在分布式系统中实现事务。抽象的介绍分布式事务的话，分布式事务就是多个本地事务通过某种关系的组合。
不过出现了分布式事务，也随之而来带来了很多问题，因为将需要将多个本地事务连接起来，则不能满足单个事务的ACID。为了解决这一问题，不断提出各种解决方案，比如：2PC、3PC等等。

2PC

2PC(Two-phase commit protocol)二阶段提交，通过引入一个事务的协调者来管理各个数据库事务的提交和回滚，就是将事务提交分为准备和提交阶段。
具体流程如下：
1、准备阶段：协调者会给各个参与者发送准备命令。等待所有资源响应之后进入第二阶段。
2、提交阶段：若第一阶段所有参与者都返回准备成功后， 协调者再次向所有参与者发送提交事务的命令，然后等待所有事务都提交成功后，返回事务执行成功。

这种2PC的解决方法中若有一个参与者返回准备失败，则协调者会命令所有发送者回滚事务的请求，导致分布式事务执行失败。
若第二阶段提交失败的话，可能会造成两种结果：第一种第二阶段执行的回滚的事务操作，不断进行重试操作，直到所有参与者都回滚了。第二种是第二阶段执行的是提交事务操作，同样是不断重试，若有的参与者事务已经提交，则剩下的参与者事务只能不断的重试，指导提交成功，这种情况不能够自己得到解决，只能由程序员进行干预。

2PC 是一种尽量保证强一致性的分布式事务，因此它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低，并且存在单点故障问题，在极端条件下存在数据不一致的风险。

3PC

针对2PC出现的现象，便提出了3PC来解决问题。
3PC的解决方案则是将2PC的提交阶段分为预提交和提交阶段，此时3PC的准备阶段仅仅负责询问参与者的情况。
具体流程如下：
1、准备阶段：协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 true 并进入预备状态，否则反馈 false。
2、预提交阶段：协调者向参与者发送预提交请求，并进入准备阶段。参与者接收到请求后，会执行本地事务操作，并记录到事务日志中（但不提交事务）如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
3、提交阶段：协调接收到所有参与者发送的ACK响应，那么他将从预提交状态进入到提交状态，并向所有参与者发送请求参与者接收到请求之后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源。事务提交完之后，向协调者发送ACK响应。协调者接收到所有参与者的ACK响应之后，完成事务。

与2PC相比，3PC降低了阻塞范围，并且在等待超时后，协调者或参与者会中断事务，避免了协调者单点问题，阶段三中协调者出现问题时，参与者会继续提交事务。但是数据不一致问题依然存在，因为如果在参与者收到请求后等待指令时，协调者请求中断事务，会导致参与者继续提交事务时造成数据不一致。

TCC

针对每个操作，都要实现对应的确认和补偿操作，也就是业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作，首先由业务代码编排来调用Try接口进行资源预留，当所有参与者的 Try 接口都成功了，事务协调者提交事务，并调用参与者的 confirm 接口真正提交业务操作，否则调用每个参与者的 cancel 接口回滚事务。
具体流程如下：
1、业务系统检测并预留资源。
2、检查阶段所有分支事务执行成功后开始执行确认阶段。
3、业务执行错误，需要回滚的状态下执行分支事务的业务的取消阶段 ，释放预留的资源。