Seata

  • Post author:
  • Post category:其他


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



版权声明:本文为Megetood原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。