什么是分布式事务问题?
答:一个业务跨越多个数据源和多个服务。
理论基础
CAP定理
分布式系统三大指标:一致性,可用性,分区容错性。
一致性(C):用户访问分布式系统的任意节点,得到数据必须一致。
可用性(A):用户访问集群任意健康节点,必须的得到访问,不得拒接。
分区(P):因为故障或其他原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
容错(P):在集群出现分区时,整个系统也要持续对外提供服务。
CAP为什么不能同时满足?
答:因为分区之间的通信可能通信失败。(即网络问题肯定会出现)
BASE理论
三个思想:基本可用,软状态,最终一致性。
基本可用(BA):分布式系统出现故障,允许损失部分可用性,即保证核心可用。
软状态(S):在一定时间内,允许出现中间状态,比如临时的不一致状态。
最终一致性(E):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。
Seata框架
Seata三个重要角色:事务协调者(TC),事务管理器(TM),资源管理器(RM)。
XA模式
成功模型
失败模型
Seata XA模式
黑色字体为第一阶段,蓝色为第二阶段
优点:强一致性,实现简单,无代码侵入。
缺点:第一,性能差,因为是事务提交是一起提交,中途有一个失败全部都要回滚,中间不释放锁,所以造成堵塞性能较差。第二,是基于依赖性数据库事务实现,如果数据库不具有事务则不可用。
实现步骤
AT模式
AT与XA模式最大区别
XA模式一阶段不提交事务,锁定资源不释放锁;AT模式一阶段直接提交,不锁定资源。
XA模式依赖数据库机制实现回滚;AT模式利用数据快照实现数据回滚。
XA模式强一致;AT模式最终一致。
存在脏写问题:回滚之前其他事务修改了数据照成回滚时是拿着最初的快照回滚,导致覆盖了其他事务修改的数据,相对其他事务就白修改了。
解决方案
设置全局锁
全局锁是解决数据脏写问题。
后快照是解决其他事务修改数据导致数据不一致问题。
TCC模式
定义:模式和AT相似,每个阶段都是独立阶段,不同的是通过人工编码来实现数据恢复。
三个实现方法:Try,Confirm,Cancel。
Try:资源的检测和预留。
Confirm:完成资源操作业务;要求Try成功Confirm一定要能成功。
Cancel:预留资源释放,可以理解为try的反向操作。
TCC模式下空回滚和业务悬挂
什么是空回滚?
答:当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作,这时cancel不能做回滚,就是空回滚
什么是业务悬挂?
答:对于已经空回滚的业务,如果以后继续执行try,就永远不可能confirm或cancel,这就是业务悬挂
使用方法
接口准备:
接口上使用@LocalTCC注解
Try方法上使用 @TwoPhaseBusinessAction注解, 配置好Try、Confirm、Cancel方法
需要传递的参数使用 @BusinessActionContextParameter注解配置
Confirm、Cancel方法需要boolean返回值
实现该接口,编写业务逻辑即可
幂等性:Confim、Cancel阶段不论网络原因或者业务异常,都会根据日志记录重复执行操作,所以需要保持接口的幂等性,也就是最多执行一次
Saga模式
工作模式:第一阶段直接提交事务,第二阶段失败做补偿业务,成功就什么都不做。
优点:1,基于事件驱动异步调用事务,吞吐量大。2,第一阶段就提交事务,不需要锁,性能好。3,不用编写TCC中三个接口,不费程序员,简单。
缺点:1,软状态持续时间不确定,时效性差。2,没有锁,没有事务隔离,存在脏写