Seata
一:什么是事务？
1.1)什么是事物?
事务是逻辑上的一组执行单元，要么都执行，要么都不执行.
1.2)事物的特性(ACID)
ACID是指数据库管理系统DBMS中事物所具有四个特性 eg:在数据库系统中，一个事务由一系列的数据库操作组成一个完整的逻辑过程，比如银行转账，从原账户扣除金额，目标账户增加金额
①:atomicity【原子性】
原子性表现为操作不能被分割，那么这二个操作 要么同时完成，要么就全部不完成，若事务出错了，那么事务就会回滚
②:Consistency【一致性】
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务开始前是一个一致状态，事务结束后是另一个一致状态， 事务将数据库从一个一致状态转移到另一个一致状态
③:Isolation【隔离性】
所谓的独立性就是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务还未提交，它所访问的数据就不受未提交事务的影响。 换句话说，一个事务的影响在该事务提交前对其它事务是不可见的
④:Durability【持久性】
若事务已经提交了，那么就回在数据库中永久的保存下来
二:什么是分布式事务？
分布式事务
分布式事务：就是把各个节点上的微服务的本地事务 结合起来，看成一个整体的事务。
分布式事务组成部分
①:事务参与者
(就是我们的一个一个的微服务，比如订单服务,库存服务)
②:资源服务器
(说白了就是我们的对应微服务连接的数据库 比如订单库，库存库)
③:事务管理器
(用于决策各个事务参数者的提交和回滚)
二阶段提交
1.准备阶段
1.准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交。 第一阶段会占用数据库连接
2.提交阶段
如果协调者收到了参与者的失败消息或者超时，直接给每参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
三:什么是Seata?
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案(AT模式是阿里首推的模式,阿里云上有商用版本的GTS[Global Transaction service 全局事务服务] ) 。
1.角色划分
RM(ResourceManager 资源管理者)
理解为 我们的一个一个的微服务 也叫做事务的参与者.
TM(TranactionManager 事务管理者)
也是我们的一个微服务，充当全局事务的发起者(决定了全局事务的开启，回滚，提交等)
凡是我们的微服务中标注了@GlobalTransactional ，那么该微服务就会被看出一个TM。我们业务场景中订单微服务就是一个事务发起者,同时也是一个RM
TC(TranactionController 全局事务的协调者)
这里就是我们的Seata-server，用来保存全局事务，分支事务，全局锁等记录，然后会通知各个RM进行回滚或者提交.
2.整体机制(两阶段提交协议的演变)
核心逻辑
set autocommit = 0;
select * from product where product_id=1 for update;
UPDATE Product SET count = count ‐ 1 WHERE product_id=1;
select * from product where product_id=1 for update;
commit;
对应的核心代码逻辑
connectionProxy.setAutoCommit(false);
return new LockRetryPolicy(connectionProxy.getTargetConnection()).execute(()‐> {
T result = executeAutoCommitFalse(args);
connectionProxy.commit();
return result;
});
2.1)工作原理
执行业务SQL update product set name = ‘GTS’ where name = ‘TXC’;
第一阶段:
1:解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where id=‘1’）等相关的信息。
2:查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。 select id, name, since from product where name = ‘TXC’;
3:执行业务 SQL：更新这条记录的 name 为 ‘GTS’。 update product set name = ‘GTS’ where name = ‘TXC’;
4:查询后镜像：根据前镜像的结果，通过 主键 定位数据 select id, name, since from product where id = 1`;
5:插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
{
“branchId”:641789253,
“undoItems”:[
{
“afterImage”:{
“rows”:[
{
“fields”:[
{
“name”:“id”,
“type”:4,
“value”:1
},
{
“name”:“name”,
“type”:12,
“value”:“GTS”
},
{
“name”:“since”,
“type”:12,
“value”:“2014”
}
]
}
],
“tableName”:“product”
},
“beforeImage”:{
“rows”:[
{
“fields”:[
{
“name”:“id”,
“type”:4,
“value”:1
},
{
“name”:“name”,
“type”:12,
“value”:“TXC”
},
{
“name”:“since”,
“type”:12,
“value”:“2014”
}
]
}
],
“tableName”:“product”
},
“sqlType”:“UPDATE”
}
],
“xid”:“xid:xxx”
}
6:提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。
7:本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
8:将本地事务提交的结果上报给 TC。
二阶段回滚
1:收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作
2:通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
3:数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改
4:根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句
5:提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。
提交
1:收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
2:异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。