精华内容
下载资源
问答
  • 2PC和3PC

    万次阅读 多人点赞 2018-06-20 09:43:49
    2PC3PC区别 相对于2PC3PC主要解决的单点故障问题,并减少阻塞,因为一旦参与者无法及时收到来自协调者的信息之后,他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致...

    随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题,大型网站的架构也在不断发展。提高大型网站的高可用架构,不得不提的就是分布式。在分布式一致性一文中主要介绍了分布式系统中存在的一致性问题。本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是分布式事务二阶段提交三阶段提交

    分布式一致性回顾

    在分布式系统中,为了保证数据的高可用,通常,我们会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上。为了对用户提供正确的增\删\改\差等语义,我们需要保证这些放置在不同物理机器上的副本是一致的。

    为了解决这种分布式一致性问题,前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议(Two Phase Commitment Protocol)、三阶提交协议(Three Phase Commitment Protocol)和Paxos算法

    分布式事务

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

    在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调。由于存在事务机制,可以保证每个独立节点上的数据操作可以满足ACID。但是,相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲,两台机器理论上无法达到一致的状态。如果想让分布式部署的多台机器中的数据保持一致性,那么就要保证在所有节点的数据写操作,要不全部都执行,要么全部的都不执行。但是,一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。所以,常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。

    XA规范

    X/Open 组织(即现在的 Open Group )定义了分布式事务处理模型。 X/Open DTP 模型( 1994 )包括应用程序( AP )、事务管理器( TM )、资源管理器( RM )、通信资源管理器( CRM )四部分。一般,常见的事务管理器( TM )是交易中间件,常见的资源管理器( RM )是数据库,常见的通信资源管理器( CRM )是消息中间件。    通常把一个数据库内部的事务处理,如对多个表的操作,作为本地事务看待。数据库的事务处理对象是本地事务,而分布式事务处理的对象是全局事务。   所谓全局事务,是指分布式事务处理环境中,多个数据库可能需要共同完成一个工作,这个工作即是一个全局事务,例如,一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功,还要依赖与全局事务相关的其它数据库的操作是否成功,如果任一数据库的任一操作失败,则参与此事务的所有数据库所做的所有操作都必须回滚。     一般情况下,某一数据库无法知道其它数据库在做什么,因此,在一个 DTP 环境中,交易中间件是必需的,由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作(可恢复)影射到全局事务中。    

    XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范(即接口函数),交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。 

    二阶提交协议三阶提交协议就是根据这一思想衍生出来的。可以说二阶段提交其实就是实现XA分布式事务的关键(确切地说:两阶段提交主要保证了分布式事务的原子性:即所有结点要么全做要么全不做)

    2PC

    二阶段提交(Two-phaseCommit)是指,在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常,二阶段提交也被称为是一种协议(Protocol))。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

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

    准备阶段

    事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息,每个参与者要么直接返回失败(如权限验证失败),要么在本地执行事务,写本地的redo和undo日志,但不提交,到达一种“万事俱备,只欠东风”的状态。

    可以进一步将准备阶段分为以下三个步骤:

    1)协调者节点向所有参与者节点询问是否可以执行提交操作(vote),并开始等待各参与者节点的响应。

    2)参与者节点执行询问发起为止的所有事务操作,并将Undo信息和Redo信息写入日志。(注意:若成功这里其实每个参与者已经执行了事务操作)

    3)各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功,则它返回一个”同意”消息;如果参与者节点的事务操作实际执行失败,则它返回一个”中止”消息。

    提交阶段

    如果协调者收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

    接下来分两种情况分别讨论提交阶段的过程。

    当协调者节点从所有参与者节点获得的相应消息都为”同意”时:

    success

    1)协调者节点向所有参与者节点发出”正式提交(commit)”的请求。

    2)参与者节点正式完成操作,并释放在整个事务期间内占用的资源。

    3)参与者节点向协调者节点发送”完成”消息。

    4)协调者节点受到所有参与者节点反馈的”完成”消息后,完成事务。

    如果任一参与者节点在第一阶段返回的响应消息为”中止”,或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时:

    fail

    1)协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。

    2)参与者节点利用之前写入的Undo信息执行回滚,并释放在整个事务期间内占用的资源。

    3)参与者节点向协调者节点发送”回滚完成”消息。

    4)协调者节点受到所有参与者节点反馈的”回滚完成”消息后,取消事务。

      不管最后结果如何,第二阶段都会结束当前事务。

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

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

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

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

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

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

    3PC

    三阶段提交(Three-phase commit),也叫三阶段提交协议(Three-phase commit protocol),是二阶段提交(2PC)的改进版本。

    3

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

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

    也就是说,除了引入超时机制之外,3PC把2PC的准备阶段再次一分为二,这样三阶段提交就有CanCommitPreCommitDoCommit三个阶段。

    CanCommit阶段

    3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求,参与者如果可以提交就返回Yes响应,否则返回No响应。

    1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。

    2.响应反馈 参与者接到CanCommit请求之后,正常情况下,如果其自身认为可以顺利执行事务,则返回Yes响应,并进入预备状态。否则反馈No

    PreCommit阶段

    协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况,有以下两种可能。

    假如协调者从所有的参与者获得的反馈都是Yes响应,那么就会执行事务的预执行。

    1.发送预提交请求 协调者向参与者发送PreCommit请求,并进入Prepared阶段。

    2.事务预提交 参与者接收到PreCommit请求后,会执行事务操作,并将undo和redo信息记录到事务日志中。

    3.响应反馈 如果参与者成功的执行了事务操作,则返回ACK响应,同时开始等待最终指令。

    假如有任何一个参与者向协调者发送了No响应,或者等待超时之后,协调者都没有接到参与者的响应,那么就执行事务的中断。

    1.发送中断请求 协调者向所有参与者发送abort请求。

    2.中断事务 参与者收到来自协调者的abort请求之后(或超时之后,仍未收到协调者的请求),执行事务的中断。

    doCommit阶段

    该阶段进行真正的事务提交,也可以分为以下两种情况。

    执行提交

    1.发送提交请求 协调接收到参与者发送的ACK响应,那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。

    2.事务提交 参与者接收到doCommit请求之后,执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

    3.响应反馈 事务提交完之后,向协调者发送Ack响应。

    4.完成事务 协调者接收到所有参与者的ack响应之后,完成事务。

    中断事务 协调者没有接收到参与者发送的ACK响应(可能是接受者发送的不是ACK响应,也可能响应超时),那么就会执行中断事务。

    1.发送中断请求 协调者向所有参与者发送abort请求

    2.事务回滚 参与者接收到abort请求之后,利用其在阶段二记录的undo信息来执行事务的回滚操作,并在完成回滚之后释放所有的事务资源。

    3.反馈结果 参与者完成事务回滚之后,向协调者发送ACK消息

    4.中断事务 协调者接收到参与者反馈的ACK消息之后,执行事务的中断。

    doCommit阶段,如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时,会在等待超时之后,会继续进行事务的提交。(其实这个应该是基于概率来决定的,当进入第三阶段时,说明参与者在第二阶段已经收到了PreCommit请求,那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前,收到所有参与者的CanCommit响应都是Yes。(一旦参与者收到了PreCommit,意味他知道大家其实都同意修改了)所以,一句话概括就是,当进入第三阶段时,由于网络超时等原因,虽然参与者没有收到commit或者abort响应,但是他有理由相信:成功提交的几率很大。 

    2PC与3PC的区别

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


    了解了2PC和3PC之后,我们可以发现,无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。Google Chubby的作者Mike Burrows说过, there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一种一致性算法,那就是Paxos,所有其他一致性算法都是Paxos算法的不完整版。后面的文章会介绍这个公认为难于理解但是行之有效的Paxos算法。

    参考资料:

    分布式协议之两阶段提交协议(2PC)和改进三阶段提交协议(3PC) 关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究 两阶段提交协议与三阶段提交协议

    展开全文
  • 分布式事务中2PC3PC区别

    万次阅读 2017-04-02 19:46:26
    因此,当一个事务要跨越多个分布式节点的时候(比如,淘宝下单流程,下单系统库存系统可能就是分别部署在不同的分布式节点中),为了保证该事务可以满足ACID,就要引入一个协调者(Cooradinator)。其他的节点被...

    协调者

    在分布式系统中,每一个机器节点虽然都能明确的知道自己执行的事务是成功还是失败,但是却无法知道其他分布式节点的事务执行情况。因此,当一个事务要跨越多个分布式节点的时候(比如,淘宝下单流程,下单系统和库存系统可能就是分别部署在不同的分布式节点中),为了保证该事务可以满足ACID,就要引入一个协调者(Cooradinator)。其他的节点被称为参与者(Participant)。协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务进行提交。

    二阶段提交协议(2PC)

    二阶段提交协议主要分为来个阶段:准备阶段和提交阶段。

    在日常生活中其实是有很多事都是这种二阶段提交的,比如西方婚礼中就经常出现这种场景:

    牧师:”你愿意娶这个女人吗?爱她、忠诚于她,无论她贫困、患病或者残疾,直至死亡。Doyou(你愿意吗)?”

    新郎:”Ido(我愿意)!”

    牧师:”你愿意嫁给这个男人吗?爱他、忠诚于他,无论他贫困、患病或者残疾,直至死亡。Doyou(你愿意吗)?”

    新娘:”Ido(我愿意)!”

    牧师:现在请你们面向对方,握住对方的双手,作为妻子和丈夫向对方宣告誓言。

    新郎:我——某某某,全心全意娶你做我的妻子,无论是顺境或逆境,富裕或贫穷,健康或疾病,快乐或忧愁,我都将毫无保留地爱你,我将努力去理解你,完完全全信任你。我们将成为一个整体,互为彼此的一部分,我们将一起面对人生的一切,去分享我们的梦想,作为平等的忠实伴侣,度过今后的一生。

    新娘:我全心全意嫁给你作为你的妻子,无论是顺境或逆境,富裕或贫穷,健康或疾病,快乐或忧愁,我都将毫无保留的爱你,我将努力去理解你,完完全全信任你,我们将成为一个整体,互为彼此的一部分,我们将一起面对人生的一切,去分享我们的梦想,作为平等的忠实伴侣,度过今后的一生。

    上面这个比较经典的桥段就是一个典型的二阶段提交过程。

    首先协调者(牧师)会询问两个参与者(二位新人)是否能执行事务提交操作(愿意结婚)。如果两个参与者能够执行事务的提交,先执行事务操作,然后返回YES,如果没有成功执行事务操作,就返回NO。

    当协调者接收到所有的参与者的反馈之后,开始进入事务提交阶段。如果所有参与者都返回YES,那就发送COMMIT请求,如果有一个人返回NO,那就返送roolback请求。

    值得注意的是,二阶段提交协议的第一阶段准备阶段不仅仅是回答YES or NO,还是要执行事务操作的,只是执行完事务操作,并没有进行commit还是roolback。和上面的结婚例子不太一样。如果非要举例的话可以理解为男女双方交换定情信物的过程。信物一旦交给对方了,这个信物就不能挪作他用了。也就是说,一旦事务执行之后,在没有执行commit或者roolback之前,资源是被锁定的。这会造成阻塞。


    2PC存在的问题

    下面我们来分析下2PC存在的问题。

    这里暂且不谈2PC存在的同步阻塞、单点问题、脑裂等问题(上篇文章中有具体介绍),我们只讨论下数据一致性问题。作为一个分布式的一致性协议,我们主要关注他可能带来的一致性问题的。


    2PC在执行过程中可能发生协调者或者参与者突然宕机的情况,在不同时期宕机可能有不同的现象。


    情况一:协调者挂了,参与者没挂

    这种情况其实比较好解决,只要找一个协调者的替代者。当他成为新的协调者的时候,询问所有参与者的最后那条事务的执行情况,他就可以知道是应该做什么样的操作了。所以,这种情况不会导致数据不一致。


    情况二:参与者挂了,协调者没挂

    这种情况其实也比较好解决。如果协调者挂了。那么之后的事情有两种情况:

    • 第一个是挂了就挂了,没有再恢复。那就挂了呗,反正不会导致数据一致性问题。

    • 第二个是挂了之后又恢复了,这时如果他有未执行完的事务操作,直接取消掉,然后询问协调者目前我应该怎么做,协调者就会比对自己的事务执行记录和该参与者的事务执行记录,告诉他应该怎么做来保持数据的一致性。


    情况三:参与者挂了,协调者也挂了

    这种情况比较复杂,我们分情况讨论。

    • 协调者和参与者在第一阶段挂了。

      • 由于这时还没有执行commit操作,新选出来的协调者可以询问各个参与者的情况,再决定是进行commit还是roolback。因为还没有commit,所以不会导致数据一致性问题。
    • 第二阶段协调者和参与者挂了,挂了的这个参与者在挂之前并没有接收到协调者的指令,或者接收到指令之后还没来的及做commit或者roolback操作。

      • 这种情况下,当新的协调者被选出来之后,他同样是询问所有的参与者的情况。只要有机器执行了abort(roolback)操作或者第一阶段返回的信息是No的话,那就直接执行roolback操作。如果没有人执行abort操作,但是有机器执行了commit操作,那么就直接执行commit操作。这样,当挂掉的参与者恢复之后,只要按照协调者的指示进行事务的commit还是roolback操作就可以了。因为挂掉的机器并没有做commit或者roolback操作,而没有挂掉的机器们和新的协调者又执行了同样的操作,那么这种情况不会导致数据不一致现象。
    • 第二阶段协调者和参与者挂了,挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了,没有人知道他执行了什么操作。

      • 这种情况下,新的协调者被选出来之后,如果他想负起协调者的责任的话他就只能按照之前那种情况来执行commit或者roolback操作。这样新的协调者和所有没挂掉的参与者就保持了数据的一致性,我们假定他们执行了commit。但是,这个时候,那个挂掉的参与者恢复了怎么办,因为他之前已经执行完了之前的事务,如果他执行的是commit那还好,和其他的机器保持一致了,万一他执行的是roolback操作那?这不就导致数据的不一致性了么?虽然这个时候可以再通过手段让他和协调者通信,再想办法把数据搞成一致的,但是,这段时间内他的数据状态已经是不一致的了!

    所以,2PC协议中,如果出现协调者和参与者都挂了的情况,有可能导致数据不一致。

    为了解决这个问题,衍生除了3PC。我们接下来看看3PC是如何解决这个问题的。

    三阶段提交协议(3PC)

    3PC最关键要解决的就是协调者和参与者同时挂掉的问题,所以3PC把2PC的准备阶段再次一分为二,这样三阶段提交就有CanCommitPreCommitDoCommit三个阶段。在第一阶段,只是询问所有参与者是否可可以执行事务操作,并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时,在第二阶段才执行事务操作,然后在第三阶段在执行commit或者rollback。

    这里再举一个生活中类似三阶段提交的例子:

    班长要组织全班同学聚餐,由于大家毕业多年,所以要逐个打电话敲定时间,时间初定10.1日。然后开始逐个打电话。

    班长:小A,我们想定在10.1号聚会,你有时间嘛?有时间你就说YES,没有你就说NO,然后我还会再去问其他人,具体时间地点我会再通知你,这段时间你可先去干你自己的事儿,不用一直等着我。(协调者询问事务是否可以执行,这一步不会锁定资源

    小A:好的,我有时间。(参与者反馈

    班长:小B,我们想定在10.1号聚会……不用一直等我。

    班长收集完大家的时间情况了,一看大家都有时间,那么就再次通知大家。(协调者接收到所有YES指令

    班长:小A,我们确定了10.1号聚餐,你要把这一天的时间空出来,这一天你不能再安排其他的事儿了。然后我会逐个通知其他同学,通知完之后我会再来和你确认一下,还有啊,如果我没有特意给你打电话,你就10.1号那天来聚餐就行了。对了,你确定能来是吧?(协调者发送事务执行指令,这一步锁住资源。如果由于网络原因参与者在后面没有收到协调者的命令,他也会执行commit

    小A顺手在自己的日历上把10.1号这一天圈上了,然后跟班长说,我可以去。(参与者执行事务操作,反馈状态

    班长:小B,我们觉得了10.1号聚餐……你就10.1号那天来聚餐就行了。

    班长通知完一圈之后。所有同学都跟他说:”我已经把10.1号这天空出来了”。于是,他在10.1号这一天又挨个打了一遍电话告诉他们:嘿,现在你们可以出门拉。。。。(协调者收到所有参与者的ACK响应,通知所有参与者执行事务的commit

    小A,小B:我已经出门拉。(执行commit操作,反馈状态

    3PC为什么比2PC好?

    直接分析协调者和参与者都挂的情况。

    • 第二阶段协调者和参与者挂了,挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了,没有人知道他执行了什么操作。

      • 这种情况下,当新的协调者被选出来之后,他同样是询问所有的参与者的情况来觉得是commit还是roolback。这看上去和二阶段提交一样啊?他是怎么解决一致性问题的呢?

      • 看上去和二阶段提交的那种数据不一致的情况的现象是一样的,但仔细分析所有参与者的状态的话就会发现其实并不一样。我们假设挂掉的那台参与者执行的操作是commit。那么其他没挂的操作者的状态应该是什么?他们的状态要么是prepare-commit要么是commit。因为3PC的第三阶段一旦有机器执行了commit,那必然第一阶段大家都是同意commit。所以,这时,新选举出来的协调者一旦发现未挂掉的参与者中有人处于commit状态或者是prepare-commit的话,那就执行commit操作。否则就执行rollback操作。这样挂掉的参与者恢复之后就能和其他机器保持数据一致性了。(为了简单的让大家理解,笔者这里简化了新选举出来的协调者执行操作的具体细节,真实情况比我描述的要复杂)

    简单概括一下就是,如果挂掉的那台机器已经执行了commit,那么协调者可以从所有未挂掉的参与者的状态中分析出来,并执行commit。如果挂掉的那个参与者执行了rollback,那么协调者和其他的参与者执行的肯定也是rollback操作。

    所以,再多引入一个阶段之后,3PC解决了2PC中存在的那种由于协调者和参与者同时挂掉有可能导致的数据一致性问题。

    3PC存在的问题

    在doCommit阶段,如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时,会在等待超时之后,会继续进行事务的提交。

    所以,由于网络原因,协调者发送的abort响应没有及时被参与者接收到,那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

    展开全文
  • 关注我的博客(http://www.hollischuang.com)的人可能都知道,我之前写过一篇文章专门介绍了一下2PC和3PC(详见:关于分布式事务、两阶段提交协议、三阶提交协议)。上一篇文章中主要介绍了下这两种分布式一致性...

    关注我的博客(http://www.hollischuang.com)的人可能都知道,我之前写过一篇文章专门介绍了一下2PC和3PC(详见:关于分布式事务、两阶段提交协议、三阶提交协议)。上一篇文章中主要介绍了下这两种分布式一致性协议的概念、具体提交流程以及优缺点。本文在上篇文章的基础上在深入了解下这两种分布式一致性协议。主要来分析下为什么2PC存在数据一致性问题,3PC是如何解决了部分2PC存在的问题的,以及为什么3PC还存在可能导致数据不一致的情况。

    对分布式系统的概念及2PC和3PC不了解的朋友建议先阅读分布式系列文章

    协调者

    在分布式系统中,每一个机器节点虽然都能明确的知道自己执行的事务是成功还是失败,但是却无法知道其他分布式节点的事务执行情况。因此,当一个事务要跨越多个分布式节点的时候(比如,淘宝下单流程,下单系统和库存系统可能就是分别部署在不同的分布式节点中),为了保证该事务可以满足ACID,就要引入一个协调者(Cooradinator)。其他的节点被称为参与者(Participant)。协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务进行提交。

    二阶段提交协议(2PC)

    二阶段提交协议主要分为来个阶段:准备阶段和提交阶段。

    在日常生活中其实是有很多事都是这种二阶段提交的,比如西方婚礼中就经常出现这种场景:

    牧师:”你愿意娶这个女人吗?爱她、忠诚于她,无论她贫困、患病或者残疾,直至死亡。Doyou(你愿意吗)?”

    新郎:”Ido(我愿意)!”

    牧师:”你愿意嫁给这个男人吗?爱他、忠诚于他,无论他贫困、患病或者残疾,直至死亡。Doyou(你愿意吗)?”

    新娘:”Ido(我愿意)!”

    牧师:现在请你们面向对方,握住对方的双手,作为妻子和丈夫向对方宣告誓言。

    新郎:我——某某某,全心全意娶你做我的妻子,无论是顺境或逆境,富裕或贫穷,健康或疾病,快乐或忧愁,我都将毫无保留地爱你,我将努力去理解你,完完全全信任你。我们将成为一个整体,互为彼此的一部分,我们将一起面对人生的一切,去分享我们的梦想,作为平等的忠实伴侣,度过今后的一生。

    新娘:我全心全意嫁给你作为你的妻子,无论是顺境或逆境,富裕或贫穷,健康或疾病,快乐或忧愁,我都将毫无保留的爱你,我将努力去理解你,完完全全信任你,我们将成为一个整体,互为彼此的一部分,我们将一起面对人生的一切,去分享我们的梦想,作为平等的忠实伴侣,度过今后的一生。

    上面这个比较经典的桥段就是一个典型的二阶段提交过程。

    首先协调者(牧师)会询问两个参与者(二位新人)是否能执行事务提交操作(愿意结婚)。如果两个参与者能够执行事务的提交,先执行事务操作,然后返回YES,如果没有成功执行事务操作,就返回NO。

    当协调者接收到所有的参与者的反馈之后,开始进入事务提交阶段。如果所有参与者都返回YES,那就发送COMMIT请求,如果有一个人返回NO,那就返送roolback请求。

    值得注意的是,二阶段提交协议的第一阶段准备阶段不仅仅是回答YES or NO,还是要执行事务操作的,只是执行完事务操作,并没有进行commit还是roolback。和上面的结婚例子不太一样。如果非要举例的话可以理解为男女双方交换定情信物的过程。信物一旦交给对方了,这个信物就不能挪作他用了。也就是说,一旦事务执行之后,在没有执行commit或者roolback之前,资源是被锁定的。这会造成阻塞。


    2PC存在的问题

    下面我们来分析下2PC存在的问题。

    这里暂且不谈2PC存在的同步阻塞、单点问题、脑裂等问题(上篇文章中有具体介绍),我们只讨论下数据一致性问题。作为一个分布式的一致性协议,我们主要关注他可能带来的一致性问题的。


    2PC在执行过程中可能发生协调者或者参与者突然宕机的情况,在不同时期宕机可能有不同的现象。


    情况一:协调者挂了,参与者没挂

    这种情况其实比较好解决,只要找一个协调者的替代者。当他成为新的协调者的时候,询问所有参与者的最后那条事务的执行情况,他就可以知道是应该做什么样的操作了。所以,这种情况不会导致数据不一致。


    情况二:参与者挂了,协调者没挂

    这种情况其实也比较好解决。如果协调者挂了。那么之后的事情有两种情况:

    • 第一个是挂了就挂了,没有再恢复。那就挂了呗,反正不会导致数据一致性问题。

    • 第二个是挂了之后又恢复了,这时如果他有未执行完的事务操作,直接取消掉,然后询问协调者目前我应该怎么做,协调者就会比对自己的事务执行记录和该参与者的事务执行记录,告诉他应该怎么做来保持数据的一致性。


    情况三:参与者挂了,协调者也挂了

    这种情况比较复杂,我们分情况讨论。

    • 协调者和参与者在第一阶段挂了。

      • 由于这时还没有执行commit操作,新选出来的协调者可以询问各个参与者的情况,再决定是进行commit还是roolback。因为还没有commit,所以不会导致数据一致性问题。
    • 第二阶段协调者和参与者挂了,挂了的这个参与者在挂之前并没有接收到协调者的指令,或者接收到指令之后还没来的及做commit或者roolback操作。

      • 这种情况下,当新的协调者被选出来之后,他同样是询问所有的参与者的情况。只要有机器执行了abort(roolback)操作或者第一阶段返回的信息是No的话,那就直接执行roolback操作。如果没有人执行abort操作,但是有机器执行了commit操作,那么就直接执行commit操作。这样,当挂掉的参与者恢复之后,只要按照协调者的指示进行事务的commit还是roolback操作就可以了。因为挂掉的机器并没有做commit或者roolback操作,而没有挂掉的机器们和新的协调者又执行了同样的操作,那么这种情况不会导致数据不一致现象。
    • 第二阶段协调者和参与者挂了,挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了,没有人知道他执行了什么操作。

      • 这种情况下,新的协调者被选出来之后,如果他想负起协调者的责任的话他就只能按照之前那种情况来执行commit或者roolback操作。这样新的协调者和所有没挂掉的参与者就保持了数据的一致性,我们假定他们执行了commit。但是,这个时候,那个挂掉的参与者恢复了怎么办,因为他之前已经执行完了之前的事务,如果他执行的是commit那还好,和其他的机器保持一致了,万一他执行的是roolback操作那?这不就导致数据的不一致性了么?虽然这个时候可以再通过手段让他和协调者通信,再想办法把数据搞成一致的,但是,这段时间内他的数据状态已经是不一致的了!

    所以,2PC协议中,如果出现协调者和参与者都挂了的情况,有可能导致数据不一致。

    为了解决这个问题,衍生除了3PC。我们接下来看看3PC是如何解决这个问题的。

    三阶段提交协议(3PC)

    3PC最关键要解决的就是协调者和参与者同时挂掉的问题,所以3PC把2PC的准备阶段再次一分为二,这样三阶段提交就有CanCommitPreCommitDoCommit三个阶段。在第一阶段,只是询问所有参与者是否可可以执行事务操作,并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时,在第二阶段才执行事务操作,然后在第三阶段在执行commit或者rollback。

    这里再举一个生活中类似三阶段提交的例子:

    班长要组织全班同学聚餐,由于大家毕业多年,所以要逐个打电话敲定时间,时间初定10.1日。然后开始逐个打电话。

    班长:小A,我们想定在10.1号聚会,你有时间嘛?有时间你就说YES,没有你就说NO,然后我还会再去问其他人,具体时间地点我会再通知你,这段时间你可先去干你自己的事儿,不用一直等着我。(协调者询问事务是否可以执行,这一步不会锁定资源

    小A:好的,我有时间。(参与者反馈

    班长:小B,我们想定在10.1号聚会……不用一直等我。

    班长收集完大家的时间情况了,一看大家都有时间,那么就再次通知大家。(协调者接收到所有YES指令

    班长:小A,我们确定了10.1号聚餐,你要把这一天的时间空出来,这一天你不能再安排其他的事儿了。然后我会逐个通知其他同学,通知完之后我会再来和你确认一下,还有啊,如果我没有特意给你打电话,你就10.1号那天来聚餐就行了。对了,你确定能来是吧?(协调者发送事务执行指令,这一步锁住资源。如果由于网络原因参与者在后面没有收到协调者的命令,他也会执行commit

    小A顺手在自己的日历上把10.1号这一天圈上了,然后跟班长说,我可以去。(参与者执行事务操作,反馈状态

    班长:小B,我们觉得了10.1号聚餐……你就10.1号那天来聚餐就行了。

    班长通知完一圈之后。所有同学都跟他说:”我已经把10.1号这天空出来了”。于是,他在10.1号这一天又挨个打了一遍电话告诉他们:嘿,现在你们可以出门拉。。。。(协调者收到所有参与者的ACK响应,通知所有参与者执行事务的commit

    小A,小B:我已经出门拉。(执行commit操作,反馈状态

    3PC为什么比2PC好?

    直接分析协调者和参与者都挂的情况。

    • 第二阶段协调者和参与者挂了,挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了,没有人知道他执行了什么操作。

      • 这种情况下,当新的协调者被选出来之后,他同样是询问所有的参与者的情况来觉得是commit还是roolback。这看上去和二阶段提交一样啊?他是怎么解决一致性问题的呢?

      • 看上去和二阶段提交的那种数据不一致的情况的现象是一样的,但仔细分析所有参与者的状态的话就会发现其实并不一样。我们假设挂掉的那台参与者执行的操作是commit。那么其他没挂的操作者的状态应该是什么?他们的状态要么是prepare-commit要么是commit。因为3PC的第三阶段一旦有机器执行了commit,那必然第一阶段大家都是同意commit。所以,这时,新选举出来的协调者一旦发现未挂掉的参与者中有人处于commit状态或者是prepare-commit的话,那就执行commit操作。否则就执行rollback操作。这样挂掉的参与者恢复之后就能和其他机器保持数据一致性了。(为了简单的让大家理解,笔者这里简化了新选举出来的协调者执行操作的具体细节,真实情况比我描述的要复杂)

    简单概括一下就是,如果挂掉的那台机器已经执行了commit,那么协调者可以从所有未挂掉的参与者的状态中分析出来,并执行commit。如果挂掉的那个参与者执行了rollback,那么协调者和其他的参与者执行的肯定也是rollback操作。

    所以,再多引入一个阶段之后,3PC解决了2PC中存在的那种由于协调者和参与者同时挂掉有可能导致的数据一致性问题。

    3PC存在的问题

    在doCommit阶段,如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时,会在等待超时之后,会继续进行事务的提交。

    所以,由于网络原因,协调者发送的abort响应没有及时被参与者接收到,那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

    参考资料

    2PC和3PC一点理解

    再谈2PC和3PC

    展开全文
  • pc移动端的区别

    千次阅读 2019-08-06 15:09:28
    而对于手机端来说,包含手指操作点击、滑动、双击、双指放大、双指缩小、五指收缩苹果最新的3Dtouch按压力度,除了手指操作外还可以配合传感器完成摇一摇、陀悬仪感应灯操作方式,操作方式更加的丰富,通过这些...

    1、操作方式不同

    PC端的操作方式与移动端已经有了明显的差别,PC端使用鼠标操作,操作包含滑动、左击、右击、双击操作,操作相对来说单一,交互效果相对较少。

    而对于手机端来说,包含手指操作点击、滑动、双击、双指放大、双指缩小、五指收缩和苹果最新的3Dtouch按压力度,除了手指操作外还可以配合传感器完成摇一摇、陀悬仪感应灯操作方式,操作方式更加的丰富,通过这些丰富的操作可设计不同新颖吸引人的交互互动设计。  

    2、屏幕尺寸不同

    随着时间的推移,移动端的设备屏幕逐渐增大,但是你再大也是大不过PC电脑屏幕的,这是毋庸置疑的。PC端屏幕大,所以他的视觉范围更广,可设计的地方更多,设计性更强,相对来说容错度更高一些有一些小的纰漏不容易被发现。

    移动端设备相对来说屏幕较小,操作局限性大,在设计上可用空间显得尤为珍贵,在小小的屏幕上使用粗大的手指操作也需要在设计中避免原件过小过近。

    3、网络环境不同 

    当下不管是移动端还是PC端都离不开网络,PC端设备连接网络更加稳定,而移动端可能遇到信号问题导致网络环境不佳,出现网速差甚至断网的问题,这就需要在设计中充分考虑网络问题,更好的设计相应的解决方案。  

    4、传感器不同

    移动端设备完善的传感器是PC端设备望尘莫及的,压力、方向、重力、GPS、NFC、指纹识别、3Dtouch、陀螺仪等等等等,就是因为这些传感器的存在才使得产品在设计中巧妙地使用传感器能让产品添姿加彩。  

    5、使用场景与使用时间不同 

    因为PC端设备的使用场景多为在家或者学校公司等一些固定的场景,所以其使用时间偏向于持续化,在一个特定的时间段内持续使用,而移动端设备不受局限,随时随地想用就用,所以使用时间更加灵活,时间更加碎片化,所以在操作上更偏向于短时间内可完成的。

    展开全文
  • Zookeeper系列(2)--2PC3PC及其应用

    万次阅读 多人点赞 2018-01-31 17:04:40
    以及相关分布式理论:CAP/BASE理论,这些是我们进行后边介绍的分布式一致性算法的基础,正是由于在系统的可用性数据一致性之间反复的权衡,于是出现了一系列的一致性协议,如2PC3PC,paxos算法等。本篇就介绍两...
  • 2PC/3PC到底是啥

    千次阅读 2018-07-22 20:15:21
    讨论 提到2PC/3PC首先想到的是它是一致性协议,而且经常把...但另一方面又经常看到2PC/3PC和分布式事务放在一起讨论,并且大部分的关系型数据库通过两阶段提交(2 Phase Commit 2PC)算法来完成分布式事务。 先大...
  • 2PC和3PC中故障情况分析

    千次阅读 2017-12-01 12:58:08
    2PC故障情况分析1. 协调者正常,参与者宕机 发生在第二阶段:无论协调者发起的是提交还是终止,那宕机的参与者在重启之后,都将执行对应操作,不存在不一致情况。 发生在第一阶段:由于协调者无法收集到所有参与者的...
  • 2pc & 3pc

    千次阅读 2020-05-30 18:32:05
    2pc&3pc问题 本质: 2pcTM超时机制 3pc加入事务询问机制+RM超时机制 事务询问机制:减少阻塞 RM超时机制:避免死锁 2pc 3pc 参考: https://juejin.im/post/5aa3c7736fb9a028bb189bca#heading-1 ...
  • Spring Cloud 分布式事务管理(二)2pc/3pc
  • 前端:移动端和PC端的区别

    万次阅读 2018-08-06 14:48:29
    在阿里的几次面试中,总是被问到移动端和PC端有什么区别,当时回答的时候主要是回答了在兼容性、网速、适配、页面布局等方面的不同,但是还是很不系统,所以这里做一个总结。   第一: PC考虑的是浏览器的兼容性...
  • 分布式事务:深入理解什么是2PC3PC及TCC协议

    万次阅读 多人点赞 2019-01-23 08:48:00
    1导读对于分布式事务的概念,可能还会有很多同学不理解或者理解得不是很深刻的地方,在这篇文章中,作者打算重点给大家先介绍下分布式事务相关的基本概念,诸如2PC3PC、TC...
  • web页面PC移动端的区别

    万次阅读 2018-10-17 10:48:13
    PC移动端的区别你知道吗? 截至2015年11月,中国手机上网用户数已超过9.05亿,软件移动化成为一种趋势,移动产品经理成为了产品经理的一个重要分支,那么对于移动端和PC端到底有什么区别呢?在设计过程中有什么...
  • 分布式系统分布式一致性问题 ...2PC(Two-Phase Commit 二阶段提交)   二阶段提交,是指将事务提交分成两个部分:准备阶段提交阶段。事务的发起者称之为协调者,事务的执行者称为参与者。 阶段一:...
  • PT px pc区别

    千次阅读 2019-04-01 16:57:59
    看了一会HTML CSS 在CSS练习中发现 有 px pc pt 三种提示, 不明白是为什么.SO 度娘了一下 PT px pc 三者都是度量单位 pt 点(Point)。绝对长度单位。 1in = 2.54cm = 25.4 mm = 72pt = 6pc px [CSS 中推荐...
  • PC和IR的区别

    千次阅读 2020-03-31 22:01:32
    IR:是用来存放指令的, PC:是用来表示指令的在主存中的地址,执行完一条指令后,PC+1,即指向下...
  • 分布式事务2PC和TCC有啥不同

    千次阅读 2019-08-18 23:15:12
    一、 什么是2PC 2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase)、提交阶段(commit phase),2是指两个阶段,P是指准备阶段,C是指提交阶段。 举例:张三和李四好久不见,老友约起...
  • 【材料】 塑料件 ABS PC区别

    千次阅读 2019-10-17 21:01:15
    1、ABS PC区别 ABS 是普通料,价格便宜;PC 是工程塑料,价格比较贵。 外观: ABS 一般都是不透明,PC 一般都是透明。 韧性: ABS 韧性差,PC 韧性好。 其他: ABS 性能耐腐蚀,高强度,高抗冲击,耐...
  • 这篇文章将介绍分布式事务中的多种实现方案,及各种分布式事务方案的实现原理、事务执行过程、优缺点,读完这篇文章相信你会对2PC3PC、TCC、MQ事务消息有个详细的了解 分布式事务的处理方法有哪些? XA协议:...
  • 详解PowerPC、X86ARM架构区别

    千次阅读 多人点赞 2020-01-14 08:03:00
    在嵌入式领域,存在着三种处理器通用的架构,PowerPC、X86、ARM,本文将对这三种架构进行对比分析。1、PowerPC的由来1975年, IMB 公司801 小型计算机工程在RI...
  • 我们想要实现PC1 ping 通PC3、PC2 ping通PC3、PC1 ping 不通PC2对吧,在你把这个拓扑图搭建好后,理论上来讲PC1 PC2 PC3就能相互通(这个不用解释的吧,因为是交换机嘛),下面来对交换机进行配置达到我们的要求: ...
  • seata实现2PC与传统2PC实现方式的差异

    千次阅读 2019-10-24 18:18:49
    https://edu.csdn.net/course/play/25967/318766Seata执行的要点
  • 分布式事务_三阶段提交(3PC)协议

    千次阅读 2019-02-28 16:49:49
    在BASE理论中,业界大佬通过长时间的测试总结,设计出了二阶段提交协议(2PC),但是2PC设计中还存在缺陷,于是就有了三阶段提交协议,这便是3PC的诞生背景。 1. 三阶段提交协议  三阶段提交(Three-phase commit...
  • H5、PC APP之间的区别与共同点

    千次阅读 2019-04-19 15:22:00
    从市场的占比来说:APP --->... (2)通常来讲,手机端和PC端对应的是一套后台服务 不同之处 一、容器不同,(测试平台与安装打开方式)  (1)PC端  PC端是电脑测试,有BS架构...
  • PC移动端的区别

    千次阅读 2018-09-01 01:56:01
    1.PC考虑的是浏览器的兼容性,而移动端开发考虑的更多的是手机兼容性,因为目前不管是android手机还是ios手机,一般浏览器使用的都是webkit内核,所以说做移动端开发,更多考虑的应该是手机分辨率的适配,不同操作...
  • 2pc(Two Phase Commitment Protocol)当一个事务操作需要跨越多个分布式节点的时候,为了保持事务处理的 ACID特性,就需要引入一个“协调者”(TM)来统一调度所有分布式节点的执行逻辑,这些被调度的分布式节点被...
  • Python开发企业级标准环境搭建

    千人学习 2019-12-29 10:08:08
    都说工欲善其事必先利其器,本课程讲帮助小白,刚转行python程序员,从无到有,搭建python相关生产环境,课程设计两套系统,linux + windows环境下的软件安装。软件安装范围有pycharm , anaconda , sublime ,jupyter ...
  • 1、PC移动端有什么区别  从我个人角度来说,我觉得PC端的定位就是用户视觉浏览路线,可以显示较多的内容,而移动互联网终端的定位就是便携,体现的是“Anyone Anytime Anywhere”的理念,它不是替代PC的设备...
  • Java面试Offer直通车

    万人学习 2019-12-18 15:19:52
    2、这门课程基于胡书敏老师8年Java面试经验,调研近百家互联网公司及面试官的问题打造而成,从筛选简历面试官角度,给出能帮助候选人能面试成功的面试技巧。 3、通过学习这门课程,你能系统掌握Java核心、数据库、...
  • 本文章是介绍pc端基于px2rem-loaderlib-flexible实现的px转rem的适配方案 我的本地环境是vue2.0 1.安装 npm install px2rem-loader -D npm install lib-flexible -S 2.配置 在build文件夹下的utils....
  • 移动端和PC端的区别

    千次阅读 2019-02-26 14:12:40
    被问到移动端和PC端有什么区别,当时回答的时候主要是回答了在兼容性、网速、适配、页面布局等方面的不同,但是还是很不系统,所以这里做一个总结。 第一: PC考虑的是浏览器的兼容性,而移动端开发考虑的更多的是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,053,977
精华内容 421,590
关键字:

2pc和3pc的区别