三阶段提交协议(3PC)

3PC:要是为了解决两阶段提交协议的单点故障问题和缩小参与者阻塞范围。 引入参与节点的超时机制之外,3PC把2PC的准备阶段分成事务询问(该阶段不会阻塞)和事务预提交,则三个阶段分别为CanCommit、PreCommit、DoCommit。

模型:

第一个阶段: CanCommit

事务询问

协调者向所有的参与者发送一个包含事务内容的canCommit请求,询问是否可以执行事务提交操作,并开始等待各参与者的响应。

② 各参与者向协调者反馈事务询问的响应参与者在接收到来自协调者的包含了事务内容的canCommit请求后,正常情况下,如果自身认为可以顺利执行事务,则反馈Yes响应,并进入预备状态否则反馈No响应

第二个阶段: PreCommit

协调者在得到所有参与者的响应之后,会根据结果有2种执行操作的情况:执行事务预提交,或者中断事务假如所有参与反馈的都是Yes,那么就会执行事务预提交。

1. 执行事务预提交(分为 3 个步骤)

发送预提交请求:协调者向所有参与者节点发出preCommit请求并进入prepared阶段

事务预提交:参与者接收到preCommit请求后,会执行事务操作,并将Undo和Redo信息记录到事务日志中。

各参与者向协调者反馈事务执行的结果:若参与者成功执行了事务操作,那么反馈Ack

若任一参与者反馈了No响应,或者在等待超时后,协调者尚无法接收到所有参与者反馈,则中断事务

2. 中断事务(分为2个步骤)

发送中断请求

协调者向所有参与者发出abort请求

中断事务:

无论是收到来自协调者的abort请求或者等待协调者请求过程中超时,参与者都会中断事务

第三个阶段: DoCommit

该阶段做真正的事务提交或者完成事务回滚,所以就会出现两种情况:

1. 执行事务提交(分为4步)

发送提交请求

进入这一阶段,假设协调者处于正常工作状态,并且它接收到了来自所有参与者的Ack响应,那么他将从预提交状态转化为提交状态,并向所有的参与者发送doCommit请求

事务提交

参与者接收到doCommit请求后,会正式执行事务提交操作,并在完成提交之后释放整个事务执行过程中占用的事务资源

反馈事务提交结果:参与者在完成事务提交后,向协调者发送Ack响应

完成事务:协调者接收所有参与者反馈的Ack消息后完成事务

2. 中断事务(分为四步)

发送中断请求:协调者向所有的参与者节点发送abort请求

事务回滚参与者收到abort请求后,会根据记录的Undo信息来执行事务回滚,并在完成回滚之后释放整个事务执行期间占用的资源

反馈事务回滚结果:参与者在完成事务回滚后,向协调者发送Ack消息。

中断事务:协调者接收到所有参与者反馈的Ack消息后,中断事务

注意:一旦进入阶段二和三,可能会出现 2 种故障:

1、协调者出现问题

2、协调者和参与者之间的网络故障

如果出现了任何一种情况,最终都会导致参与者无法收到 doCommit 请求或者 abort 请求,针对这种情况,参与者都会在等待超时之后,继续进行事务提交导致数据不一致

  • 3
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当涉及到多个参与者的分布式事务时,常见的分布式事务协议有两阶段提交(2PC)、阶段提交(3PC)以及TCC(Try-Confirm-Cancel)。 1. 两阶段提交(2PC): 在两阶段提交协议中,有一个协调者(Coordinator)和多个参与者(Participants)。该协议包含两个阶段: - 准备阶段(Prepare Phase):协调者向所有参与者发送准备请求,并等待它们的响应。参与者在准备阶段执行事务的前半部分,并将准备好的状态和日志信息发送给协调者。 - 提交阶段(Commit Phase):如果所有参与者都准备好了,协调者向所有参与者发送提交请求。参与者在收到请求后,执行事务的后半部分,并将最终执行结果发送给协调者。协调者根据参与者的反馈情况决定是否提交或中止事务,并通知所有参与者执行对应的操作。 2. 阶段提交(3PC): 阶段提交协议是对两阶段提交协议的改进,引入了一个超时机制来解决两阶段提交协议中可能出现的长时间等待问题。该协议包含阶段: - CanCommit阶段:类似于两阶段提交的准备阶段,协调者询问所有参与者是否可以提交事务,并等待它们的响应。 - PreCommit阶段:如果所有参与者都同意提交,协调者会发送PreCommit请求给所有参与者,并等待它们的响应。参与者在收到请求后,执行事务的前半部分,并将准备好的状态和日志信息发送给协调者。 - DoCommit阶段:如果所有参与者都准备好了,协调者向所有参与者发送Commit请求。参与者在收到请求后,执行事务的后半部分,并将最终执行结果发送给协调者。协调者根据参与者的反馈情况决定是否提交或中止事务,并通知所有参与者执行对应的操作。 3. TCC(Try-Confirm-Cancel): TCC是一种基于补偿机制的分布式事务协议,相比于2PC和3PC,它更加灵活。TCC协议将事务分为阶段: - Try阶段:尝试执行事务的操作,检查所有资源是否可用。如果所有资源都可用,则进入下一个阶段;否则,执行回滚操作。 - Confirm阶段:确认执行事务的操作,将所有的修改持久化。如果确认成功,则事务提交完成;否则,执行回滚操作。 - Cancel阶段:取消执行事务的操作,撤销所有的修改。这个阶段是回滚操作的最后一道保险措施。 TCC协议通过在每个阶段中提供相应的补偿操作,使得可以在分布式环境下实现事务的一致性和可靠性。它的灵活性在于可以根据具体业务需求来定义每个阶段的操作,适应各种复杂的分布式事务场景。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值