分布式一致性算法2PC和3PC

为了解决分布式一致性问题,产生了不少经典的分布式一致性算法,本文将介绍其中的2PC和3PC。2PC即Two-Phase Commit,译为二阶段提交协议。3PC即Three-Phase Commit,译为三阶段提交协议。
?

分布式系统和分布式一致性问题

?
  分布式系统,即运行在多台不同的网络计算机上的软硬件系统,并且仅通过消息传递来进行通信和协调。
  分布式一致性问题,即相互独立的节点之间如何就一项决议达成一致的问题。
?

2PC

?
  2PC,二阶段提交协议,即将事务的提交过程分为两个阶段来进行处理:准备阶段和提交阶段。事务的发起者称协调者,事务的执行者称参与者。
?
  阶段1:准备阶段
  1、协调者向所有参与者发送事务内容,询问是否可以提交事务,并等待所有参与者答复。
  2、各参与者执行事务操作,将Undo和Redo信息记入事务日志中(但不提交事务)。
  3、如参与者执行成功,给协调者反馈YES,即可以提交;如执行失败,给协调者反馈NO,即不可提交。
?
  阶段2:提交阶段
?
  此阶段分两种情况:所有参与者均反馈YES、或任何一个参与者反馈NO。
  所有参与者均反馈YES时,即提交事务。
  任何一个参与者反馈NO时,即中断事务。
?
  提交事务:(所有参与者均反馈YES)
  1、协调者向所有参与者发出正式提交事务的请求(即Commit请求)。
  2、参与者执行Commit请求,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务提交。
?
  附如下示意图:
?

?
  中断事务:(任何一个参与者反馈NO)
  1、协调者向所有参与者发出回滚请求(即Rollback请求)。
  2、参与者使用阶段1中的Undo信息执行回滚操作,并释放整个事务期间占用的资源。
  3、各参与者向协调者反馈Ack完成的消息。
  4、协调者收到所有参与者反馈的Ack消息后,即完成事务中断。
?
  附如下示意图:
?

?

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请求。此时,参与者都会在等待超时之后,继续执行事务提交。
?
  附示意图如下:
?

?

3PC的优点和缺陷

?
  优点:降低了阻塞范围,在等待超时后协调者或参与者会中断事务。避免了协调者单点问题,阶段3中协调者出现问题时,参与者会继续提交事务。
?
  缺陷:脑裂问题依然存在,即在参与者收到PreCommit请求后等待最终指令,如果此时协调者无法与参与者正常通信,会导致参与者继续提交事务,造成数据不一致。
?

后记

?
  无论2PC或3PC,均无法彻底解决分布式一致性问题。
  解决一致性问题,唯有Paxos,后续将单独总结。

原文地址:http://blog.51cto.com/11821908/2058651

时间: 2024-10-04 07:30:10

分布式一致性算法2PC和3PC的相关文章

分布式一致性算法梳理

分布式一致性算法主流方案:2PC.3PC.leader/follower.paxos 一致性有两种场景: 1.多份相同的数据,在一处修改,保证多份一致 2.一个业务变更多份不同的数据,要保持一致,要成功都成功,要失败都失败 产生不一致的原因: 1.异常操作导致不成功 2.网络分区 3.应用故障 两阶段提交(2PC) 将事务的提交分为准备和提交两个阶段来达成一致性的算法,主要用于事务管理.分布式一致性,两阶段提交需要在更新发起者和参与者中间加一个协调者的角色.具体步骤如下: 1.变更者发起变更申请

分布式事务(1)---2PC和3PC理论

分布式事务(1)---2PC和3PC理论 分布式事物基本理论:基本遵循CPA理论,采用柔性事物特征,软状态或者最终一致性特点保证分布式事物一致性问题. 分布式事物常见解决方案: 2PC两段提交协议 3PC三段提交协议(弥补两端提交协议缺点) TCC或者GTS(阿里) 消息中间件最终一致性 使用LCN解决分布式事物,理念"LCN并不生产事务,LCN只是本地事务的搬运工". 一.两阶段提交(2PC) 两阶段提交又称2PC,2PC是一个非常经典的强一致.中心化的原子提交协议. 这里所说的中心

分布式一致性算法:Raft 算法

Raft 算法是可以用来替代 Paxos 算法的分布式一致性算法,而且 raft 算法比 Paxos 算法更易懂且更容易实现.本文对 raft 论文进行翻译,希望能有助于读者更方便地理解 raft 的思想.如果对 Paxos 算法感兴趣,可以看我的另一篇文章:分布式系列文章--Paxos算法原理与推导 摘要Raft 是用来管理复制日志(replicated log)的一致性协议.它跟 multi-Paxos 作用相同,效率也相当,但是它的组织结构跟 Paxos 不同.这使得 Raft 比 Pax

分布式一致性算法——paxos

一.什么是paxos算法 Paxos 算法是分布式一致性算法用来解决一个分布式系统如何就某个值(决议)达成一致的问题. 人们在理解paxos算法是会遇到一些困境,那么接下来,我们带着以下几个问题来学习paxos算法: 1.paxos到底在解决什么问题? 2.paxos到底如何在分布式存储系统中应用? 3.paxos的核心思想是什么? 二.paxos解决了什么问题 分布式的一致性问题其实主要是指分布式系统中的数据一致性问题.所以,为了保证分布式系统的一致性,就要保证分布式系统中的数据是一致的. 在

Paxos分布式一致性算法简介和Apache ZooKeeper的概念映射

Paxos是一个基于消息传递的一致性算法,近几年被广泛应用于分布式计算中,Google的Chubby,Apache的Zookeeper都是基于它的理论来实现的,Paxos还被认为是到目前为止唯一的分布式一致性算法,其它的算法都是Paxos的改进或简化.Paxos只有在一个可信的计算环境中才能成立,这个环境是不会被入侵所破坏的. 由Leslie Lamport发明了Paxos算法,他目前供职于微软研究院.1998年在ACM Transactions on Computer Systems的<The

Raft 为什么是更易理解的分布式一致性算法

Raft 为什么是更易理解的分布式一致性算法 一致性问题可以算是分布式领域的一个圣殿级问题了,关于它的研究可以回溯到几十年前. 拜占庭将军问题 Leslie Lamport 在三十多年前发表的论文<拜占庭将军问题>(参考[1]). 拜占庭位于如今的土耳其的伊斯坦布尔,是东罗马帝国的首都.由于当时拜占庭罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信差传消息.在战争的时候,拜占庭军队内所有将军必需达成 一致的共识,决定是否有赢的机会才去攻打敌人的阵营.但是,在军队内

【转】Raft 为什么是更易理解的分布式一致性算法

编者按:这是看过的Raft算法博客中比较通俗的一篇了,讲解问题的角度比较新奇,图文并茂,值得一看.原文链接:Raft 为什么是更易理解的分布式一致性算法 一致性问题可以算是分布式领域的一个圣殿级问题了,关于它的研究可以回溯到几十年前. 拜占庭将军问题 Leslie Lamport 在三十多年前发表的论文<拜占庭将军问题>(参考[1]). 拜占庭位于如今的土耳其的伊斯坦布尔,是东罗马帝国的首都.由于当时拜占庭罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信差传消息.

兄弟连区块链入门到精通教程区块链共识算法分布式一致性算法Raft

Paxos自1990年提出以后,相当长时间内几乎已成为分布式一致性算法的代名词.但因其难以理解和实现,目前知名实现仅有Chubby.Zookeeper.libpaxos几种,其中Zookeeper使用的ZAB对Paxos做了大量改进.为此,2013年斯坦福的Diego Ongaro.John Ousterhout,提出了新的更易理解和实现的一致性算法,即Raft. Raft和Paxos均只要保证n/2+1节点正常,即可服务.相比Paxos,其优势即为易于理解和实现.Raf将算法分解为:选择领导者

三:分布式事务一致性协议2pc和3pc

一:分布式一致性协议--->对于一个分布式系统进行架构设计的过程中,往往会在系统的可用性和数据一致性之间进行反复的权衡,于是就产生了一系列的一致性协议.--->长期探索涌现出一大批经典的一致性协议和算法.其中最著名的就是二阶段提交协议,三阶段提交协议和paxos算法. 二:2PC与3PC--->在分布式系统中,每一个机器节点虽然都能够明确知道自己在进行事务操作过程中的结果是成功或失败,但却无法直接获取到其他分布式节点的操作结果.因此,当一个事务操作需要跨越多个分布式节点的时候,为了保持事