不要光说理论，分布式事务2阶段提交理论的落地方案seata

背景

最近公司准备把支付功能单独抽成一个公用的支付服务系统。这样一来在调用支付时就要考虑分布式事务问题。提起分布式事务，就必须得遵循CAP理论。

分布式事务所有解决思路：把一个分布式事务拆分成多个本地事务。

理论依据

两阶段提交 （2PC） 理论 。

角色：全局事务管理者 事务参与者

1 准备阶段（锁定资源，执行事务，但不提交，记录Undo/Redo 日志）

Undo 日志是记录修改前的数据，用于数据库回滚。

Redo 日志是记录修改后的数据，用于提交事务后，写入数据文件

2 提交事务阶段（事务管理者发出决策，事务参与者开始提交或者回滚本地事务，释放资源）。

成功时序图：

失败时序图：

提醒： 这里的redo,undo 都是数据库日志实现，数据库需要支持事务，所以是基于数据库的。

存在的问题

1. 单点问题 ：事务管理者宕机，导致参与者都被阻塞,整个数据库群不可用。
2. 同步阻塞问题：在2阶段执行过程中，参与者一直要等待协调者。
3. 存在数据不一致风险，网络通信中其实这是个无法完全解决的问题。

三阶段提交

在2阶段提交的基础上，多出一个询问阶段，并在参与者中也引入超时机制。

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。虽然 3PC 用超时机制，解决了协调者故障后参与者的阻塞问题，但与此同时却多了一次网络通信，性能上反而变得更差，生产上一般不会用。

2PC具体的解决方案：

seata 是阿里开源的分布式事务框架

高性能，对业务0侵入的，工作在应用层的中间件。

角色：

• Transaction Coordinator(TC): 全局事务协调者(需要独立部署)，用来协调全局事务和各个分支事务（不同服务）的状态， 驱动全局事务和各个分支事务的回滚或提交。
• Transaction Manager?: 事务管理者，业务层中用来开启/提交/回滚一个整体事务（在调用服务的方法中用注解开启事务）。
• Resource Manager(RM): 资源管理者，一般指业务数据库代表了一个分支事务（Branch Transaction），管理分支事务与 TC 进行协调注册分支事务并且汇报分支事务的状态，驱动分支事务的提交或回滚。

成功时序图

失败时序图

提醒：seata 在第一阶段就提交了事务，释放了锁。在第二阶段都成功时，可以异步通知，所以性能高，不会有阻塞。

实战步骤

1. 下载seata-server，并配置file.conf,registry.conf（也可以不配置默认本地文件配置）。
2. 业务项目引入相应的jar包。
3. 业务数据库创建undo_log日志表
4. 修改业务配置文件application.xml
5. 在业务发起者端开启全局事务@GlobalTransactional

其中配置可以参考项目的说明文档

下一章节演示具体的案例项目。