Seata

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 记录。