43 两阶段提交协议 44分布式事务增强数据库一致性 45分布 - Read

《43 两阶段提交协议 44分布式事务增强数据库一致性 45分布 - Read》由会员分享，可在线阅读，更多相关《43 两阶段提交协议 44分布式事务增强数据库一致性 45分布 - Read（51页珍藏版）》请在金锄头文库上搜索。

1、 4.3 两阶段提交协议4.4分布式数据库中的数据更新4.5分布式事务增强数据库一致性4.6本章小结4.3 两阶段提交协议n431 两阶段提交协议的基本思想和内 容n432 两阶段提交协议的通信结构n433 两阶段提交协议与故障恢复431 两阶段提交协议的基本思想和内容n 两阶段提交协议(Two-phase Commitment Protocal2PC)既简单又精巧，它把本地原子性提 交行为的效果扩展到分布式事务，保证了分布式事 务提交的原子性，并在不损坏日志的情况下实现 快速故障恢复，提高分布式数据库系统的可靠性。n 在两阶段提交协议中，把分布式事务的某一个 代理(根代理)指定为协调者(co

2、odinator)，所有其他 代理称为参与者(Participants)。只有协调者才有掌握 提交或撤销事务的决定权，而其他参与者各自负责 在其本地数据库中执行写操作，并向协调者提出撤 销或提交子事务的意向。一般一个站点惟一地对应 一个子事务，如果某一参与者与协调者在同一站点 ，虽然它们不需要使用网络来通信，但在处理时仍 逻辑地认为它与协调者不在同一站点。 图4.14为协调者和参与者关系的示意图 2PC保证分布式事务提交的原子性，这是通过坚 持在分布式事务的结果生效以前，所有参与执行分 布式事务的站点都同意提交而做到这一点.图4.15描述了协调者和一个参与者之间的两 阶段提交协议的活动 。图中

3、椭圆形表示状态 ，虚线表示协调者和参与者之间的消息。虚 线上的标号说明了消息的种类 .2Pc把事务的提交过程分为两个阶段：第一阶段是表决阶段，目的是形成一个共 同的决定。第二阶段是执行阶段，目的是实现这个决 定.根据协调者的指令参与者或者提交事务 ，或者撤销事务，并给协调者发送确认消息 。此时，协调者在日志中写入一条事务结束 记录并终止事务。请注意协调者做出关于事务的全局终止决定的 方式。该决定受两条规则支配,这两条规则合称 为全局提交规则： n 只要有一个参与者撤销事务，协调者就必须做 出全局撤销决定。n 只有所有参与者都同意提交事务，协调者才能 做出全局提交决定。 从图4.14中可以看出以

4、下一些关于两阶段提交协议的 一些重要之处。首先，两阶段提交协议允许参与者可 以单方面撤销事务；其次，一旦参与者确定了提交或 撤销提议它就不能再更改它的提议;第三，当参与者 处于就绪状态时，根据协调者发出的消息的种类，参 与者可以转换为提交状态或撤销状态；第四，协调者 依据全局提交规则做出全局终止决定;最后，注意协调 者和参与者可能进入某些相互等待对方发送消息的状 态。为了确保它们能够从这些状态中退出并终止，要 使用定时器。每个进程进入一个状态时都要设置定时 器。如果所期待的消息在定时器超时之前没有到来， 定时器向进程报警，进程于是调用它自己的超时协议 。432 两阶段提交协议的通信结 构n集中

5、式2Pc通信结构n分层式2Pc通信结构n线性2Pc的通信结构 n分布式2PC的通信结构集中式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分别描述了集中式两阶 段提交协议通信结构中协调者和参与者的 执行过程.这些算法说明了协调者和参与者

8、之间相互通信的过程。 n算法4.1 2PC-Coordinatorn算法4.2 2PC-Parcipant 433 两阶段提交协议与故障恢复由两阶段提交协议的工作原理可见，之所以 能够在不丢失运行记录信息的情况下.从所有故 障中迅速恢复，就是因为在执行过程中维护了 事务日志，记录了执行恢复所需要的信息。现在来分析当发生不同类型故障时，2Pc的行 为 。n 站点故障n 丢失报文 n 网络分割 站点故障 (1)一参与者在把就绪记录写入运行记录以前 出现故障。在这种情况下，协调者超时机制满 期，它将采取撤消的决定。所有的参与者都撤 销它们的子事务。当发生该故障的参与者恢复 时，重启动过程简单地撤销该

9、事务即可不需 要过问其他站点的情况。(2)一参与者在把就绪记录写入运行记录以后 发生故障。在这种情况下，其他参与者的站点终 止该事务(提交或撤消)。当故障站点恢复时，重 启动过程不得不询问协调者或别的某个参与者关 于该事务的结果(提交或撤消)，然后执行相应的 动作(提交或撤消)。这种情况下需要访问远程的 恢复信息.(3)协调者在把预备记录写入运行记录以后，而 在写入global-commit或global-abort记录以前发生故 障。这种情况下所有已经回答READY的参与者必 须等待协调者恢复。协调者的重启动过程从头开 始恢复提交协议，从预备记录(在运行记录中)读取 参与者的标识，再次把PR

10、EPARE(预备)报发送给 它们。每个就绪的参与者必须要识别出该新的 PREPARE报文是前一个的重复报文。(4)协调者在远行记录中写入global-commit或 global-abort记录以后而在写入完成记录以前发生 故障。这种情况下，协调者在重启动时必须再 次给所有参与者发送其决定,未曾收到此命令的 所有参与者不得不等待到协调者恢复为止。和 以前一样，参与者不应因收到该命令报文两次 而受到影响。(5)协调者在运行记录中写入完成以后发生故障 。这种情况下,该事物已经结束,在重启动时不需 任何动作。丢失报文 (1)来自一个参与者的回答报文(READY或 ABORT)被丢失。在这种情况下，协

11、调者的超时 满期，整个事务被撤销。要注意，只由协调者 来发现这种故障，而从协调者的观点来看，它 完全好像是一参与者的故障。但是从参与者 的观点来看情况就不同了，该参与者并不认为 自己有故障，因而不会执行重启动过程。(2)丢失一个PREPARE报文。这种情况下该参 与者仍停在等待状态。因为协调者并没有收到 回答，所以其全局结果和前一种情况相同。(3)丢失一命令报文(commit或abort)。采用图4.15 的协议时，该参与者对此命令处于不肯定状态 。在参与者中引入超时机制就可简单地消除这 个问题；从回答起在超时后仍末收到任何报文 的话，就发送请求再发送该命令。(4)丢失一个AcK报文。协调者对

12、参与者有无收 到该报文处于不肯定状态。可以在协调者中引 入超时机制就可简单地消除这个问题；如果从 发出命令起到超时后仍未受到任何AcK报文，协 调者就再次发送该命令。在参与者站点处理这 种情况的最好办法是再次发送AcK报文，即使该 子事务在那期间已经完成并不再活动也要重发 。网络分割 这里假设发生了简单的网络分割情况，即把 站点分成为两个组；包含协调者的组叫做协调 者组，而另一组叫参与者组。从协调者的观点 来看，这种分割等效于一组参与者的故障情况，与上述第1(1)和1(2)点相似：协调者作出决定 然后把命令发送给协调者一组中的所有参与者 ，因而这些站点能够正确地结束事务。如从参 与者组的成员观

13、点来看，这种分割等效于协调者故障，情况与上述第1(3)和1(4)点相似。要注意，对于涉及处理分布式事务的站点 来说，其恢复过程要比集中式数据库复杂。在 集中式数据库中，只合两种可能；事务要么提 交，要么不提交，所以恢复机构执行相应的重 做或撤销动作。在分布式数据库中，还可能有 其他情况；(1)一个参与者就绪(情况1(2)。(2)协调者已启动第1阶段(情况1(3)。 (3)协调者已启动第2阶段(情况1(4)。 这些情况分布式数据库管理系统中的 恢复机制都能识别，并根据识别的情况 作相应的处理。4.4分布式数据库中的数据更 新n4.4.1 多站点的数据更新n4.4.2 主文本更新法n4.4.3 快

14、照方法4.4.1 多站点的数据更新1 多站点数据更新的原则和方法在分布式数据库系统中，为了获得高查询速度 和高可靠性，以增加数据复制的代价来减少数据 通信的代价并增强系统的可靠性。但由于数据 复制在多个站点上，一旦要对有多个副本的数据 进行更新时，为保证数据库的一致性，就必须对 这些数据的所有复制版本同时做同样的更新。先考虑单用户情况。如果站点A上有一个事务T对 数据x进行更新，若x在站点Bl，B2，Bn和C1 ，C2，C m上都有它的副本.而现在站点Bl，B2 ，Bn与站点A连通，但站点Cl，C2，Cm 与站点A现在不连通，如图所示。此时现在只能对连通站点Bl，B2， Bn上的x副本进行更新

15、，而对不连通站点Cl，C2 ，Cm上的x副本，只能当站点连通时才能进 行更新。为此，要记录对x所做的更新内容和应更 新而未被连通的站点，一旦其中的站点连通，就 立刻进行相应的更新。 2 多站点数据更新存在的问题1) 多站点各副本同时更新的不现实性:因为每一 个站点某一时刻与站点A连通的概率为P(P=1),同时更新要求每一个有X副本的站点与A都 连通,其概率是:P*n,当n趋于无穷大时,P*n趋于0.2)当对未连通的站点上的副本要求更新的事务增 多时,就不能保证在该站点A连通时,进行的更新是 正确的.因为更新的顺序就是连通的顺序,而通常情况下 ,更新的顺序不会是连通的顺序,除非更新是相互独 立的

16、.4.5.2主文本更新法n基本思想对每一个有多副本的数据(关系或片段)，指 定其中一个副本为主文本，其他为辅文本。一 般，不同的数据其主文本在不同的站点上，对 一个数据的更新，只要对它的主文本进行更新 ，就认为完成了对该数据的更新。然后由拥有 主文本的站点负责把对主文本所做的更新，及 时发送给各辅文本站点进行更新。各辅文本的 更新可并行进行。如有与主文本尚未连通的辅 文本，在连通后按记录的更新顺序逐一进行更 新。例如 站点A拥有x的主文本，其他站点拥有x的辅 文本站点B1现在未连通TI和T2分别为站点A 和站点B5发出的修更新x的事务，且TI先于T2。 站点A上的事务管理程序按TI，T2顺序对在其站 点上的x主文本进行修改，并依次记录更新内容 和尚未连通的站点B3。并及时向各连通站点发出更新 通知和更新内容，由于站点BI，B2，B4， B5是 连通站点，收到通知按T1，T2要求进行修改。 因B3尚未连通，待其连通时，由站点A将记录的 要求