两阶段提交2PC 和 三阶段提交3pc

简介: 两阶段提交2PC 和 三阶段提交3pc

一、概念

二阶段提交2PC(Two phase Commit)是指,在分布式系统里,为了保证所有节点在进行事务提交时保持一致性的一种算法。
2PC,二阶段提交协议,即将事务的提交过程分为两个阶段来进行处理:准备阶段和提交阶段。事务的发起者称协调者,事务的执行者称参与者。

二、背景

在分布式系统里,每个节点都可以知晓自己操作的成功或者失败,却无法知道其他节点操作的成功或失败。
当一个事务跨多个节点时,为了保持事务的原子性与一致性,需要引入一个协调者(Coordinator)来统一掌控所有参与者(Participant)的操作结果,并指示它们是否要把操作结果进行真正的提交(commit)或者回滚(rollback)。

三、思路

2PC顾名思义分为两个阶段,其实施思路可概括为:
(1)投票阶段(voting phase):参与者将操作结果通知协调者;
(2)提交阶段(commit phase):收到参与者的通知后,协调者再向参与者发出通知,根据反馈情况决定各参与者是否要提交还是回滚;

四、缺陷

算法执行过程中,所有节点都处于阻塞状态,所有节点所持有的资源(例如数据库数据,本地文件等)都处于封锁状态。
典型场景为:

  • (1)某一个参与者发出通知之前,所有参与者以及协调者都处于阻塞状态;
  • (2)在协调者发出通知之前,所有参与者都处于阻塞状态;

另外,如有协调者或者某个参与者出现了崩溃,为了避免整个算法处于一个完全阻塞状态,往往需要借助超时机制来将算法继续向前推进,故此时算法的效率比较低。
总的来说,2PC是一种比较保守的算法。

五、举例

甲乙丙丁四人要组织一个会议,需要确定会议时间,不妨设甲是协调者,乙丙丁是参与者。

投票阶段:

  • (1)甲发邮件给乙丙丁,周二十点开会是否有时间;
  • (2)甲回复有时间;
  • (3)乙回复有时间;
  • (4)丙迟迟不回复,此时对于这个活动,甲乙丙均处于阻塞状态,算法无法继续进行;
  • (5)丙回复有时间(或者没有时间);
    提交阶段:
  • (1)协调者甲将收集到的结果反馈给乙丙丁(什么时候反馈,以及反馈结果如何,在此例中取决与丙的时间与决定);
  • (2)乙收到;
  • (3)丙收到;
  • (4)丁收到;

六、结论

2PC的缺陷

  • 1、同步阻塞:最大的问题即同步阻塞,即:所有参与事务的逻辑均处于阻塞状态。
  • 2、单点:协调者存在单点问题,如果协调者出现故障,参与者将一直处于锁定状态。
  • 3、脑裂:在阶段2中,如果只有部分参与者接收并执行了Commit请求,会导致节点数据不一致。
    由于2PC存在如上同步阻塞、单点、脑裂问题,因此又出现了2PC的改进方案,即3PC。

3PC

  3PC,三阶段提交协议,是2PC的改进版本,即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。

  阶段1:CanCommit
  1、协调者向所有参与者发出包含事务内容的CanCommit请求,询问是否可以提交事务,并等待所有参与者答复。
  2、参与者收到CanCommit请求后,如果认为可以执行事务操作,则反馈YES并进入预备状态,否则反馈NO。

  阶段2:PreCommit

  此阶段分两种情况:
  1、所有参与者均反馈YES,即执行事务预提交。
  2、任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈,即中断事务。

  事务预提交:(所有参与者均反馈YES时)
  1、协调者向所有参与者发出PreCommit请求,进入准备阶段。
  2、参与者收到PreCommit请求后,执行事务操作,将Undo和Redo信息记入事务日志中(但不提交事务)。
  3、各参与者向协调者反馈Ack响应或No响应,并等待最终指令。

  中断事务:(任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈时)
  1、协调者向所有参与者发出abort请求。
  2、无论收到协调者发出的abort请求,或者在等待协调者请求过程中出现超时,参与者均会中断事务。

  阶段3:do Commit

  此阶段也存在两种情况:
  1、所有参与者均反馈Ack响应,即执行真正的事务提交。
  2、任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈,即中断事务。

  提交事务:(所有参与者均反馈Ack响应时)
  1、如果协调者处于工作状态,则向所有参与者发出do Commit请求。
  2、参与者收到do Commit请求后,会正式执行事务提交,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务提交。

  中断事务:(任何一个参与者反馈NO,或者等待超时后协调者尚无法收到所有参与者的反馈时)
  1、如果协调者处于工作状态,向所有参与者发出abort请求。
  2、参与者使用阶段1中的Undo信息执行回滚操作,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务中断。

  注意:进入阶段三后,无论协调者出现问题,或者协调者与参与者网络出现问题,都会导致参与者无法接收到协调者发出的do Commit请求或abort请求。此时,参与者都会在等待超时之后,继续执行事务提交。

  附示意图如下:

image.png

3PC的优点和缺陷

  优点:降低了阻塞范围,在等待超时后协调者或参与者会中断事务。避免了协调者单点问题,阶段3中协调者出现问题时,参与者会继续提交事务。

  缺陷:脑裂问题依然存在,即在参与者收到PreCommit请求后等待最终指令,如果此时协调者无法与参与者正常通信,会导致参与者继续提交事务,造成数据不一致。

后记

  无论2PC或3PC,均无法彻底解决分布式一致性问题。
  解决一致性问题,唯有Paxos 。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
26天前
|
监控
两阶段终止模式和Balking模式
两阶段终止模式和Balking模式
19 1
|
7月前
|
存储 算法 关系型数据库
对比两阶段提交,三阶段提交做了哪些改进?
在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调。在关系型数据库中,由于存在事务机制,可以保证每个独立节点上的数据操作满足 ACID。但是,相互独立的节点之间无法准确的知道其他节点中的事务执行情况,所以在分布式的场景下,如果不添加额外的机制,多个节点之间理论上无法达到一致的状态。 在分布式事务中,两阶段和三阶段提交是经典的一致性算法,那么两阶段和三阶段提交的具体流程是怎样的,三阶段提交又是如何改进的呢?
54 0
|
3月前
|
存储 消息中间件 关系型数据库
解密分布式事务:CAP理论、BASE理论、两阶段提交(2PC)、三阶段提交(3PC)、补偿事务(TCC)、MQ事务消息、最大努力通知
解密分布式事务:CAP理论、BASE理论、两阶段提交(2PC)、三阶段提交(3PC)、补偿事务(TCC)、MQ事务消息、最大努力通知
|
9月前
|
存储 算法 NoSQL
分布式事务两阶段提交和三阶段提交有什么区别?
分布式事务两阶段提交和三阶段提交有什么区别?
156 0
分布式事务两阶段提交和三阶段提交有什么区别?
|
11月前
【JavaP6大纲】分布式事务篇:两阶段提交(2PC)
【JavaP6大纲】分布式事务篇:两阶段提交(2PC)
|
11月前
【JavaP6大纲】分布式事务篇:三阶段提交(3PC)
【JavaP6大纲】分布式事务篇:三阶段提交(3PC)
分布式学习六:三阶段提交(3PC)
分布式学习六:三阶段提交(3PC)
82 0
分布式事务 2PC两阶段3PC三阶段
两阶段提交协议(2PC) 两阶段提交协议用于保证分布式事务的原子性,即所有的参与节点或者全部都执行或者全部不执行,其执行过程主要分为两个阶段: 第一阶段,准备阶段;第二阶段,提交阶段。
194 1
|
安全 程序员 开发工具
一通操作猛如虎 合并Unidbg的更新,继续跑sign
一通操作猛如虎 合并Unidbg的更新,继续跑sign
一通操作猛如虎 合并Unidbg的更新,继续跑sign
|
SQL 监控 关系型数据库
分布式事务实战---XA两阶段提交(2PC)方案详解(下)
分布式事务实战---XA两阶段提交(2PC)方案详解
496 0
分布式事务实战---XA两阶段提交(2PC)方案详解(下)