分布式事务解决方案之2PC（二）
一 什么是2PC
2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。
举例：张三和李四好久不见，老友约起聚餐，饭店老板要求先买单，才能出票。这时张三和李四分别抱怨近况不如意，囊中羞涩，都不愿意请客，这时只能 AA。只有张三和李四都付款，老板才能出票安排就餐。但由于张三和李四都是铁公鸡，形成了尴尬的一幕：
准备阶段：老板要求张三付款，张三付款。老板要求李四付款，李四付款；
提交阶段：老板出票，两人拿票纷纷落座就餐。
例子中形成了一个事务，若张三或李四其中一人拒绝付款，或钱不够，店老板都不会给出票，并且会把已收款退回。整个事务过程由事务管理器和参与者组成，店老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。
二 2PC 详细分析
在计算机中部分关系数据库如 Oracle、MySQL 支持两阶段提交协议；
1）准备阶段（Prepare phase）：事务管理器给每个参与者发送 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交；
（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）
2）提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚 (Rollback) 消息；否则，发送提交 (Commit) 消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放锁资源。
下图展示了2PC的两个阶段，分成功和失败两个情况说明：
成功情况：
失败情况：
三 XA 解决方案
2PC 的传统方案是在数据库层面实现的，如 Oracle、MySQL 都支持 2PC 协议，为了统一标准减少行业内不必要的对接成本，需要制定标准化的处理模型及接口标准，国际开放标准组织Open Group 定义了分布式事务处理模型 DTP（Distributed Transaction Processing Reference Model） 。
为了让大家更明确XA方案的内容过程，下面新用户注册送积分为例来说明：
执行流程如下：
1）应用程序（AP）持有用户库和积分库两个数据源；
2）应用程序（AP）通过 TM 通知用户库 RM 新增用户，同时通知积分库 RM 为该用户新增积分，RM 此时并未提交事务，此时用户和积分资源锁定；
3）TM收到执行回复，只要有一方失败则分别向其他RM发起回滚事务，回滚完毕，资源锁释放；
4）TM 收到执行回复，全部成功，此时向所有 RM 发起提交事务，提交完毕，资源锁释放。
DTP 模型定义如下角色：
AP(Application Program)：即应用程序，可以理解为使用DTP分布式事务的程序。
RM(Resource Manager)：即资源管理器，可以理解为事务的参与者，一般情况下是指一个数据库实例，通过资源管理器对该数据库进行控制，资源管理器控制着分支事务。
TM(Transaction Manager)：事务管理器，负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个RM。全局事务是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即是一个全局事务。
DTP 模型定义TM和RM之间通讯的接口规范叫XA，简单理解为数据库提供的2PC接口协议，基于数据库的 XA 协议来实现 2PC 又称为 XA 方案。
以上三个角色之间的交互方式如下：
1） TM 向 AP 提供应用程序编程接口，AP 通过 TM 提交及回滚事务；
2） TM 交易中间件通过 XA 接口来通知 RM 数据库事务的开始、结束以及提交、回滚等。
总结：
整个 2PC 的事务流程涉及到三个角色 AP、RM、TM。AP 指的是使用 2PC 分布式事务的应用程序；RM 指的是资源管理器，它控制着分支事务；TM 指的是事务管理器，它控制着整个全局事务。
1） 在准备阶段 RM 执行实际的业务操作，但不提交事务，资源锁定；
2） 在提交阶段 TM 会接受 RM 在准备阶段的执行回复，只要有任一个 RM 执行失败，TM 会通知所有 RM 执行回滚操作，否则，TM 将会通知所有 RM 提交该事务，提交阶段结束资源锁释放。
XA方案的问题：
1）需要本地数据库支持XA协议；
2）资源锁需要等到两个阶段结束才释放，性能较差。
四 Seata 方案
Seata 是由阿里中间件团队发起的开源项目 Fescar，后更名为 Seata，它是一个是开源的分布式事务框架。
传统 2PC 的问题在 Seata 中得到了解决，通过对本地关系数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。主要优点是性能较好，且不长时间占用连接资源，它以高效并且对业务 0 侵入的方式解决微服务场景下面临的分布式事务问题，它目前提供 AT 模式 (即2PC) 及 TCC 模式的分布式事务解决方案。
Seata的设计思想如下：
Seata 的设计目标其一是对业务无侵入，因此从业务无侵入的 2PC 方案着手，在传统 2PC 的基础上演进，并解决 2PC 方案面临的问题；
Seata 把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下图是全局事务与分支事务的关系图：
与传统 2PC 的模型类似，Seata 定义了3个组件来协议分布式事务的处理过程：
Transaction Coordinator (TC)： 事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收 TM 指令发起全局事务的提交与回滚，负责与 RM 通信协调各各分支事务的提交或回滚；
Transaction Manager (TM)： 事务管理器，TM 需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向 TC 发起全局提交或全局回滚的指令；
Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器 TC 的指令，驱动分支（本地）事务的提交和回滚。
还拿新用户注册送积分举例 Seata 的分布式事务过程：
具体的执行流程如下：
1）用户服务的 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID；
2）用户服务和积分服务的 RM 向 TC 注册分支事务，用户分支事务在用户服务执行新增用户逻辑，积分分支事务在积分服务执行完新增积分逻辑，并将两者纳入 XID 对应全局事务的管辖；
3）用户服务执行分支事务，向用户表插入一条记录；
4）逻辑执行到远程调用积分服务时(XID 在微服务调用链路的上下文中传播)。积分服务的RM 向 TC 注册分支事务，该分支事务执行增加积分的逻辑，并将其纳入 XID 对应全局事务的管辖；
5）积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务；
6）用户服务分支事务执行完毕。
7）TM 向 TC 发起针对 XID 的全局提交或回滚决议；
8）TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
Seata 实现 2PC 与传统 2PC 的差别：架构层次方面，传统 2PC 方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身，通过 XA 协议实现，而 Seata 的 RM 是以 jar 包的形式作为中间件层部署在应用程序这一侧的。
两阶段提交方面，传统 2PC 无论第二阶段的决议是 commit 还是 rollback，事务性资源的锁都要保持到 Phase2 完成才释放。而 Seata 的做法是在 Phase1 就将本地事务提交，这样就可以省去 Phase2 持锁的时间，整体提高效率。
五 Seata 实现 2PC 事务
需要自己下载 Seata 事务协调器，解压安装使用；
1）业务说明
本示例通过Seata中间件实现分布式事务，模拟三个账户的转账交易过程。
两个账户在三个不同的银行(张三在bank1、李四在bank2)，bank1和bank2是两个个微服务。交易过程是，张三给李四转账指定金额。
上述交易步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。
本示例程序技术结构如下：
2）Seata 执行流程
正常提交流程
回滚流程：回滚流程省略前的RM注册过程；
要点说明：
1）每个 RM 使用 DataSourceProxy 连接数据库，其目的是使用 ConnectionProxy，使用数据源和数据连接代理的目的就是在第一阶段将 undo_log 和 redo_log 和业务数据放在一个本地事务提交，这样就保存了只要有业务操作就一定有 undo_log 和 redo_log；
2）在第一阶段 undo_log 中存放了数据修改前和修改后的值，为事务回滚作好准备，所以第一阶段完成就已经将分支事务提交，也就释放了锁资源；
3）TM 开启全局事务开始，将 XID 全局事务 id 放在事务上下文中，通过 openFeign 调用也将 XID 传入下游分支事务，每个分支事务将自己的 Branch ID 分支事务 ID 与 XID 关联；
4）第二阶段全局事务提交，TC 会通知各各分支参与者提交分支事务，在第一阶段就已经提交了分支事务，这里各各参与者只需要删除 undo_log 即可，并且可以异步执行，第二阶段很快可以完成；
5）第二阶段全局事务回滚，TC 会通知各各分支参与者回滚分支事务，通过 XID 和 Branch ID 找到相应的回滚日志，通过回滚日志生成反向的 SQL 并执行，以完成分支事务回滚到之前的状态，如果回滚失败则会重试回滚操作。
六 核心业务代码实现
dtx-seata-demo-bank1 实现如下功能：
1、张三账户减少金额，开启全局事务。
2、远程调用 bank2 向李四转账。
（1）Dao
@Mapper @Component public interface AccountInfoDao { //更新账户金额 @Update("update account_info set account_balance = account_balance + #{amount} where account_no = #{accountNo}") int updateAccountBalance(@Param("accountNo") String accountNo, @Param("amount") Double amount); }
（2） FeignClient 远程调用 bank2 的客户端
@FeignClient(value = "seata-demo-bank2", fallback = Bank2ClientFallback.class) // 指定调用微服务的服务名，以及服务熔断降级失败调用类 public interface Bank2Client { // 远程调用李四的微服务 @GetMapping("/bank2/transfer") String transfer(@RequestParam("amount") Double amount); } @Component public class Bank2ClientFallback implements Bank2Client { @Override public String transfer(Double amount) { return "fallback"; } }
（3）Service
@Service @Slf4j public class AccountInfoServiceImpl implements AccountInfoService { @Autowired private AccountInfoDao accountInfoDao; @Autowired private Bank2Client bank2Client; /** * 将 @GlobalTransactional 注解标注在全局事务发起的 Service 实现方法上，开启全局事务： * GlobalTransactionalInterceptor 会拦截 @GlobalTransactional 注解的方法，生成全局事务 ID(XID)，XID会在整个分布式事务中传递； * 在远程调用时，spring-cloud-alibaba-seata 会拦截 Feign 调用将XID传递到下游服务； */ @GlobalTransactional // 开启全局事务 @Transactional // 开启本地事务 @Override public void updateAccountBalance(String accountNo, Double amount) { log.info("******** Bank1 Service Begin ... xid: {}", RootContext.getXID()); // 扣减张三的金额 accountInfoDao.updateAccountBalance(accountNo, amount * -1); // 调用李四微服务，转账 String transfer = bank2Client.transfer(amount); if ("fallback".equalsIgnoreCase(transfer)) { // 调用李四微服务异常 throw new RuntimeException("调用李四微服务异常"); } if (amount == 2) { // 手动制造 bank1 张三转账异常 throw new RuntimeException("bank1 make exception 2"); } } }
（4）Controller
@RestController @Slf4j public class Bank1Controller { @Autowired private AccountInfoService accountInfoService; // 张三转账 @GetMapping("/transfer") public String transfer(Double amount) { accountInfoService.updateAccountBalance("1", amount); return "bank1" + amount; } }
dtx-seata-demo-bank2 实现如下功能：
李四账户增加金额。
（1）Dao
@Mapper @Component public interface AccountInfoDao { //更新账户 @Update("UPDATE account_info SET account_balance = account_balance + #{amount} WHERE account_no = #{accountNo}") int updateAccountBalance(@Param("accountNo") String accountNo, @Param("amount") Double amount); }
（2）Service
@Service @Slf4j public class AccountInfoServiceImpl implements AccountInfoService { @Autowired private AccountInfoDao accountInfoDao; @Transactional // 开启本地事务【此时全局事务是在张三那边开启全局事务】 @Override public void updateAccountBalance(String accountNo, Double amount) { log.info("******** Bank2 Service Begin ... xid: {}", RootContext.getXID()); // 李四增加金额 accountInfoDao.updateAccountBalance(accountNo,amount); // 制造李四增加金额异常 if (amount == 3) { throw new RuntimeException("bank2 make exception 2"); } } }
（3）Controller
@RestController @Slf4j public class Bank2Controller { @Autowired private AccountInfoService accountInfoService; // 接收张三转账 @GetMapping("/transfer") public String transfer(@RequestParam("amount") Double amount) { accountInfoService.updateAccountBalance("2", amount); return "bank2" + amount; } }
七 小结
讲解了传统 2PC（基于数据库 XA 协议）和 Seata 实现 2PC 的两种 2PC 方案，由于 Seata 的 0 侵入性并且解决了传统 2PC 长期锁资源的问题，所以推荐采用 Seata 实现 2PC ，保证数据的强一致性。
Seata 实现 2PC 要点：
1）全局事务开始使用 @GlobalTransactional标识；
2）每个本地事务方案仍然使用 @Transactional 标识；
3）每个数据都需要创建 undo_log 表，此表是 Seata 保证本地事务一致性的关键。
