SeataAT分布式事务解决方案

Seata-AT分布式事务解决方案（2PC）

一、购物场景

二、关键角色

1. 事务管理器（TM）：决定何时全局事务开始和结束，是各种事务指令的源头（司令官）。
   定义全局事务的边界，就是主业务中组合调用各分支方法的地方，通过打@GlobalTransactional注解声明。
   

2. 事务协调器（TC）：负责转发事务相关的各个指令，这里由Seata-Server担任（传令官）。
   

3. 资源管理器（RM）：分支事务的执行者（大兵）。
   Seata对Spring的@Transactional注解进行了扩展，使其支持与Seata交互，
   

   • 向Seata注册分支事务
   • 开启本地事务
   • 提交本地事务
   • 向Seata上报本地事务执行成功或失败
     来实现分布式事务。
     
     

三、过程（两阶段）

1. TM向通过Seata向所有RM下达开启全局事务的指令，各RM执行本地事务并将执行结果通过Seata报告回TM，在RM上，若没有异常，本地事务会提交的。
   
2. TM根据各RM返回的执行报告，通过异常捕获的方式，若没有得到异常则通过Seata向各RM下发全局提交指令，否则下达全局回滚指令，个RM再各自执行全局事务层面的提交或回滚操作。
   

四、Seata-AT如何实现全局事务的提交和回滚

单个RM顺利执行完本地事务后，是会提交本地事务的，数据库已完成了持久化操作，本地事务区也已被清空，那全局的提交或回滚又该怎么实现呢？

Seata需要在各RM所使用的数据库创建一张叫undo_log的回滚日志表，Seata利用sqlParser三方包解析出每次分支事务SQL语句，得到关键字、字段等信息，通过拼接，生成对应的逆向SQL语句，这个表里存的就是逆向语句。

• 当RM收到全局提交指令时，直接删除对应的undo_log记录就可以了。
• 当RM收到全局回滚指令时，则需要执行对应的undo_log记录来将数据还原到本地事务执行之前的状态。
  

五、Seata-AT如何解决并发场景的脏读和脏写问题

问题描述

整体思路是通过拼接SELECT FOR UPDATE语句，利用数据库锁来实现的。