分布式事务

1. 事务概述

事务的基本结构

开启事务

执行业务逻辑

提交/回滚事务

分布式事务是指在多个系统上进行的事务，目的是保证在一个过程中对这些系统操作的数据的一致性。

分布式事务实现的思路：要执行事务的各个系统准备好后，再统一提交或回滚。

2. XA规范

• AP：应用程序
• TM：事务管理器
• RM：资源管理器

XA规范定义了事务管理器和数据库之间的接口规范，事务管理器通过该接口规范来通知数据库事务开始、回滚、提交。该接口规范由各数据库厂商来实现。

3. 两阶段提交（2PC）

两阶段是指 1.准备；2. 提交/回滚。

注意：

1. 两阶段期间是要跟数据库保持链接的，在提交/回滚后要断开链接释放资源。
2. 回滚可能是因为事务参与方没有准备好，或者响应事务协调方超时。

 

普通的执行流程：

1. 协调方问各个参与方准备好了没

2.1. 参与方如果都回答准备好了，协调方就通知所有参与方都提交事务

2.2. 参与方有回答没准备好的，或者有超时没回答的，协调方就通知所有参与方都回滚

3. 事务结束后，参与方释放数据库资源

 

更优的流程：

按照下面“2PC存在的问题”的解法处理后的流程。优化前2PC在一阶段就开启事务，但不提交，要等到二阶段再提交；优化后2PC在一阶段就执行sql了（开启事务，执行，提交，释放数据库连接），好处是减少连接时长，坏处是要在一阶段做好备份，若回滚，则用备份去覆盖。

 

2PC存在的问题：

• 单点问题：协调方只有一个，如果出问题整个事务就乱了。解法：把协调方部署成集群。
• 数据库资源阻塞占用：在事务期间，要跟数据库保持链接，如果事务执行时间较长，这些链接就很久得不到释放。解法：在第一阶段就提交事务，并记录下提交前的状态。若第二阶段是“提交”，则什么也不需要做；若第二阶段是“回滚”，只需把之前的状态覆盖现在的状态。seata就是用的这种方法来优化2PC。
• 数据不一致：如果参与方都回答准备好了，到协调方在下发命令让所有参与方提交的时候，有参与方掉链子了(如没网、执行失败等)，其数据就与其他参与方的不一致了。解法：使用脚本来检测数据的一致性，检测到有不一致可以按策略来修复。

4. 三阶段提交（3PC）

注意：3PC实际很少用，一般都用2PC。

3PC相对于2PC来说，要解决的问题是2PC在一阶段的时候就开启事务（或执行了事务），如果做执行有问题，就得回滚，比较耗资源。所以3PC增加了一个预检查阶段（can commit），让每个参与方检查一下自己执行的一些前置条件是否满足，以此减少后面回滚的概率。

三个阶段是指：

1. can commit：即上文说的预检查阶段。
2. pre commit：同2PC的一阶段。
3. do commit：同3PC的二阶段。

4. tcc

tcc大体来说其实也是划分成了两个阶段。严格来说tcc是一种特殊的2PC，它在2PC基础上做了优化。

tcc的t（try）算一个阶段，

cc（cancel/commit）算第二个阶段。

它与2pc的差别：

• 2PC更多注重的是数据库层面的操作，tcc注重的是业务层面的操作。
• 2PC一般在强一致要求时使用，而tcc在弱一致要求时使用。
• 2PC在一阶段就锁定了全部资源，而tcc在try的时候只锁定了一部分资源。比如：有个字段的值是100，2PC是直接锁了这个字段，其他人都不能操作这个字段了；而tcc是从这个字段里拿走它需要的（如2个），剩余的（98）其他人还能用这个字段。