两阶提交、三阶提交、TCC框架

62 篇文章 1 订阅
62 篇文章 1 订阅

 

首先介绍一下分布式事务,分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)

在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调,也就是说引入一个“协调者”的组件来统一调度所有分布式节点的执行。

具体来说二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

所谓的两个阶段是指:第一阶段:准备阶段(投票阶段)和第二阶段:提交阶段(执行阶段)。

二阶段提交看起来确实能够提供原子性的操作,但是不幸的事,二阶段提交还是有几个缺点的:

1、同步阻塞问题。执行过程中,所有参与节点都是事务阻塞型的。当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。

2、单点故障。由于协调者的重要性,一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段,协调者发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。(如果是协调者挂掉,可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题)

3、数据不一致。在二阶段提交的阶段二中,当协调者向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中协调者发生了故障,这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

4、二阶段无法解决的问题:协调者再发出commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。

由于二阶段提交存在着诸如同步阻塞、单点问题、脑裂等缺陷,所以,研究者们在二阶段提交的基础上做了改进,提出了三阶段提交。

与两阶段提交不同的是,三阶段提交有两个改动点。

1、引入超时机制。同时在协调者和参与者中都引入超时机制。2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

相对于2PC,3PC主要解决的单点故障问题,并减少阻塞,因为一旦参与者无法及时收到来自协调者的信息之后,他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题,因为,由于网络原因,协调者发送的abort响应没有及时被参与者接收到,那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

TCC,不同2PC、3PC数据节点事务一致性,他是业务节点的层面的。BASE理论的大成者通过Try节点修改成软状态状态,再通过confrim或者cancel来处理事务。confrim或者cancel一步出现异常,他提供日志机制进行重试或告警达到基本可用、最终一致性。

也可以用paxos算法做一个协调者集群,保证其高可用。

****************************************************************************

【如果文字看累了,可b站搜索“沙皮狗2021”,用听的方式领略知识的魅力】

   传送门 :https://space.bilibili.com/407643589

【微信公众号】:沙皮狗2021

****************************************************************************

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
TCC(Try-Confirm-Cancel)是一种分布式事务管理机制,它采用“两阶提交”和“补偿事务”种方式,确保分布式事务的原子性和一致性。 TCC的核心思想是将一个复杂的事务拆分成三个步骤:试图执行(Try)、确认执行(Confirm)和取消执行(Cancel)。这三个步骤分别对应“两阶提交”(2PC)中的准备阶段提交阶段和回滚阶段TCC有以下三个步骤: 1.试图执行(Try):首先,在事务发起方(服务A)执行操作前,会向参与方(服务B)发送请求,询问其是否能够执行当前操作。如果参与方确认可以执行,则进行预留资源,记录操作信息;如果参与方回应拒绝,则整个事务将会回滚。 2.确认执行(Confirm):当所有参与方都能够执行操作时,事务发起方会通知各个参与方提交执行请求,对应2PC中的“提交事务”阶段提交完成后,事务进入“已提交”状态。 3.取消执行(Cancel):如果有任何一个参与方在“试图执行”或“确认执行”阶段发生异常,或者在“确认执行”之前事务发起方主动取消了事务,那么事务将进入“已撤销”状态。在“已撤销”状态下,事务发起方可以向各个参与方发送请求进行事务回滚操作。 TCC采用“补偿事务”来确保一致性,即当某个参与方在Confirm阶段发生异常,无法提交时,其他参与方会执行相反的操作,将之前预留的资源释放掉,从而保证整个事务的原子性和一致性。 总的来说,TCC机制是一种高可靠、高性能的分布式事务管理机制,适用于对事务数据的正确性和一致性要求较高的场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

蜗牛慢慢向上爬

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值