分布式事务--ACP和2cp-2阶段提交--Tcc补偿事务-----面试简单总结

传统的ACID分别是(mysql , oracle sqlserver)

  • A:(Atomicity) 原子性
  • C:(Consistency)一致性
  • I:(Isolation)隔离性
  • D:(Durability)持久性

ACP

  • A:(Arailability)可用性
  • C:(Consistency)强一致
  • P:(Partition–tolerance)分区容错性

在实际开发分布式系统中我们只能满足两种,分区容错性是分布式 系统中必然要使用的,在架构的时候往往需要把精力花费到,如何根据业务的特点在 (一致性)和(可用性)之间求平衡

2pc垮库事务(JTA/XA)

首先这个2cp 是实现跨库二阶段提交
再面试过程中 会问到 怎么实现 垮库事务 其实可以使用开源库,开源框架(atomikos)实现垮库事务
具体实现
1,导入jar包 2,连接池基本属性3,连接路径账号密码4,让atomikos代理Jdbc ,5创建一个全场事务,6开启事务,编译sql,8,预提交,9判断 如果 没有异常 就提交事务,则回滚事务,同时atomikos 如果提交 失败的话 它有重试的 还有记录日志的 功能 可以手动 提交(在实际开发中用的并不多)
分布式事务--ACP和2cp-2阶段提交--Tcc补偿事务-----面试简单总结
分布式事务--ACP和2cp-2阶段提交--Tcc补偿事务-----面试简单总结

BASE理论

在分布式系统中,我们往往追求的是可用性,它的重要程序比一致性要高,那么如何实现高可用性呢? 前人已经给我们提出来了另外一个理论,就是BASE理论,它是用来对CAP定理进行进一步扩充的。BASE理论指的是:

Basically Available(基本可用)
Soft state(软状态)
Eventually consistent(最终一致性)
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

在 分布式系统里使用Tcc(Try ,Confirm ,Cancel )也叫两阶段补偿事务

TCC 其实就是采用的补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。它分为三个阶段:

Try 阶段主要是对业务系统做检测及资源预留

Confirm 阶段主要是对业务系统做确认提交,Try阶段执行成功并开始执行 Confirm阶段时,默认 Confirm阶段是不会出错的。即:只要Try成功,Confirm一定成功。

Cancel 阶段主要是在业务执行错误,需要回滚的状态下执行的业务取消,预留资源释放。

当我我们使用Tcc事务的时候

XA是资源层面的分布式事务,强一致性在俩阶段提交的整个过程中,一直会持有资源的锁。而TCC是在业务层面的分布式事务最终一致性不会有资源的锁 ,运行原理 基本上和2PC 相似 它首先是 先预留资源,预留资源就是,比如说电商的库存,正常是当卖出一件商品就会减一,这时预留资源 就会预计加减一, 但不是真正的去数据库减一 一直执行到第二 阶段的时候全部都没异常才会减一,
分布式事务--ACP和2cp-2阶段提交--Tcc补偿事务-----面试简单总结

所以第一步首先 预留资源 ,进入第二阶段 提交事务 更新数据, 反之如果第一阶段就有事务么有成功的话 到第二阶段 肯定会回滚回去,还原最初的状态,在有就是当数据库宕机 后者断网了 可能正在提交事务, 就可能造成异常不过 TCC
也有重试功能 和记录日志的功能 (也可以手动提交)其实他自身的框架也能完成这一点的 , 其实这也不能 保证一致性 有些 功能 我 们可以借助一些像MQ 消息队列完成 比如一些添加积分 分布式事务--ACP和2cp-2阶段提交--Tcc补偿事务-----面试简单总结