《《两阶段提交协议》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《两阶段提交协议》PPT课件.ppt（51页珍藏版）》请在三一办公上搜索。
1、4.3 两阶段提交协议4.4分布式数据库中的数据更新4.5分布式事务增强数据库一致性4.6本章小结,4.3 两阶段提交协议,431 两阶段提交协议的基本思想和内容432 两阶段提交协议的通信结构433 两阶段提交协议与故障恢复,431 两阶段提交协议的基本思想和内容,两阶段提交协议(Two-phase Commitment Protocal2PC)既简单又精巧，它把本地原子性提交行为的效果扩展到分布式事务，保证了分布式事务提交的原子性，并在不损坏日志的情况下实现快速故障恢复，提高分布式数据库系统的可靠性。在两阶段提交协议中，把分布式事务的某一个代理(根代理)指定为协调者(coodinator)
2、，所有其他代理称为参与者(Participants)。只有协调者才有掌握提交或撤销事务的决定权，而其他参与者各自负责在其本地数据库中执行写操作，并向协调者提出撤销或提交子事务的意向。一般一个站点惟一地对应一个子事务，如果某一参与者与协调者在同一站点，虽然它们不需要使用网络来通信，但在处理时仍逻辑地认为它与协调者不在同一站点。,图4.14为协调者和参与者关系的示意图,返回,2PC保证分布式事务提交的原子性，这是通过坚持在分布式事务的结果生效以前，所有参与执行分布式事务的站点都同意提交而做到这一点.,图4.15描述了协调者和一个参与者之间的两阶段提交协议的活动。图中椭圆形表示状态，虚线表示协调者和
3、参与者之间的消息。虚线上的标号说明了消息的种类.2Pc把事务的提交过程分为两个阶段：第一阶段是表决阶段，目的是形成一个共同的决定。第二阶段是执行阶段，目的是实现这个决定.根据协调者的指令参与者或者提交事务，或者撤销事务，并给协调者发送确认消息。此时，协调者在日志中写入一条事务结束记录并终止事务。,请注意协调者做出关于事务的全局终止决定的方式。该决定受两条规则支配,这两条规则合称为全局提交规则：只要有一个参与者撤销事务，协调者就必须做出全局撤销决定。只有所有参与者都同意提交事务，协调者才能做出全局提交决定。,从图4.14中可以看出以下一些关于两阶段提交协议的一些重要之处。首先，两阶段提交协议允许
4、参与者可以单方面撤销事务；其次，一旦参与者确定了提交或撤销提议它就不能再更改它的提议;第三，当参与者处于就绪状态时，根据协调者发出的消息的种类，参与者可以转换为提交状态或撤销状态；第四，协调者依据全局提交规则做出全局终止决定;最后，注意协调者和参与者可能进入某些相互等待对方发送消息的状态。为了确保它们能够从这些状态中退出并终止，要使用定时器。每个进程进入一个状态时都要设置定时器。如果所期待的消息在定时器超时之前没有到来，定时器向进程报警，进程于是调用它自己的超时协议。,432 两阶段提交协议的通信结构,集中式2Pc通信结构分层式2Pc通信结构线性2Pc的通信结构 分布式2PC的通信结构,集中式
5、2Pc通信结构,有一些不同的通信范例可以在实现两阶段提交协议时使用。上面讨论的并在图4.14中指述的范例称为集中式两阶段提交协议，这是因为通信只发生在协调者和参与者之间，参与者之间不交换消息。图4.16中作了更明确的描述.,分层式2Pc通信结构,如图协调者是在树根的DTM代理者。在协调者和参与者之间的通信不用直接广播的方法进行,而是使报文在树中上下传播。每个DTM代理者是通信树的一个内部节点，它从下层节点处收集报文或向它们广播报文。,线性2Pc的通信结构,另一种可供选择的范例是线性两阶段提交协议(也称为嵌套两阶段提交协议)。在该结构中，参与者之间可以相互通信。为了通信，系统中的站点之间要进行排
6、序。假定参与事务执行的站点之间的顺序是1到N，协调者就是序列中的第一个。实现两阶段提交协议时，在第一阶段使用了向前通信方式，从协调者(No1)到N；在第二阶段使用了向后通信方式，即从N到协调者。于是，线性两阶段提交协议按如下方式操作.,图4.18 线性2PC的通信结构 它产生较少的消息但是不提供任何并行。因此，它增加了相应时间，降低了性能。然而，它可能适合于没有广播能力的网络。,分布式2PC的通信结构,实现两阶段提交协议的另一种流行的通信结构允许所有的参与者在第一阶段相互通信，以便它们能独立做出关于特定事务的终止决定。这称为分布式两阶段提交协议，它不需要第二阶段，因为参与者可以自己做出决定。其
7、操作过程如下：,图4.19 分布式2PC的通信结构,另外在线性两阶段提交协议中，一个参与者必须知道在线序关系中其后继参与者的标识；在分布式两阶段提交协议中，一个参与者必须知道所有参与者的标识。在协调者发给参与者的准备消息中附加一张参与者列表可以解决该问题，因为协调者清楚地知道谁是参与者。这样的问题不会出现在集中式两阶段提交协议中。算法4.1和算法4.2分别描述了集中式两阶段提交协议通信结构中协调者和参与者的执行过程.这些算法说明了协调者和参与者之间相互通信的过程。,算法4.1 2PC-Coordinator算法4.2 2PC-Parcipant,433 两阶段提交协议与故障恢复,由两阶段提交协
8、议的工作原理可见，之所以能够在不丢失运行记录信息的情况下.从所有故障中迅速恢复，就是因为在执行过程中维护了事务日志，记录了执行恢复所需要的信息。现在来分析当发生不同类型故障时，2Pc的行为。站点故障 丢失报文 网络分割,站点故障,(1)一参与者在把就绪记录写入运行记录以前出现故障。在这种情况下，协调者超时机制满期，它将采取撤消的决定。所有的参与者都撤销它们的子事务。当发生该故障的参与者恢复时，重启动过程简单地撤销该事务即可不需要过问其他站点的情况。,(2)一参与者在把就绪记录写入运行记录以后发生故障。在这种情况下，其他参与者的站点终止该事务(提交或撤消)。当故障站点恢复时，重启动过程不得不询问
9、协调者或别的某个参与者关于该事务的结果(提交或撤消)，然后执行相应的动作(提交或撤消)。这种情况下需要访问远程的恢复信息.,(3)协调者在把预备记录写入运行记录以后，而在写入global-commit或global-abort记录以前发生故障。这种情况下所有已经回答READY的参与者必须等待协调者恢复。协调者的重启动过程从头开始恢复提交协议，从预备记录(在运行记录中)读取参与者的标识，再次把PREPARE(预备)报发送给它们。每个就绪的参与者必须要识别出该新的PREPARE报文是前一个的重复报文。,(4)协调者在远行记录中写入global-commit或global-abort记录以后而在写入
10、完成记录以前发生故障。这种情况下，协调者在重启动时必须再次给所有参与者发送其决定,未曾收到此命令的所有参与者不得不等待到协调者恢复为止。和以前一样，参与者不应因收到该命令报文两次而受到影响。(5)协调者在运行记录中写入完成以后发生故障。这种情况下,该事物已经结束,在重启动时不需任何动作。,丢失报文,(1)来自一个参与者的回答报文(READY或ABORT)被丢失。在这种情况下，协调者的超时满期，整个事务被撤销。要注意，只由协调者来发现这种故障，而从协调者的观点来看，它完全好像是一参与者的故障。但是从参与者的观点来看情况就不同了，该参与者并不认为自己有故障，因而不会执行重启动过程。(2)丢失一个P
11、REPARE报文。这种情况下该参与者仍停在等待状态。因为协调者并没有收到回答，所以其全局结果和前一种情况相同。,(3)丢失一命令报文(commit或abort)。采用图4.15的协议时，该参与者对此命令处于不肯定状态。在参与者中引入超时机制就可简单地消除这个问题；从回答起在超时后仍末收到任何报文的话，就发送请求再发送该命令。(4)丢失一个AcK报文。协调者对参与者有无收到该报文处于不肯定状态。可以在协调者中引入超时机制就可简单地消除这个问题；如果从发出命令起到超时后仍未受到任何AcK报文，协调者就再次发送该命令。在参与者站点处理这种情况的最好办法是再次发送AcK报文，即使该子事务在那期间已经完
12、成并不再活动也要重发。,网络分割 这里假设发生了简单的网络分割情况，即把站点分成为两个组；包含协调者的组叫做协调者组，而另一组叫参与者组。从协调者的观点来看，这种分割等效于一组参与者的故障情况，与上述第1(1)和1(2)点相似：协调者作出决定然后把命令发送给协调者一组中的所有参与者，因而这些站点能够正确地结束事务。如从参与者组的成员观点来看，这种分割等效于协调者故障，情况与上述第1(3)和1(4)点相似。要注意，对于涉及处理分布式事务的站点来说，其恢复过程要比集中式数据库复杂。在集中式数据库中，只合两种可能；事务要么提交，要么不提交，所以恢复机构执行相应的重做或撤销动作。在分布式数据库中，还可
13、能有其他情况；,(1)一个参与者就绪(情况1(2)。(2)协调者已启动第1阶段(情况1(3)。(3)协调者已启动第2阶段(情况1(4)。这些情况分布式数据库管理系统中的恢复机制都能识别，并根据识别的情况作相应的处理。,4.4分布式数据库中的数据更新,4.4.1 多站点的数据更新4.4.2 主文本更新法4.4.3 快照方法,4.4.1 多站点的数据更新,1 多站点数据更新的原则和方法 在分布式数据库系统中，为了获得高查询速度和高可靠性，以增加数据复制的代价来减少数据通信的代价并增强系统的可靠性。但由于数据复制在多个站点上，一旦要对有多个副本的数据进行更新时，为保证数据库的一致性，就必须对这些数据
14、的所有复制版本同时做同样的更新。,先考虑单用户情况。如果站点A上有一个事务T对数据x进行更新，若x在站点Bl，B2，Bn和C1，C2，C m上都有它的副本.而现在站点Bl，B2，Bn与站点A连通，但站点Cl，C2，Cm与站点A现在不连通，如图所示。,此时现在只能对连通站点Bl，B2，Bn上的x副本进行更新，而对不连通站点Cl，C2，Cm上的x副本，只能当站点连通时才能进行更新。为此，要记录对x所做的更新内容和应更新而未被连通的站点，一旦其中的站点连通，就立刻进行相应的更新。2 多站点数据更新存在的问题 1)多站点各副本同时更新的不现实性:因为每一个站点某一时刻与站点A连通的概率为P(P=1),
15、同时更新要求每一个有X副本的站点与A都连通,其概率是:P*n,当n趋于无穷大时,P*n趋于0.,2)当对未连通的站点上的副本要求更新的事务增多时,就不能保证在该站点A连通时,进行的更新是正确的.因为更新的顺序就是连通的顺序,而通常情况下,更新的顺序不会是连通的顺序,除非更新是相互独立的.,主文本更新法,基本思想 对每一个有多副本的数据(关系或片段)，指定其中一个副本为主文本，其他为辅文本。一般，不同的数据其主文本在不同的站点上，对一个数据的更新，只要对它的主文本进行更新，就认为完成了对该数据的更新。然后由拥有主文本的站点负责把对主文本所做的更新，及时发送给各辅文本站点进行更新。各辅文本的更新可
16、并行进行。如有与主文本尚未连通的辅文本，在连通后按记录的更新顺序逐一进行更新。,例如,站点A拥有x的主文本，其他站点拥有x的辅文本站点B1现在未连通TI和T2分别为站点A和站点B5发出的修更新x的事务，且TI先于T2。站点A上的事务管理程序按TI，T2顺序对在其站点上的x主文本进行修改，并依次记录更新内容和尚 未连通的站点B3。并及时向各连通站点发出更新通知和更新内容，由于站点BI，B2，B4，B5是连通站点，收到通知按T1，T2要求进行修改。因B3尚未连通，待其连通时，由站点A将记录的要求更新的内容和修更新顺序通知站点B2上的事务管理器执行更新。,2存在问题(1)更新传播要在短时间内完成，否
17、则将会得到“过时”数据。(2)如果主文本站点不可用时，会引起其他辅文本站点也不可用。3 改进方法 采用“移动主文本法”.移动主文本法：若初次修改在某个辅文本站点上进行，然后再把更新引向该数据的主站点。如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新.待原主文本站点连通后,系统将自动把它改为辅文本,并按记录要求执行更新.,若初次修改就在主文本上进行，而主文本站点现在与网络未连通，即作本地修改，则这次修改操作失败，事务被撤消。因为主文本站点与网络尚未连通，也就无法传播更新。移动主文本法也存在一个问题，当网络分割成多个部分时，更新处理会不一致。例如网络被分割成w1和w2，
18、对数据x进行更新。若w1中将x修改为R，w2中将x修改为S，当网络连通时，将使用R还是使用S来恢复x呢?,4.4.3 快照方法,1定义 快照类似于视图，但快照的数据是实际存放在数据库中，是对其中数据暂时凝固，且对满足条件的数据的定期复制，并用新的一次复制替代原来的复制。它可以使用命令定义,既可定期刷新，也可当必要时强制刷新。下面是一个创建快照的SQL语句,2快照方法的优缺点,采用快照方法可完成复杂的查询，而又不阻止更新.为了与主文本保持同步,当主文本被更新时,需要刷新快照.虽然快照中的数据不是“全新”的，但在实际应用中，很少需要真正“全新”的数据。因此，快照方法既避免了某些并发控制的开销(见第
19、五章)，而又便于复杂查询的完成，是提高系统可用性的有 效方法.但是快照是一个只读关系.对查询操作可使用快照,也可使用主文本,而对更新操作还是应在主文本上完成.,分布式数据库中存在的信息是对客观世界的反映客观世界要保持合理的状态存在，总要有一定规则的，这种规则反映到分布式数据库中，就是分布式一数据库的数据要满足一定约束条件，这种约束条件称为一致性约束它分为两类：业务规则的一致性约束：它是客观世界本身存在的一定规则；冗余数据的一致性约束：分布式数据库管理的需要，如为了提高系统效率和可靠性采用冗余数据,45 分布式数据库中的数据更新,4.5.1 业务规则的一致性,业务规则可以被分为 有效性约束和数据
20、依赖约束.有效性约束的业务规则主要是 域约束 数据依赖约束的业务规则是指实体完整性约束和引用完整性约束.,如果一个数据库中的数据满足全部业务规则,就是说它是一致的数据库,也就是说,数据库中的数据值对于预先确定的业务规则是一致的。数据库管理员和用户对分布式数据库系统必须支持的业务规则都应有确切的了解。例如：考虑在银行业务中的一些事务的例子：银行的现金存取处理是一个事务：银行的客户从他们在银行的帐户中取走现金。注意：如果客户试图从他的帐户中取出多于存入的累计余额，事务将对数据库所做的任何更新进行回退.那么这个事务强制实施下述业务规则，即一个帐户的存款余额必须大于等于0。,所有业务规则，无论在用户编
21、写的事务中或由DBMS的事务优化器产生的事务中，都必须强制实行。多数商用分布式DBMS的事务优化，在产生分布式事务时只加少数几类规则。为了补救这种不足，需要：1.程序员必须编写加进业务规则的分布式事务 2.必须定期扫描，检测不一致的数据，予以消除 3.找出那些没有实施的，不能由事务优化器加上的强行业务规则。,452 冗余数据的一致性 1冗余数据必须保持一致 在分布式数据库设计时，数据库管理员把关系的片段分配到多个成员站点是出于以下两个主要的理由：提高系统的可靠性和可用性。如果用户由于某种原因不能访问某个成员数据库那么他们可以访问另一个成员数据库上的相同片段；提高“读”事务的本地性，以降低通信成
22、本。特别是对读出比写入频率高得多的那些应用。,考虑下面两个事务：,假定包含的片段的副本驻留在北京和上海两个成员数据库中。同时假定一个请求(事务)是在北京发出，而另一个请求在上海发出。这两个请求在两个成员中可能以不同的顺序执行。设x的初始值为50。在两个DBMs按不问顺序执行这两个请求的结果如表所示。,x在这两个成员数据库中的值是有分歧的。数据库管理员所能做的，或者允许成员数据库中的冗余数据出现暂时的分歧而后使它们归于一致；或者保证事务在包含冗余数据的站点以相同的顺序执行事务，从而防止包含冗余数据的成员数据库产生分歧。,2异步复制器 试图使分布式数据库中冗余数据绝对保持一致似乎是不可能的，一般允
23、许对冗余数据的修改有暂时的不一致。为了更好地管理冗余数据(多副本的复制数据)最近数据库厂家推出了几种新的产品，这些产品称为数据复制器。采用一种级联策略对复制片段或复制表中的数据值进行同步。复制器强制用户修改数据的主副本，然后把修改迁移到其余的副本上。用户可以从辅助副本检索数据，但是禁让用户修改辅助副本。,复制数据使用户可以把一个数据库分拆开来，把信息存放在更接近于使用信息最多的用户。不同的数据复制产品的差别有如下两个方面：在主副本上何时获取数据 何时把主副本获取的数据用到辅助副本。主副本获取数据，在其传输到不同成员数据库中的辅助副本之前，先复制到一个获取文件或队列中。获取有关数据更新信息可采用
24、如下方法：数据驱动 计时器驱动 应用程序驱动,把获取的有关数据更新信息用于辅助副本也可以采用如下方法：数据驱动 计时器驱动 应用程序驱动,4.6小结,分布式事务管理的主要目标是保证所有事务具有原子性、一致性(可串行性)、隔离性和持久性。为了达到这个目标,分布式事务管理程序在本地事务管理程序保证本地事务的ACID(或ASID)的基础上，利用两阶段提交协议来保证分布式事务的ACID，从而获得分布式数据库系统的可靠性。两阶段提交协议确保同一事务的所有子事务要么全部提交，要么全部撤消，不管有无发生故障。而且两阶段提交协议在不丢失运行日志信息的情况 下，可从任何故障恢复。两阶段提交协议的通信结构可以是集中式、分层式、线性或分布 式的，它们各有特色。,分布式事务增强了数据库的一致性，包括业务规则一致性和冗余数据的一致性。在分布式数据库系统中数据的冗余是提高系统可靠性和查询处理效率的基础，对多副本数据的更新，通常采用主文本或移动主文本更新方法。快照方法不影响数据更新而又利于处理复杂查询，是提高系统可用性的有效方法。,
