Seata总结

事务四大特性ACID

原子性(Atomicity):事务作为一个整体被执行,包含在其中的对数据库的操作要么全部被执行,要么都不执行。

一致性(Consistency):事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外,一致性还有另外一层语义,就是事务的中间状态不能被观察到(这层语义也有说应该属于原子性)。

隔离性(Isolation):多个事务并发执行时,一个事务的执行不应影响其他事务的执行,如同只有这一个操作在被数据库所执行一样。

持久性(Durability):已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时,此操作将不可逆转。

CAP: 一致性,可用性,分区容错。

base理论:

基本可用:允许服务降级或者允许响应时间受到一定损失

软状态:允许同步数据的时候出现一定时间延迟

最终一致性:经过一段时间的同步数据之后,最终都能够达到一个一致的状态

Seata

分布式事务 = n 个本地事务。通过事务管理器,达到 n 个本地事务要么全部成功,要么全部失败。

分布式解决方案:

1.通过消息中间件,将分布式事务转为本地事务

2.Seata:AT、TCC、XA等

反向补偿:TM根据阶段1各个RM prepare的结果,决定是提交还是回滚事务。如果所有的RM都prepare成功,那么TM通知所有的RM进行提交;如果有RM prepare回执NO的话,则TM通知所有RM回滚自己的事务分支。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mip4ufZt-1667380766002)(Seata/image-20220621165821933.png)]

有一个undo_log表,表中有数据,branch_id 事务分支id,xid 全局事务id,rellback_info(json数据,解析后里面有之前的镜像beforeImage,里面记录更改之前的数据,一个之后的镜像afterImage 记录更改之后的数据),事务提交时已经更改了数据,发现有其他事务无法完成,全部事务回滚,更改了的数据根据beforeImage里的数据生成update 语句改回之前的数据,这就是AT 模式中得事务回滚,实质是反向补偿

AT模式

1.两阶段提交

2.二阶段提交还是回滚,是全自动化得,开发者不需要任何额外得工作

3.代码零侵入

4.实现得原理,有一个undo_log表

5.所谓的回滚,实际上是一个反向补偿

一阶段

  1. 解析SQL:得到SQL的类型(update),表名,条件等信息

  2. 查询前镜像:根据解析得到的条件信息,生成查询语句,定位数据,得到前镜像

  3. 执行业务SQL:更新镜像的结果,通过

收到TC的分支回滚请求,开启一个本地事务

回滚根据xid 和branch_id 找到相应的undolog 记录

拿后镜像和前镜像数据经行比较,有不同就说明数据被修改过,根据配置策略来处理

根据undolog 中的前镜像和业务的SQL的相关信息生成并执行回滚的语句

提交本地事务。将本地事务的执行结果上报给TC

哪里需要做分布式事务,加一个@GlobalTransactional

TCC

Try-Confirm-Cancel

1.业务侵入

2.不需要 undo_log表

3.回滚也是反向补偿

4.提交、回滚都是开发者自己实现

XA

XA规范,数据库支持分布式事务的规范,目前想MySQL、Oracle、SQLServer等,都是支持XA规范的

  1. XA中的回滚,是真正的回滚,而不是反向补偿
  2. XA对资源锁定的时间过长,导致并发效率很低
  3. XA是一种强一致性的分布式事务解决方案,而AT 和TCC 都属于最终一致性

其他方案

本地消息:stock->account->order,有一个公共的第三张表,当stock执行的时候,向这张表中添加一条记录,记录中有一个状态为1,account执行完之后,这个状态为2,order执行完这个状态为3

利用消息中间件来做,RocketMQ Half Message

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值