搜索
4.3两阶段提交协议4.4分布式数据库中的数据更新4.5分布式事务增强数据库一致性4.6本章小结4.3两阶段提交协议4．3．1两阶段提交协议的基本思想和内容4．3．2两阶段提交协议的通信结构4．3．3两阶段提交协议与故障恢复4．3．1两阶段提交协议的基本思想和内容两阶段提交协议(Two-phaseCommitmentProtocal—2PC)既简单又精巧，它把本地原子性提交行为的效果扩展到分布式事务，保证了分布式事务提交的原子性，并在不损坏日志的情况下．实现快速故障恢复，提高分布式数据库系统的可靠性。在两阶段提交协议中，把分布式事务的某一个代理(根代理)指定为协调者(coodinator)，所有其他代理称为参与者(Participants)。只有协调者才有掌握提交或撤销事务的决定权，而其他参与者各自负责在其本地数据库中执行写操作，并向协调者提出撤销或提交子事务的意向。一般一个站点惟一地对应一个子事务，如果某一参与者与协调者在同一站点，虽然它们不需要使用网络来通信，但在处理时仍逻辑地认为它与协调者不在同一站点。图4.14为协调者和参与者关系的示意图2PC保证分布式事务提交的原子性，这是通过坚持在分布式事务的结果生效以前，所有参与执行分布式事务的站点都同意提交而做到这一点.图4.15描述了协调者和一个参与者之间的两阶段提交协议的活动。图中椭圆形表示状态，虚线表示协调者和参与者之间的消息。虚线上的标号说明了消息的种类.2Pc把事务的提交过程分为两个阶段：第一阶段是表决阶段，目的是形成一个共同的决定。第二阶段是执行阶段，目的是实现这个决定.根据协调者的指令．参与者或者提交事务，或者撤销事务，并给协调者发送确认消息。此时，协调者在日志中写入一条事务结束记录并终止事务。请注意协调者做出关于事务的全局终止决定的方式。该决定受两条规则支配,这两条规则合称为全局提交规则：只要有一个参与者撤销事务，协调者就必须做出全局撤销决定。只有所有参与者都同意提交事务，协调者才能做出全局提交决定。从图4.14中可以看出以下一些关于两阶段提交协议的一些重要之处。首先，两阶段提交协议允许参与者可以单方面撤销事务；其次，一旦参与者确定了提交或撤销提议．它就不能再更改它的提议;第三，当参与者处于就绪状态时，根据协调者发出的消息的种类，参与者可以转换为提交状态或撤销状态；第四，协调者依据全局提交规则做出全局终止决定;最后，注意协调者和参与者可能进入某些相互等待对方发送消息的状态。为了确保它们能够从这些状态中退出并终止，要使用定时器。每个进程进入一个状态时都要设置定时器。如果所期待的消息在定时器超时之前没有到来，定时器向进程报警，进程于是调用它自己的超时协议。4．3．2两阶段提交协议的通信结构集中式2Pc通信结构分层式2Pc通信结构线性2Pc的通信结构分布式2PC的通信结构集中式2Pc通信结构有一些不同的通信范例可以在实现两阶段提交协议时使用。上面讨论的并在图4.14中指述的范例称为集中式两阶段提交协议，这是因为通信只发生在协调者和参与者之间，参与者之间不交换消息。图4.16中作了更明确的描述.分层式2Pc通信结构如图协调者是在树根的DTM—代理者。在协调者和参与者之间的通信不用直接广播的方法进行,而是使报文在树中上下传播。每个DTM—代理者是通信树的一个内部节点，它从下层节点处收集报文或向它们广播报文。线性2Pc的通信结构另一种可供选择的范例是线性两阶段提交协议(也称为嵌套两阶段提交协议)。在该结构中，参与者之间可以相互通信。为了通信，系统中的站点之间要进行排序。假定参与事务执行的站点之间的顺序是1到N，协调者就是序列中的第一个。实现两阶段提交协议时，在第一阶段使用了向前通信方式，从协调者(No．1)到N；在第二阶段使用了向后通信方式，即从N到协调者。于是，线性两阶段提交协议按如下方式操作.图4.18线性2PC的通信结构它产生较少的消息．但是不提供任何并行。因此，它增加了相应时间，降低了性能。然而，它可能适合于没有广播能力的网络。分布式2PC的通信结构实现两阶段提交协议的另一种流行的通信结构允许所有的参与者在第一阶段相互通信，以便它们能独立做出关于特定事务的终止决定。这称为分布式两阶段提交协议，它不需要第二阶段，因为参与者可以自己做出决定。其操作过程如下：图4.19分布式2PC的通信结构另外．在线性两阶段提交协议中，一个参与者必须知道在线序关系中其后继参与者的标识；在分布式两阶段提交协议中，一个参与者必须知道所有参与者的标识。在协调者发给参与者的准备消息中附加一张参与者列表可以解决该问题，因为协调者清楚地知道谁是参与者。这样的问题不会出现在集中式两阶段提交协议中。算法4.1和算法4.2分别描述了集中式两阶段提交协议通信结构中．协调者和参与者的执行过程.这些算法说明了协调者和参与者之间相互通信的过程。算法4.12PC-Coordinator算法4.22PC-Parcipant4．3．3两阶段提交协议与故障恢复由两阶段提交协议的工作原理可见，之所以能够在不丢失运行记录信息的情况下.从所有故障中迅速恢复，就是因为在执行过程中维护了事务日志，记录了执行恢复所需要的信息。现在来分析当发生不同类型故障时，2Pc的行为。站点故障丢失报文网络分割站点故障(1)一参与者在把就绪记录写入运行记录以前出现故障。在这种情况下，协调者超时机制满期，它将采取撤消的决定。所有的参与者都撤销它们的子事务。当发生该故障的参与者恢复时，重启动过程简单地撤销该事务即可．不需要过问其他站点的情况。(2)一参与者在把就绪记录写入运行记录以后发生故障。在这种情况下，其他参与者的站点终止该事务(提交或撤消)。当故障站点恢复时，重启动过程不得不询问协调者或别的某个参与者关于该事务的结果(提交或撤消)，然后执行相应的动作(提交或撤消)。这种情况下需要访问远程的恢复信息.(3)协调者在把预备记录写入运行记录以后，而在写入global-commit或global-abort记录以前发生故障。这种情况下所有已经回答READY的参与者必须等待协调者恢复。协调者的重启动过程从头开始恢复提交协议，从预备记录(在运行记录中)读取参与者的标识，再次把PREPARE(预备)报发送给它们。每个就绪的参与者必须要识别出该新的PREPARE报文是前一个的重复报文。(4)协调者在远行记录中写入global-commit或global-abort记录以后而在写入完成记录以前发生故障。这种情况下，协调者在重启动时必须再次给所有参与者发送其决定,未曾收到此命令的所有参与者不得不等待到协调者恢复为止。和以前一样，参与者不应因收到该命令报文两次而受到影响。(5)协调者在运行记录中写入完成以后发生故障。这种情况下,该事物已经结束,在重启动时不需任何动作。丢失报文(1)来自一个参与者的回答报文(READY或ABORT)被丢失。在这种情况下，协调者的超时满期，整个事务被撤销。要注意，只由协调者来发现这种故障，而从协调者的观点来看，它完全好像是一参与者的故障。但是．从参与者的观点来看情况就不同了，该参与者并不认为自己有故障，因而不会执行重启动过程。(2)丢失一个PREPARE报文。这种情况下该参与者仍停在等待状态。因为协调者并没有收到回答，所以其全局结果和前一种情况相同。(3)丢失一命令报文(commit或abort)。采用图4.15的协议时，该参与者对此命令处于不肯定状态。在参与者中引入超时机制就可简单地消除这个问题；从回答起在超时后仍末收到任何报文的话，就发送—请求再发送该命令。(4)丢失一个AcK报文。协调者对参与者有无收到该报文处于不肯定状态。可以在协调者中引入超时机制就可简单地消除这个问题；如果从发出命令起到超时后仍未受到任何AcK报文，协调者就再次发送该命令。在参与者站点处理这种情况的最好办法是再次发送AcK报文，即使该子事务在那期间已经完成并不再活动也要重发。网络分割这里假设发生了简单的网络分割情况，即把站点分成为两个组；包含协调者的组叫做协调者组，而另一组叫参与者组。从协调者的观点来看，这种分割等效于一组参与者的故障情况，与上述第1(1)和1(2)点相似：协调者作出决定然后把命令发送给协调者一组中的所有参与者，因而这些站点能够正确地结束事务。如从参与者组的成员观点来看，这种分割等效于协调者故障，情况与上述第1(3)和1(4)点相似。要注意，对于涉及处理分布式事务的站点来说，其恢复过程要比集中式数据库复杂。在集中式数据库中，只合两种可能；事务要么提交，要么不提交，所以恢复机构执行相应的重做或撤销动作。在分布式数据库中，还可能有其他情况；(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．多站点数据更新的原则和方法在分布式数据库系统中，为了获得高查询速度和高可靠性，以增加数据复制的代价来减少数据通信的代价．并增强系统的可靠性。但由于数据复制在多个站点上，一旦要对有多个副本的数据进行更新时，为保证数据库的一致性，就必须对这些数据的所有复制版本同时做同样的更新。先考虑单用户情况。如果站点A上有一个事务T对数据x进行更新，若x在站点Bl，B2，…，Bn和C1，C2，…，Cm上都有它的副本.而现在站点Bl，B2，…，Bn与站点A连通，但站点Cl，C2，…，Cm与站点A现在不连通，如图所示。此时．现在只能对连通站点Bl，B2，…，Bn上的x副本进行更新，而对不连通站点Cl，C2，…，Cm上的x副本，只能当站点连通时才能进行更新。为此，要记录对x所做的更新内容和应更新而未被连通的站点，一旦其中的站点连通，就立刻进行相应的更新。2．多站点数据更新存在的问题1)多站点各副本同时更新的不现实性:因为每一个站点某一时刻与站点A连通的概率为P(P=1),同时更新要求每一个有X副本的站点与A都连通,其概率是:P**n,当n趋于无穷大时,P**n趋于0.2)当对未连通的站点上的副本要求更新的事务增多时,就不能保证在该站点A连通时,进行的更新是正确的.因为更新的顺序就是连通的顺序,而通常情况下,更新的顺序不会是连通的顺序,除非更新是相互独立的.4.5.2主文本更新法1.基本思想对每一个有多副本的数据(关系或片段)，指定其中一个副本为主文本，其他为辅文本。一般，不同的数据其主文本在不同的站点上，对一个数据的更新，只要对它的主文本进行更新，就认为完成了对该数据的更新。然后由拥有主文本的站点负责把对主文本所做的更新，及时发送给各辅文本站点进行更新。各辅文本的更新可并行进行。如有与主文本尚未连通的辅文本，在连通后按记录的更新顺序逐一进行更新。例如站点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)更新传播要在短时间内完成，否则将会得到“过时”数据。(2)如果主文本站点不可用时，会引起其他辅文本站点也不可用。3．改进方法采用“移动主文本法”.移动主文本法：若初次修改在某个辅文本站点上进行，然后再把更新引向该数据的主站点。如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新.待原主文本站点连通后,系统将自动把它改为辅文本,并按记录要求执行更新.若初次修改就在主文本上进行，而主文本站点现在与网络未连通，即作