事务的ACID原则:
A:原子性:
C:一致性:
I:隔离性:
D:持久性:
分析分布式服务得事务问题:
在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样得事务就是分布式事务。
分布式事务的理论基础:
CAP定理:
分布式三个指标:
一致性:用户访问分布式系统中的任意节点,得到的数据必须一致。叫做一致性
可用性:用户访问集群中的任意健康节点,必须得到响应,而不是超时或拒绝。叫做可用性
分区容错性:因为网络故障或其他原因导分布式系统中的部分节点与其他节点失去连接,形成独立分区。叫做分区性
在集群出现分区时,整个系统也有持续对外提供服务。叫做容错性
分布式系统无法同时满足这三个指标,这个结论就叫做CAP定理。
总结:
分布式系统通过网络连接,一点会出现分区问题(P)
当分区出现时,系统不能同时满足一致性(C)和可用性(A)
问:elasticsearch集群是CP还是AP?
答:ES集群出现分区时,故障节点会被剔除集群,数据分片会重新分配到其他节点,保证数据一致。因此是低可用性、高一致性,属于CP。 注:eureka集群属于AP,nacos默认是AP不过可修改
BASE理论三个思想:
BASE理论是对CAP的一种解决方案,包括三个思想:
Basically Available(基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态
Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。
如何解决分布式事务 子事务的一致性问题:
AP模式(柔性事务):各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致
CP模式(刚性事务):各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。
解决分布式事务的思想和模型:
1.全局事务:整个分布式事务
2.分支事务:分布式事务中包含的每个子系统的事务
3.最终一致思想:各分支事务分别执行并提交,如果有不一致的情况,再想办法恢复数据
4.强一致思想:各分支事务执行完业务不要提交,等待彼此结果,而后同一提交或回滚。
Seata架构
Seata事务管理中有三个重要的角色:
TC-事务协调者(需要单独部署):维护全局和分支事务的状态,协调全局事务提交或回滚。
TM-事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM-资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
微服务如何集成Seata:
1.引入依赖
2.添加配置文件
3.在创建订单的方法上加注解:@GlobalTransactional
Seata提供了四种不同的分布式事务解决方案:
XA模式(CP):强一致性分阶段事务模式,牺牲了一定的可用性,无业务侵入
TCC模式(AP):最终一致的分阶段事务模式,有业务侵入
AT模式(AP):最终一致的分阶段事务模式,无业务侵入,也是Seata的默认模式
SAGA模式(AP):长事务模式,有业务侵入。
XA模式的优点:
强一致性,满足ACID原则,用的是原生事务,要么全部成功,要么全部失败。一般的关系型数据库都支持,实现简单,没代码侵入
XA模式的缺点:
AT模式与XA模式的区别:
XA模式在第一阶段不提交事务,会占用每一个数据库的库锁,等所有的都执行完毕之后,才会一起提交
AT模式在第一阶段直接提交,不锁定资源
XA模式是利用原生的机制进行回滚,AT模式利用数据快照实现数据回滚
XA模式是强一致性,AT模式是最终一致性
AT模式工作原理:
1.注册分支事务
2.记录undo-log(数据快照)
3.执行业务sql并提交
4.报告事务状态
5.如果事务都成功了则提交事务,删除快照。如果有一个分支事务失败了,则读取快照,恢复数据。
AT模式回滚原理:
AT模式脏读问题:
Seata里面事务直接的隔离级别默认是:读未提交,如果读到别人还未提交的数据就会出现脏读问题
解决方法:可以通过select语句后面加上 for update语句,这样他们在提交数据读数据的时候会先获取全局锁,如果没有获取全局锁会不断的尝试去获取,直到拿到全局锁,这样就不会出现脏读问题,不过这样性能不太好,如果没必要,最好不要加
AT模式脏写问题:
AT模式优点:
1.一阶段完成直接提交事务,释放数据库资源,性能比较好
2.利用全局锁实现读写隔离
3.没有代码侵入,框架自动完成回滚和提交
AT模式的缺点:
1.两阶段之间属于软状态,属于最终一致
2.框架的快照功能会影响性能,但比XA模式要好很多
TCC模式原理:
TCC模式与AT模式相似,每阶段都是独立事务,不同的是TCC是通过人工编码来实现数据恢复的,需要实现三个方法:
1.Try(尝试执行):资源的检测和预留。
2.Confirm(提交):完成资源操作业务;要求Try成功Confirm一定要能成功。
3.Cancel(回滚):预留资源释放,可以理解为Try的反向操作。
TCC的优点:
1.第一阶段直接提交事务,释放数据库资源,性能好
2.相比AT模式,不要生成快照,也不需要全局锁,性能是最好的
3.不依赖数据库事务,依赖于代码
TCC缺点:
1.有代码侵入,需要人为编写三个方法,麻烦
2.也不是一致性的 是最终一致性
3.需要考虑到提交和回滚失败的可能性,做好幂的处理等。
Saga模式:
Saga模式是seata提供的长事务解决方案,分为两个阶段:
1.一阶段:直接提交本地事务
2.二阶段:成功则什么都不做,失败则通过编写补偿业务来回滚
Saga模式的优点:
1.事务参与者可用基于事件驱动实现异步调用,吞吐高
2.一阶段直接提交事务,无锁,性能好
3.不要编写Tcc中的三个阶段,实现简单
Saga模式的缺点:
1.软状态持续时间不确定,时效性差
2.没有锁,没有事务隔离,会有脏写
四种模式对比:
XA | AT | TCC | SAGA | |
---|---|---|---|---|
一致性 | 强一致 | 弱一致 | 弱一致 | 最终一致 |
隔离性 | 完全隔离 | 基于全局锁隔离 | 基于资源预留隔离 | 无隔离 |
代码侵入 | 无 | 无 | 有,要编写3个接口 | 有,要编写状态机和补偿业务 |
性能 | 差 | 好 | 非常好 | 非常好 |
场景 | 对一致性、隔离性有高要求的业务 | 基于关系型数据库的大多数分布式事务场景都可以 | 对性能要求较高的事务,有哦非关系型数据库要参与的事务 | 业务流程长、业务流程多,参与者包含其他公司或遗留系统服务,无法提供TCC模式要求的三个接口 |