分布式事务
2023-02-15 11:40:14 0 举报AI智能生成
登录查看完整内容
seata
作者其他创作
大纲/内容
一致性
c
可用性
a
分区容错性
p
cp
ap
最多同时满足两个
CAP定理
基本可用
BA
软状态
S
最终一致性
E
保证一致性，就牺牲了可用性
保证基本可用就行了
不可用，把你剔除掉
当你恢复的时候，再把你加回来
CP
保证了可用性，就牺牲一致性
暂时的不一致是没关系
只要最后数据是一致的就行了
AP
对CAP定理的一个补足
BASE理论
各个分支事务先不提交
处理完后统一通个气
如果都成功了，那就一起提交
如果有一个失败了，那就全部回滚
各个分支事务处理完后，直接提交
整个流程结束之后，通个气
如果都成功，那就啥都不用做
如果有一个失败了，就全部回滚(反向更新)
分布式事务的启发
理论知识
事务协调者
bat命令行启动就行
配置服务名称
指定注册中心
指定配置中心
改配置文件
将全局事务、分支事务存到数据库
配置数据库的信息，数据库、用户名、密码
去配置中心写它的配置
启动
前置准备
需要我们自己部署
TC
资源管理器
RM
事务管理者
TM
分布式事务原理
默认的依赖版本比较低
需要手动排除，然后重新导
引入seata包，重新指定版本
指定使用的注册中心
配置nacos的地址信息
配置namespace、group、serviceName(填写TC的服务名称)
无法直接指定
先配置事务组
根据事务组做映射
配置集群
修改配置文件，需要配置TC的地址
微服务集成分布式事务
基于数据库XA规范
CP类型
全局事务注册到事务协调者，开始全局事务
注册分支事务
不提交，挂起状态
分支事务执行
所有的都执行完成之后，由TC判断是提交还是回滚
原理流程
基于XA规范实现的，实现起来很简单
没有代码侵入
强一致性
优点
数据库得支持XA规范
保证强一致性，意味着性能很差
缺点
优缺点
修改配置文件，配置使用XA模式
给所有参与的微服务
@GlobalTransational
给全局事务入口
使用方式
XA
没有数据库的限制
AP类型
TM开启全局事务
RM注册各个分支事务
生成一个快照
分支事务做完提交
第一阶段
TC判断各个分支事务的执行状态
异步删快照
如果都成功了
基于快照进行数据恢复
删快照
如果有一个失败
第二阶段
引入了全局锁概念
解决写丢失的问题
优化1
如果两个事务，一个事务受seata管理，另一个事务不受seata管理
在这种情况下，全局锁就失去了作用
引入了前后快照
是一致的，表示没有人修改过，可以正常回滚
不一致，表示中间已经有其他人修改过了，无法回滚了，需要人工介入
回滚之前要先比较一下后快找与数据库的数据是否一致
优化2
XA是CP，AT是AP
XA依赖数据库，AT不依赖数据库
AT性能更优
XA锁定资源，AT不会
和XA区别
不受数据影响
性能会比XA好一些
无代码侵入性
最终一致性的
有可能会导致数据无法回滚
TC的数据库需要导入一张全局锁的表(lock_table)
有参与事务的每个微服务的数据库都要导入一张undo_log表（用来记录快照数据）
分布式事务的模式设置为：AT
分布式事务全局事务的方法入口添加一个注解
AT
资源的预留
Try
T
业务的提交
Confrim
C
资源的释放
Cancel
RM注册分支事务
直接提交
Try进行资源预留
TC检查各个分支事务
删除预留的资源
如果都成功
回滚资源
执行cancel
如果失败了
快
不依赖数据库，也不用快照，也不需要全局锁
代码有侵入性，需要自己编码实现TCC过程
考虑接口的幂等性
浪费程序员
还没有进行资源预留
做空回滚的时候，插入一条数据，标记状态是回滚状态
执行了回滚操作
判断预留表里面，有没有资源预留的记录
空回滚
做了空回滚之后
来进行资源的预留
没有，可以预留
有，不能进行资源的预留了
判断表里面，这个事务id有没有对应的数据
业务悬挂
@LocalTCC
需要编写一个接口类
@TwoPhaseBusinessAction(name=\"try-method\
try
confirm
cancel
写三个方法
RootConetxt
BussinessActionContext
获取全局事务id
不需要
留着这条记录，以后发生业务悬挂或者空回滚可以拿来判断
cancel的时候，需要预留的记录删除掉吗？
然后实现这些接口
需要编写三个接口
TCC
长事务
没有任何隔离机制
应用场景比较少
SAGA
事务模式
针对TC来做集群
异地容灾
group
service
cluster
nacos cluster
关于事务组的这一部分配置放到配置中心去
配置的热更新
集群结构
针对啥？
高可用
自由主题
分布式事务
0 条评论
回复 删除
下一页
