分布式事务之二阶段提交、三阶段提交

本文详细解析了分布式系统中2PC(两阶段提交)和3PC(三阶段提交)的事务协调机制。2PC通过中间者协调各节点的事务提交,确保一致性,但存在单点故障和阻塞问题。3PC增加了预提交阶段,试图解决2PC的部分问题,但仍面临数据一致性挑战。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

分布式系统中的每个节点都能知道自己的事物是成功还是失败,但是不知道其他节点的操作结果。要保证多个节点的事务性,就需要一个中间者来协调这些机器,由中间者来决定事物的提交。2pc和3pc应运而生。

 

2PC

过程如下

 

  1. 中间者向每个节点发送事物请求
  2. 每个节点执行事物操作,将undo和redo记录下来,并将自己的执行结果返回给中间者
  3. 如果都执行成功,则中间者向各个节点发送提交请求,节点们执行事务提交操作,并发送ack给中间者;如果有任意一个节点失败,则中间者向各个节点发送回滚请求,节点们执行回滚操作,并发送ack给中间者。

他的缺点也很明显:中间者是单点,节点会阻塞,可能只有一部分节点收到commit请求

3PC

过程如下

 

  1. 中间者向所有节点发送cancommit请求,询问是否可以执行事务提交操作
  2. 如果所有节点都返回成功,中间者会发送precommit请求,节点们会执行事务操作,将undo和redo记录下来,并将自己的执行结果返回给中间者,等待最后的提交或者终止;如果任一节点返回失败或者中间者在超时时间内没收到节点的返回,会发送终止请求,节点们中断事务。如果节点们在超时时间内没收到中间者发送的precommit阶段的请求(包括正常的precommit请求或者中断请求),也会中断事物。
  3. 此阶段在成功发送precommit请求之后。如果任一节点返回失败或者中间者在超时时间内没收到节点的返回,中间者会向所有节点发送终止请求,节点们收到终止请求会中断事物,利用undo执行回滚操作,返回ack;如果全都返回成功,中间者发送docommit请求,节点们正式提交事务,返回ack。因为各种原因导致的节点无法在超时时间内收到中间者发送的提交或者终止请求,节点都会进行事务提交

缺点也很明显了:在第三步如果中间者发送的终止操作无法在超时时间内到达节点的话,节点也会执行提交,数据会不一致

分布式事务三阶段提交(Three-Phase Commit,3PC)是在传统的两阶段提交(Two-Phase Commit,2PC)基础上进行改进的一种分布式事务协议。它通过引入预备阶段来解决两阶段提交协议中的阻塞问题。 分布式事务三阶段提交的过程如下: 1. CanCommit 阶段:事务协调者向所有参与者发送 CanCommit 请求,并等待参与者的回复。参与者在接收到 CanCommit 请求后,会执行本地的事务检查,判断是否可以提交事务。如果所有参与者都返回 Yes,则进入下一阶段;如果有任何一个参与者返回 No,则中止事务。 2. PreCommit 阶段:事务协调者向所有参与者发送 PreCommit 请求,并等待参与者的回复。参与者在接收到 PreCommit 请求后,会执行事务的预提交操作,并将预提交结果返回给事务协调者。如果所有参与者都返回 Acknowledgement,则进入下一阶段;如果有任何一个参与者返回 Abort,则中止事务。 3. DoCommit 阶段:事务协调者向所有参与者发送 DoCommit 请求,并等待参与者的回复。参与者在接收到 DoCommit 请求后,会执行事务的最终提交操作,并将提交结果返回给事务协调者。如果所有参与者都返回 Acknowledgement,则整个事务提交成功;如果有任何一个参与者返回 Abort,则整个事务被回滚。 分布式事务三阶段提交相对于传统的两阶段提交协议,引入了预备阶段(PreCommit),在该阶段参与者可以执行预提交操作,但仍然需要协调者的最终确认才能进行最终提交。这样可以减少了阻塞等待的时间,提高了系统的并发性能。 然而,分布式事务三阶段提交仍然存在一些问题,如单点故障、网络分区等情况下的可用性问题。因此,在实际应用中,需要综合考虑业务需求和系统特点,选择合适的事务协议来保证数据的一致性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值