&&[&&中关村在线 原创&&]&& 作者：&&|&&责编：李诺
　　通过对PC第一、二发展阶段的梳理我们能看到“改变”是一个非常重要的关键词，第一阶段改变了我们的工作方式，第二阶段改变了我们的沟通方式，而第三阶段将改变我们的生活方式。　　对好莱坞漫画英雄感兴趣的朋友估计对钢铁侠的贾维斯（J.A.R.V.I.S.）印象深刻，确切的说贾维斯是运行在PC上的，而此时的PC已经远远超出了我们目前的认知，它没有固定的形态，交互方式也主要通过对话、手势。当然，贾维斯在目前来看还过于科幻，却让我们看到了未来PC的一个雏形：智能AI+万物互联。钢铁侠中的贾维斯　　第一、二阶段的PC扮演的是纸笔和一扇门，而第三阶段则扮演的是枢纽，这个枢纽则连通了生活习惯和周围一切。举个例子，在未来叫醒你的不是闹钟，而是清晨的一缕阳光。智能AI通过对生活习惯的记录判断最佳起床时间，然后控制窗帘自动打开。这不是幻想，以目前的技术能力已经可以实现了。　　不过看似简单的过程，中间却需要大量的数据积累和处理，对于性能的要求更为苛刻，而性能正是PC的强项。第三阶段的PC可能没有固定形态，也可能是以云服务的形式存在。而手机则会成为PC的输入输出设备，与现在键鼠、显示器的定位差不多。　　看到这估计大家就明白了为什么商业巨头争先抢占智能AI和智能家居领域，这不仅是PC的未来，也是我们生活的未来。谷歌AlphaGo　　现在我们能够看到在智能AI和万物互联两个方面的相关产品。比如智能AI方面，包括苹果Siri、微软Cortana和之前很火的谷歌AlphaGo等；万物互联方面就丰富多彩了，智能开关、智能门锁、智能灯泡等。不过无论是智能AI还是万物互联，目前仍然处在比较初期的阶段，最明显的表现就是：不智能、不好使。　　除了技术方面的局限外，笔者认为最大的局限还在于资本。本文属于原创文章，如若转载，请注明来源：.cn/636/6367933.html
提示：支持键盘“← →”键翻页
产品定位 屏幕尺寸
投诉欺诈商家:
天津重庆哈尔滨沈阳长春石家庄呼和浩特西安太原兰州乌鲁木齐成都昆明贵阳长沙武汉郑州济南青岛烟台合肥南京杭州东莞南宁南昌福州厦门深圳温州佛山宁波泉州惠州银川
本城市下暂无经销商
4￥107885￥98886￥84857￥65888￥43999￥639910￥8699两阶段提交-2PC - CSDN博客
两阶段提交-2PC
two phase commit protocol，<span style="color:#PC）可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的一致性算法。该算法能够解决很多的临时性系统故障（包括进程、网络节点、通信等故障），被广泛地使用。但是，它并不能够通过配置来解决所有的故障，在某些情况下它还需要人为的参与才能解决问题。参与者为了能够从故障中恢复，它们都使用日志来记录协议的状态，虽然使用日志降低了性能但是节点能够从故障中恢复。
在两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。协议中假设每个节点都会记录写前日志（write-ahead
log）并持久性存储，即使节点发生故障日志也不会丢失。协议中同时假设节点不会发生永久性故障而且任意两个节点都可以互相通信。
当事务的最后一步完成之后，协调器执行协议，参与者根据本地事务能够成功完成回复同意提交事务或者回滚事务。
顾名思义，两阶段提交协议由两个阶段组成。
在正常的执行下，这两个阶段的执行过程如下所述：
阶段1：请求阶段（commit-requestphase，或称表决阶段，votingphase）
在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
阶段2：提交阶段（commitphase）
在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
两阶段提交协议最大的劣势是其通过阻塞完成的协议，在节点等待消息的时候处于阻塞状态，节点中其他进程则需要等待阻塞进程释放资源才能使用。如果协调器发生了故障，那么参与者将无法完成事务则一直等待下去。
以下情况可能会导致节点发生永久阻塞：
如果参与者发送同意提交消息给协调者，进程将阻塞直至收到协调器的提交或回滚的消息。如果协调器发生永久故障，参与者将一直等待，这里可以采用备份的协调器，所有参与者将回复发给备份协调器，由它承担协调器的功能。
如果协调器发送“请求提交”消息给参与者，它将被阻塞直到所有参与者回复了，如果某个参与者发生永久故障，那么协调器也不会一直阻塞，因为协调器在某一时间内还未收到某参与者的消息，那么它将通知其他参与者回滚事务。
同时两阶段提交协议没有容错机制，一个节点发生故障整个事务都要回滚，代价比较大。
(a verygood example)
下面我们通过一个例子来说明两阶段提交协议的工作过程：
A组织B、C和D三个人去爬长城：如果所有人都同意去爬长城，那么活动将举行；如果有一人不同意去爬长城，那么活动将取消。用<span style="color:#PC算法解决该问题的过程如下：
首先A将成为该活动的协调者，B、C和D将成为该活动的参与者。
阶段<span style="color:#：
A发邮件给B、C和D，提出下周三去爬山，问是否同意。那么此时A需要等待B、C和D的邮件。
B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。由于某种原因，D白天没有查看邮件。那么此时A、B和C均需要等待。到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。
阶段<span style="color:#：
此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。那么A将发邮件通知B、C和D，下周三爬长城活动取消。
此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。
通过该例子可以发现，<span style="color:#PC协议存在明显的问题。假如D一直不能回复邮件，那么A、B和C将不得不处于一直等待的状态。并且B和C所持有的资源，即下周三不能安排其它活动，一直不能释放。其它等待该资源释放的活动也将不得不处于等待状态。
基于此，后来有人提出了三阶段提交协议，在其中引入超时的机制（2阶段提交协议的变种协议中也有相应的超时机制），将阶段<span style="color:#分解为两个阶段：在超时发生以前，系统处于不确定阶段；在超市发生以后，系统则转入确定阶段。
<span style="color:#PC协议包含协调者和参与者，并且二者都有发生问题的可能性。假如协调者发生问题，我们可以选出另一个协调者来提交事务。例如，班长组织活动，如果班长生病了，我们可以请副班长来组织。如果协调者出问题，那么事务将不会取消。例如，班级活动希望每个人都能去，假如有一位同学不能去了，那么直接取消活动即可。或者，如果大多数人去的话那么活动如期举行（<span style="color:#PC变种）。为了能够更好地解决实际的问题，2PC协议存在很多的变种，例如：树形2PC协议（或称递归2PC协议）、动态2阶段提交协议（D2PC）等。
理想的时候：没有异常
此时，我们假设所有参与者、网络都不会出现异常，这种情况下2PC没有任何难度。
协调者向所有参与者发出VOTE_REQUEST请求，然后 协调者阻塞等待所有参与者的响应 参与者在收到VOTE_REQUEST的时候，执行事务预处理，根据预处理的结果响应协调者：VOTE_COMMIT或者VOTE_ABORT； 然后参与者等待协调者的最后决定(global_decision)
协调者等待所有的参与者的响应，如果所有参与者都响应VOTE_COMMIT，那么协调者就向所有参与者发出GLOBAL_COMMIT； 如果至少有一个参与者响应VOTE_ABORT，那么协调者就向所有参与者发出GLOBAL_ABORT
参与者根据协调者的决定(global_decision)在本地进行事务操作
下面看下具体示意图：
图一 &事务提交
图二 事务回滚
在理想的时代，一切都是完美的，一切都是简单的。
协调者的状态转移图如下：
参与者的状态转移图如下：
次理想的时候：节点、网络异常会最终恢复
最糟糕的时候：协调者和参与者在死亡后无法恢复
2PC很无辜的看着大家，其实这个与我无关。听我详细道来。
本节的算法摘自《Distributed Systems: Principles and Paradigms》。
Actions of Coordinator
write(&START_2PC tolocal log&);
multicast(&VOTE_REQUESTto all participants&);
while(not all votes have been collected)
& waitfor(&any incoming vote&);
&&if(timeout)
&&& write(&GLOBAL_ABORT to local host&);
&&& multicast(&GLOBAL_ABORT to all participants&);
&&& exit();
& record(vote);
if(all participants send VOTE_COMMIT and coordinatorvotes COMMIT)
& write(&GLOBAL_COMMIT to local log&);
& multicast(&GLOBAL_COMMIT to all participants&);
& write(&GLOBAL_ABORT to local log&);
& multicast(&GLOBAL_ABORT to all participants&);
Actions of Participantsdata/Main/TwoPhaseCommit.txt
write(&INIT to locallog&);
waitfor(&VOTE_REQUESTfrom coordinator&);
if(timeout)
& write(&VOTE_ABORT to local log&);
if(&participantvotes COMMIT&)
& write(&VOTE_COMMIT to local log&);
& send(&VOTE_COMMIT to coordinator&);
& waitfor(&DESCISION from coordinator&);
&&if(timeout)
&&& multicast(&DECISION_REQUEST to other participants&);
&&& waituntil(&DECISION is received&);&/// remain blocked
&&& write(&DECISION to local log&);
&&if(DECISION ==&&GLOBAL_COMMIT&)
&&& write(&GLOBAL_COMMIT to local log&);
&&else&if(DECISION==&&GLOBAL_ABORT&)
&&& write(&GLOBAL_ABORT to local log&);
&&& write(&GLOBAL_ABORT to local log&);
&&& send(&GLOBAL_ABORT to coordinator&);
<span style="color:#PC这个协议本身其实本不难，难的是很多人（包括我自己）在学习算法本身的时候会思考如何把他应用在实际系统上。是想，如果我们假设任何阶段coordinator或者participant出现异常，那么整个算法就停止在那个地方一直循环等待，直到退出的节点恢复，算法才继续往前走，这个算法其实一点难度都没有。但是每个人都会思考，这样的算法在实际过程中还有用吗？实际过程中 的工程师们是如何来处理这个问题的？只要一思考这些，读者就会觉得怎么都不对。其实就2PC而言，他本来就是一个阻塞的算法，
在所有participant都响应VOTE_REQUEST之后，在收到DECISION之前，coordinator宕机，那么算法就会一直阻塞，因为没有人 知道最后的decision是什么。既然它天生就是阻塞的，那么我们直接再弱化一下它好了，任何步骤主要出现异常，算法都阻塞。这样理解到的才是算法的实质。
可能有人会问，上面算法中有的地方在超时后会进行一些操作，然后算法可以继续；有些地方在超时后算法无法继续；这是为什么？什么时候决定算法可以继续，什么时候应该阻塞？以我对算法本身的理解，继续还是阻塞的标准是：
是否会导致事务的结果处于一种不一致的状态（一部分参与者commit，一部分参与者abort）；如果不会出现不一致的情况， 那么算法可以继续；否则就必须阻塞。
可以这么理解：非阻塞的部分是算法的优化。算法继续，唯一会出现不一致状态的情况是，所有的参与者都响应了VOTE_REQUEST，在 任何参与者收到decision之前coordinator宕机死亡，此时所有参与者都必须等待coordinator恢复。
有个的观点：所有参与者(包括协调者)都必须通过多副本的方式保证自己的高可用性， 因为单副本不可用的问题不是2PC这个协议的目的，如果没有2PC这个协议，单副本的不可用性也是存在的，因此这种问题与2PC无关。可以说2PC本身不解决高可用性问题，它仅仅
解决的是atomic group commit的问题，这是2PC的假设，也是理解2PC的关键。一句话：每个协议解决自己的问题，不要带着你面临的 n个问题来理解2PC(包括其他分布式协议)，这样只能使你自己陷入死角。
大家会说，那么每个协议如果这样去了解，岂不是都很简单，我作为架构师的最终目的是实现高可用的系统，而不是分开理解每个协议。呵呵，可以理解，我和大家一样由于这个想法走了很多的弯路。我会后续慢慢的告诉大家2PC如何在高可用的系统中使用。在分布式一致性这一系列文章中，我会为大家逐一解开谜底。
看google如何使用2PC实现实时搜索，通过BigTable自身的高可用性解决解决participants的高可用性问题；通过
解决coordinator不具备高可用性的问题。看了这篇分析，你会发现前面我关于2PC的分析是正确的。
，看2PC如何与PAXOS结合实现replicated state machine，通过 分布式选举解决coordinator的高可用性问题，通过replicated state
machine解决participants的高可用性问题。
分析对工程实践的指导
还是从那里讨论得到的：如果在分布式系统中，协议包括这种逻辑：A发起一个请求给所有人；等待所有人响应之后A继续进行处理。这样的东西一看就太复杂，不靠谱，因为这相当于实现了一个2PC，有些偏复杂，如果必须这么实现， 那么同学，你一定要按照2PC的理解方式去理解，去分析这个问题。
其实在分布式系统中，需要使用2pc思想指导设计的地方很多。一个很简单的例子，中心节点控制从一个数据节点拷贝一个分片到另外一个数据节点就需要这样的协议。以gfs增加block副本为例，当gfs metaserver的后台线程发现某个block的副本数量小于配置的阈&#20540;的时候，就会发起副本拷贝的任务：将block从一个chunkserver拷贝到另外一个chunkserver。这样的场景会产生如下问题：
metaserver如何监控拷贝进度？ 如果拷贝的源失败如何处理？ 如果拷贝的目的失败如何处理？
一个比较挫的设计方法：meta不断的去询问源或者目的，任务是否结束，根据复制的结果决定如何进行后续的操作。想一想，这个实现起来有 多困难，metaserver上有上十万的block，如何处理？
看看伟大的google是如何处理的，metaserver为所有复制任务维护一个任务队列，任务队列中的任务有超时时间； 后台线程发现副本数量小于配置的阈&#20540;，首先查看任务队列中是否有任务正在进行该bock的复制操作，如果有任务 则不做任何事情；如果没有相应的任务，则发起任务。metaserver的工作到此为止。那么如何判断任务队列中的任务完成与否呢？这是chunkserver的事情，复制的目的会在复制任务完成后向metaserver汇报新复制的block，
metaserver在收到复制完成的汇报后会把相应的任务从任务队列中删除。这样，整个协议很简单，很清晰，不易出bug。 之前那种挫的设计，状态太难维护。在我们实际的工程实践中，一定要尽量少的使用一个进程去等待另外两个进程 完成某项任务的协议，这样的协议太难维护了。&
本文已收录于以下专栏：
相关文章推荐
二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。...
两阶段提交协议（two phase commit protocol，2PC）可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交...
2PC是指Oracle的两阶段提交协议（Two-Phase Commit protocol）。
2PC用于确保所有分布式事务能够同时提交（Commit）或者回滚（Rollback），以便使的数据库能...
分布式事务是指发生在多台数据库之间的事务，Oracle中通过dblink方式进行事务处理，分布式事务比单机事务要复杂的多。大部分的关系型数据库通过两阶段提交（2 Phase Commit 2PC）算法...
两阶段提交协议是很常见的解决分布式事务的方式，他可以保证分布式事务中，要么所有参与的进程都提交事务成功，要么都取消事务，这样做可以在分布式环境中保持ACID中A(原子性)。
在两阶段提交协议中，包含...
对于两阶段协议，只要学过《数据库基本原理》这本书的应该对这个名词比较熟悉，当时在本科的时候，学过这个协议，结果在后面却完全忘了这个协议，直到在后面《大数据存储》里面有一道关于两阶段协议的题后才引起了我...
两阶段提交协议（two phase commit protocol，2PC）可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交...
2PC：可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的一致性算法。该算...
2PC，保障分布式事务原子性，既在所有站点上要么全部commit，要么全部abort，回滚；
2PC：实现分布式事务的关键就是两阶段提交协议。在此协议中，一个或多个资源管理器的活动均由一个称为事务协调...
本文原文连接: http://blog.csdn.net/bluishglc/article/details/7612811 ,转载请注明出处！
XA是由X/Open组织提出的分布式...
他的最新文章
讲师：吴岸城
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)博客访问： 1687604
博文数量： 446
博客积分： 7040
博客等级： 少将
技术积分： 4132
注册时间：
范德萨发而为
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 服务器与存储
部分翻译自
两阶段提交协议是在事务处理、数据库，以及计算机网络中使用的一种原子提交协议(atomic commitment)。它是一个分布式算法，协调在整个分布式原子事务中的参与者的行为(commit或者roll back)。这个协议在一些系统错误发生时仍然能够成功，((两阶段提交协议))但并不能保证对所有错误都能进行容错。为了能做错误恢复，协议的所有参与者都需要使用日志对协议状态进行记录。
前提条件& (两阶段提交协议)。
两阶段提交协议在下面的条件下执行：其中一个节点被设置为coordinator，其他节点设置为cohorts。协议假定在每个节点上都有一个使用write-ahead log的稳定数据存储节点。没有节点崩溃，write-log的日志保证不丢失(这两点假设太过了吧，节点崩溃之后可以做恢复吧？)。并且任意两个节点都可以互相通信(这个条件过于严格)。
提交请求阶段(或者叫做投票阶段)
&& &1.coordinator发送一个query to commit消息给所有的cohorts，等待直到收到所有cohorts的回复。
&& &2.cohorts在本地节点执行事务(之后coordinator会要求提交这个事务)，写本地的redo和undo日志
&& &3.每一个cohorts，如果执行成功，回复一个agreement消息(假如cohorts同意执行commit)；如果执行失败，回复一个abort消息。(两阶段提交协议)。
提交阶段(或者叫完成阶段)成功
如果coordinator接收到所有cohorts发送回来的agreement消息：
&& &1.coordinator发送一个commit消息给所有的cohorts
&& &2.每一个cohorts完成commit操作，(两阶段提交协议)释放所有事务处理过程中使用的锁资源
&& &3.每一个cohorts回复一个acknowledgment给coordinator
&& &4.coordinator在收到所有acknowledgment消息之后完成整个操作
如果任何一个cohorts在提交请求阶段回复abort消息给coordinator:
&& &1.coordinator回复一个rollback消息给所有的cohorts
&& &2.每一个cohorts执行本地事务的undo操作(根据undo日志记录)，并且释放事务执行过程中使用的资源和锁
&& &3.每一个cohorts给coordinator回复acknowledgement消息(两阶段提交协议)。
&& &4.coordinator在接收到所有的cohorts的acknowledgement消息之后执行事务undo操作
两阶段提交协议最大的缺点是：它是一个阻塞协议。当一个节点在等待回复消息时进入阻塞状态。其他需要这些资源的处理事务需要等待。如果coordinator挂掉，cohorts将永远不能结束它们的事务，如下面的情况所述：
如果一个cohort发送agreement消息给coordinator，它将进入阻塞状态直到收到回复的commit或者rollback 消息。如果这个时候coordinator挂掉，并且不再恢复，这个cohort将一直阻塞(为什么这里不能使用等待超时的机制来abort掉这个事务呢？个人理解，如果一个cohort独自决定将这个未完成事务abort掉，可能导致全局的数据不一致，因为不知道其他节点是否执行了abort操作)，(两阶段提交协议)除非它可以从其他cohort那里获得全局的commit/abort消息
当coordinator发送query to commit消息之后，它将阻塞直到收到所有cohorts的回复消息。如果这个时候，一个cohort挂掉，并且不再能恢复，coordinator用下面的方法来解除阻塞：因为coordinator是唯一一个决定提交或回滚的节点，(两阶段提交协议)所以可以使用超时机制来解决阻塞问题。如果coordinator在一段时间之内没有收到来自cohort的消息，它将不再等待，直接向所有的cohort发送abort消息。这是这个协议的又一个缺点：它倾向于abort这样的case，而不是完成这个case
两阶段提交中的故障处理：
首先说明(源自《数据库与事务处理》一书，为什么要这样设计？)
coordinator对事务开始和提交消息进行强制写入到非易失性介质中；
cohorts对准备消息和提交消息进行强制写入到非易失性介质中。。(两阶段提交协议)。
写入非易失性介质中的日志用于在节点崩溃之后能查找到崩溃时节点在事务中的状态。
如果对以上日志操作的写入，首先在缓存中写入，(两阶段提交协议)然后批量写入非易失性介质，那么情况会更加复杂，因为如果节点崩溃，会丢失当前的事务状态。
1.coordinator在等待投票消息时超时。coordinator发送abort消息给所有cohorts，终止事务
2.coordinator在等待提交完毕消息时超时。coordinator与cohort联系，确认cohort的提交完毕消息。如果coordinator无法联系上这个cohort，无法知道它是否正常提交，则放弃，因为已提交完成的cohorts无法做回滚操作了。
这时该怎么处理呢？因为其他cohorts已经完成提交，不能对事务进行回滚。可以这样考虑：coordinator在多次重试都无法得到完成提交的消息之后可以放弃，待cohort重新恢复自行处理，这时可能有两种情况：a.cohort在本地日志中发现已完成本地提交，所以可能由于网络故障导致提交完成消息没有到达coordinator，所以直接忽略；b.cohort发现在本地日志中发现尚未提交成功，因为到达这里，可以肯定本地已做好提交准备，但是不知道coordinator是决定提交，所以向coordinator询问，按coordinator的回复来进行提交或回滚)。(两阶段提交协议)。
3.coordinator在发送准备到发送提交消息的这段时间中崩溃。coordinator恢复重启后，发现并未做提交操作，保险操作(因为coordinator不知道它是否发现欧诺个准备消息，或其他cohorts是否做好提交准备)，直接发送abort消息给所有cohorts，终止事务
4.coordinator在发送提交消息之后崩溃。这种情况下，不能保证所有cohorts都已收到了提交消息，所以给所有的cohorts发送commit消息，保证事务的正常提交
5.cohorts在等待commit或abort消息的时候崩溃。重启之后发现日志中有事务准备消息，尝试向coordinator询问事务状态，根据回复做提交或异常终止。如果无法联系上coordinator，则向其他cohorts询问事务状态，如果有某一个节点已经做了提交或异常终止(说明coordinator已发送了相关消息)，则做同样的操作
6.cohort在收到commit消息，完成提交之后出现崩溃。这时可能coordinator在等待该cohort的提交完成回应消息，所以cohort主动联系coordinator告知事务状态。
个人总结：
两阶段提交协议其实是将集中式的提交协议(常用单机数据库的事务提交方法)的工程拆开成两个阶段，从commit这个步骤将其拆开，在commit之前，(两阶段提交协议)发送消息给coordinator，等待coordinator确认收集到所有的可提交消息之后，再执行提交操作。当然最后还需要cohort回复ack消息给coordinator确认本地事务提交已成功
1.在提交阶段,cohorts收到commit消息之后，所有cohorts都应该执行commit操作，这时如果有某个cohorts执行commit失败，那么coordinator将不会收到这个corhort的ack消息，这是coordinator将如何处理，因为其他正常提交的cohorts已经在本地完成了commit操作，本地数据还能作rollback操作吗?如果不能，会出现数据不一致的情况。(两阶段提交协议)。
其他资源：
, an alternative fault-tolerant commit algorithm based on the Paxos algorithm for n-process consensus.
阅读(8718) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。}