分布式事务框架 JTA,TCC,seata

JTA  AND TCC

 

需要一个框架协调者: 当两个同时成功了才执行commit 否则执行rollback

二阶段 : 第一阶段预提交sql  第二部执行commit或者rollback

XA: 两阶段提交

JTA: java规范的两阶段提交  (中间件)atomikos (jta规范)

 

atomikos 将jdbc的连接封装了一层 用atomikos 操作sql的事物

 

CAP  BASE 概念

 

 

其中分区容错 是必须满足的  (两个分布式之间网络的通讯有可能断开数据不能同步,分区容错性解决了两个分布式系统就算网络断开也可以独立通讯) 至少保证访问单个的也可以访问

 

一致性和可用性只能满足其一

一致性(当两个服务之间不能通信,往web1中插入数据化web2中查不到的,返回提示没有这个数据或者数据未同步)

可用性(当两个服务之间不能通信,往web1中插入数据化web2中查不到的,返回null 查不到)

zookeeper cp 一致性

 

base   把cap 调优 折中处理  在特定的业务下满足一点一致性并且也满足一些可用性

 

 

 

 

和jta的区别  事物的锁密度小  并发变强

总结 : jta的方式对于事物是一个一个排队执行的  ,事物锁的强度大, 耗性能和时间 ,对于单个项目可以考虑

tcc : 虽然他的性能更高,锁的强度小,但是代码侵入性很大, 你需要自己写代码去回滚 .

 MQ:   还有使用消息队列的方式去提交回滚事物

 

SEATA

每一个对应自己的db

 

 TC:事务协调者  全局的  用于记录和统计事物 

 TM: 事务管理者  事务的发起 管理分支  用于创建全局事物 真正做事的

  RM:资源管理器   一个代理的连接  返回一个数据库连接

Seata解析-TM、RM、TC交互流程梳理  https://blog.csdn.net/weixin_38308374/article/details/108329792

@Transactional  spring的事务注解 :  1.建立连接 2.开启事务 3.执行方法 4.提交或者回滚

 

将每个系统的事物注册到事物管理者里面  第一个注册进去的事物会有一个groupid  会保存起来 , 同一个方法中使用不同的事物  事物的grouypid是相同的,为了让他进行同时回滚操作

事物协调者发现异常后通知各个分支事物回滚

groupid  的传递 是通过拦截器