事务四大特性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回滚自己的事务分支。
有一个undo_log表,表中有数据,branch_id 事务分支id,xid 全局事务id,rellback_info(json数据,解析后里面有之前的镜像beforeImage,里面记录更改之前的数据,一个之后的镜像afterImage 记录更改之后的数据),事务提交时已经更改了数据,发现有其他事务无法完成,全部事务回滚,更改了的数据根据beforeImage里的数据生成update 语句改回之前的数据,这就是AT 模式中得事务回滚,实质是反向补偿
AT模式
1.两阶段提交
2.二阶段提交还是回滚,是全自动化得,开发者不需要任何额外得工作
3.代码零侵入
4.实现得原理,有一个undo_log表
5.所谓的回滚,实际上是一个反向补偿
一阶段
-
解析SQL:得到SQL的类型(update),表名,条件等信息
-
查询前镜像:根据解析得到的条件信息,生成查询语句,定位数据,得到前镜像
-
执行业务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规范的
- XA中的回滚,是真正的回滚,而不是反向补偿
- XA对资源锁定的时间过长,导致并发效率很低
- XA是一种强一致性的分布式事务解决方案,而AT 和TCC 都属于最终一致性
其他方案
本地消息:stock->account->order,有一个公共的第三张表,当stock执行的时候,向这张表中添加一条记录,记录中有一个状态为1,account执行完之后,这个状态为2,order执行完这个状态为3
利用消息中间件来做,RocketMQ Half Message