浅谈Seata分布式事务管理实现原理

浅浅的花香味﹌ 2022-12-29 15:28 171阅读 0赞

前面写了常见的[分布式解决方案介绍][Link 1] 。这篇文章要写的seata是阿里的分布式解决方案中间件。

### Seata与2PC的区别 ###

> 相对于2pc，seata有独立的事务管理，整体实现也分两阶段，可以看做是2pc的演变。**而两种方案最大区别就是Seata支持AT，即异步事务的实现。**
> 
> 在2PC中，第一阶段开始事务操作就会锁定资源，直到二次提交完成后释放资源，在整个过程中对于每个分支事务来说资源锁定时间都依赖其他的分支事务。
> 
> 而在Seata中，每一个分支事务的提交操作都可以在第一阶段自主完成，降低了锁范围提高效率。而第二阶段中对于异常需要回滚的情况，是基于**`UNDO_LOG` **表中数据反解析 SQL 来达到回滚补偿的目的。

### Seata 分布式事务的几种角色 ###

**Transaction Coordinator(TC)**

> **全局事务协调者**，用来协调全局事务和各个分支事务（不同服务）的状态， 驱动全局事务和各个分支事务的回滚或提交。

**Transaction Manager™**

> ** 事务管理者**，业务层中用来开启/提交/回滚一个整体事务（在调用服务的方法中用注解开启事务）。

**Resource Manager(RM)**

> **资源管理者**，一般指业务数据库代表了**一个分支事务**（Branch Transaction），管理分支事务与 TC 进行协调注册分支事务并且汇报分支事务的状态，驱动分支事务的提交或回滚。

![54e80afd777b1d9d92204cd16c628989.png][]

### Seata中分布式事务管理实现 ###

**TM 开启事务后生成全局唯一的 XID**，会在各个调用的服务间进行传递。

**在第一阶段中**，各分支事务各自独立执行并尝试事务提交。首先会生成对应的回滚日志记录在UNDOLOG中，在本地事务提交前，各分支事务向 **全局事务协调者 TC** 注册分支 ( Branch Id)使得**TC** 将其纳入XID 对应全局事务TM的管辖内 ，然后分支事务为要修改的记录申请全局锁 ，为这条数据加锁，而如果一直拿不到锁那就需要回滚本地事务。如果分支事务能拿到锁顺利执行并提交，业务数据的更新和前面生成的 UNDO LOG 数据一并提交，**并将本地事务提交的结果上报给全局事务协调者 TC，**第一阶段结束。

**第二阶段是根据各分支的决议做提交或回滚**。**如果决议是全局提交**，此时各分支事务已提交并成功，这时全局事务协调者（TC） 会向分支发送第二阶段的请求。收到 TC 的分支提交请求，该请求会被放入一个异步任务队列中，并马上返回提交成功结果给 TC。异步队列中会异步和批量地根据 Branch ID 查找并删除相应 UNDO LOG 回滚记录。**如果决议是全局回滚**，过程比全局提交麻烦一点，`RM` 服务方收到 `TC` 全局协调者发来的回滚请求，**通过 `XID` 和 `Branch ID` 找到相应的回滚日志记录**，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。

![20201124150507311.png_pic_center][]                            ![20201124151737116.png_pic_center][]

[Link 1]: https://blog.csdn.net/qq_29569183/article/details/111589621
[54e80afd777b1d9d92204cd16c628989.png]: /images/20221120/509d6bdb875d4e7aa4cc633178922716.png
[20201124150507311.png_pic_center]: https://img-blog.csdnimg.cn/20201124150507311.png?#pic_center
[20201124151737116.png_pic_center]: /images/20221120/5bf4c5f1fecf4e37b28ec5409171cdd9.png