首页  思维导图  详情



 



分布式事务

2023-02-15 11:40:14   0  举报





AI智能生成

seata

后端开发

模板推荐

作者其他创作

大纲/内容

理论知识

CAP定理

一致性

可用性

分区容错性

最多同时满足两个

BASE理论

基本可用

软状态

最终一致性

对CAP定理的一个补足

保证一致性，就牺牲了可用性

保证基本可用就行了

不可用，把你剔除掉

当你恢复的时候，再把你加回来

保证了可用性，就牺牲一致性

暂时的不一致是没关系

只要最后数据是一致的就行了

分布式事务的启发

各个分支事务先不提交

处理完后统一通个气

如果都成功了，那就一起提交

如果有一个失败了，那就全部回滚

各个分支事务处理完后，直接提交

整个流程结束之后，通个气

如果都成功，那就啥都不用做

如果有一个失败了，就全部回滚(反向更新)

分布式事务原理

事务协调者

需要我们自己部署

bat命令行启动就行

前置准备

改配置文件

指定注册中心

配置服务名称

指定配置中心

去配置中心写它的配置

将全局事务、分支事务存到数据库

配置数据库的信息，数据库、用户名、密码

启动

资源管理器

事务管理者

微服务集成分布式事务

引入seata包，重新指定版本

默认的依赖版本比较低

需要手动排除，然后重新导

修改配置文件，需要配置TC的地址

指定使用的注册中心

配置nacos的地址信息

配置namespace、group、serviceName(填写TC的服务名称)

配置集群

无法直接指定

先配置事务组

根据事务组做映射

事务模式

XA

基于数据库XA规范

CP类型

原理流程

全局事务注册到事务协调者，开始全局事务

注册分支事务

分支事务执行

不提交，挂起状态

所有的都执行完成之后，由TC判断是提交还是回滚

优缺点

优点

基于XA规范实现的，实现起来很简单

没有代码侵入

强一致性

缺点

数据库得支持XA规范

保证强一致性，意味着性能很差

使用方式

给所有参与的微服务

修改配置文件，配置使用XA模式

给全局事务入口

@GlobalTransational

没有数据库的限制

AP类型

最终一致性

原理流程

第一阶段

TM开启全局事务

RM注册各个分支事务

分支事务做完提交

生成一个快照

第二阶段

TC判断各个分支事务的执行状态

如果都成功了

异步删快照

如果有一个失败

基于快照进行数据恢复

删快照

优化1

引入了全局锁概念

解决写丢失的问题

优化2

如果两个事务，一个事务受seata管理，另一个事务不受seata管理

在这种情况下，全局锁就失去了作用

引入了前后快照

回滚之前要先比较一下后快找与数据库的数据是否一致

是一致的，表示没有人修改过，可以正常回滚

不一致，表示中间已经有其他人修改过了，无法回滚了，需要人工介入

和XA区别

XA是CP，AT是AP

XA依赖数据库，AT不依赖数据库

XA锁定资源，AT不会

AT性能更优

优缺点

优点

不受数据影响

性能会比XA好一些

无代码侵入性

缺点

最终一致性的

有可能会导致数据无法回滚

使用方式

TC的数据库需要导入一张全局锁的表(lock_table)

有参与事务的每个微服务的数据库都要导入一张undo_log表（用来记录快照数据）

分布式事务的模式设置为：AT

分布式事务全局事务的方法入口添加一个注解

@GlobalTransational

TCC

Try

资源的预留

Confrim

业务的提交

Cancel

资源的释放

最终一致性

原理流程

第一阶段

TM开启全局事务

RM注册分支事务

Try进行资源预留

直接提交

第二阶段

TC检查各个分支事务

如果都成功

删除预留的资源

如果失败了

执行cancel

回滚资源

优缺点

优点

快

不依赖数据库，也不用快照，也不需要全局锁

缺点

浪费程序员

代码有侵入性，需要自己编码实现TCC过程

考虑接口的幂等性

最终一致性

空回滚

还没有进行资源预留

执行了回滚操作

做空回滚的时候，插入一条数据，标记状态是回滚状态

判断预留表里面，有没有资源预留的记录

业务悬挂

做了空回滚之后

来进行资源的预留

判断表里面，这个事务id有没有对应的数据

没有，可以预留

有，不能进行资源的预留了

使用方式

需要编写三个接口

需要编写一个接口类

@LocalTCC

写三个方法

try

@TwoPhaseBusinessAction(name="try-method", commitMethod="confirm-method", rollbackMethod="cancel-method")

confirm

cancel

然后实现这些接口

获取全局事务id

RootConetxt

BussinessActionContext

cancel的时候，需要预留的记录删除掉吗？

不需要

留着这条记录，以后发生业务悬挂或者空回滚可以拿来判断

SAGA

长事务

没有任何隔离机制

应用场景比较少

高可用

针对啥？

针对TC来做集群

集群结构

异地容灾

nacos cluster

group

service

cluster

配置的热更新

关于事务组的这一部分配置放到配置中心去

自由主题

 Collect

Get Started

分布式事务

 Collect

Get Started

分布式事务

 Collect

Get Started

分布式系统10个坑

 Collect

Get Started

分布式事务框架 seata





0 条评论

下一页