分布事务管理

10.3.5　分布事务管理

在分布式数据库系统中，一个数据库应用程序通常要被划分为一个或多个事务，由分布式事务管理系统对其进行管理和执行。对于分布事务而言，它除了具有原子性、持久性、一致性和隔离性四个性质外，由于分布数据库的分布特性，分布事务还具有自己独有的特性：在分布事务中，除需要考虑访问数据库的存取操作序列外，还必须考虑大量数据传送、通信原语和控制报文等，这些都是分布式事务所具有的性质。

一个分布事务中的操作要涉及多个结点上的数据。因此，分布事务的执行是由这些结点上的若干个子事务进程完成的。在分布事务中，有一个子事务是最先生成的，而其他子事务都是由这个子事务生成的，最先生成的这个事务负责监控分布事务的执行。各个子事务需要相互通信和配合，来完成分布事务的全局操作。

分布式事务管理的目的是维护分布事务的原子性、一致性、持久性和隔离性；获得最小的主存和CPU开销，降低控制报文的传输个数和加快分布事务的响应速度；获得最大限度的系统可靠性和可用性。

分布式事务管理最重要的两个方面是事务恢复和事务的并发控制。

一、事务故障恢复

数据库在运行过程中故障和错误总是难免的。不同的故障会造成数据库不同程度的损害，轻则事务不能正常运行，重则造成数据库数据不一致性。更严重的情况，会使部分或整个数据库遭到破坏。前面已经讨论了集中式数据库系统中的故障类型和恢复技术。在集中式数据库系统中利用日志文件（必要时加上后备副本）总可以把数据库恢复到某种正确的状态。

在分布式数据库系统中，各个场地除了可能发生如同集中式数据库的那些故障外，还会出现通信网络中通信信息丢失、长时间延迟、网络线路中断等事故。因此，情况比集中式数据库更复杂，相应的恢复过程也就更复杂些。

为了执行分布事务，通常在每个场地都有一个局部事务管理器，用来管理局部子事务的执行，保证子事务的完整性。同时这些局部管理器之间还必须相互协调，保证所有场地对它们所处理的子事务采取同样的策略：要么都提交，要么都回滚。为了保证这一策略，最常用的技术是两段提交协议（2Phase Commit Protocol，简称2PC）。

若在某结点上有一全局事务T，将其分解为在多个结点上执行的子事务。为了保持多结点协调一致，可以指定T所在结点上的管理器为协调者（Coordinator），在其他结点上的事务管理器称为参与者（Participants）。参与者向协调者提出提交或中止（Vote-Commit/Abort）事务的意向，协调者根据参与者提出的意向决定全局。

事务的提交或回滚（Commit/Roll Back）的两段提交协议如图10-12所示。

图10-12

（1）第一段是决定段——协调者根据参与者的意向决定提交或回滚事务，当且仅当所有的参与者均赞同提交时（Vote-Commit），协调者才能决定提交事务。具体执行过程是：协调者向所有参与者发出准备消息（Prepare），参与者根据本结点子事务执行结果是成功或失败回答同意提交（Vote-Commit）或中止（Abort）。出于事务恢复的需要，协调者在发出第一个准备消息时，需将Prepare作为运行记录（Log Record）写入磁盘，并启动超时机构（Timeout）。若参与者进入Vote-Commit状态，应将Vote-Commit记录和本结点提交该子事务所需信息写入运行记录，否则参与者应先将Abort记录写入运行记录，然后向协调者发出Abort消息。所以第一段的任务是确认各子事务是否已成功地执行。

（2）第二段是执行段——协调者向参与者发出Commit/Roll Back命令，各参与者根据协调者的命令决定执行提交或回滚。具体执行过程是：

协调者先将全局提交（Global-Comm it）记录成全局回滚（Global-Roll Back）记录写入运行记录，然后向所有参与者发送全局提交或回滚命令。

参与者根据接收到的命令内容将Commit或Abort记录写入运行记录并执行相应的操作。

该事务的两段提交处理完毕，协调者将事务完成（Complete）记录写入运行记录。

协调者在向某个参与者发出Prepare消息后，若隔一定时间（超时）仍收不到该参与者回答的Vote-Commit/Abort消息，可以重发Prepare消息，直到收到其回答的消息为止。同样，参与者在发出Vote-Commit/Abort消息后，若隔一定时间（超时），参与者仍未收到协调者发出的Commit/Roll Back命令，可以重发Vote-Commit/Abort消息，直到收到协调者的命令为止。由于协调者和参与者采用互相通信的交互方式，协议的执行是可靠的，从而保证全局事务执行的原子性。此外，2PC协议提供良好的故障恢复能力。在运行记录信息完整无缺的情况下，2PC协议可为结点故障（Node Failure）、消息丢失故障（Failure of Message Lose）和网络分区故障（Partition Failure）提供恢复故障支持。

通过对2PC协议执行过程的分析可以看出：参与者从发出消息Vote-Commit/Abort至收到协调者的命令这段时间，如果协调者失败，则事务可能被阻塞而迟迟不能结束，进入阻塞状态。为了改善2PC协议的性能，提出一些改进的2PC协议如三段提交协议等。

二、事务的并发控制

分布式并发控制是分布式事务管理系统的重要组成部分。最常用的分布式并发控制方法有两种：基于封锁的并发控制方法和基于时标的并发控制。

基于封锁的分布式并发控制基本思想和集中式数据库的思想是一致的，即对任何数据操作前要加锁，操作完成后，必须释放锁。

基于封锁的分布式并发控制的实现方法有很多，主要包括：分布式两段封锁（2PL）协议、主站点封锁法、主副本封锁法等。虽然封锁模型很多，但它们实现并发控制的原理是类似的，即对事务间的冲突操作通过加锁的原则和锁的相容性机制实现冲突操作的串行化调度。对于共享操作，事务并发执行；对于排它操作，事务串行执行。

在基于封锁的并发控制方法中，分布式两段封锁协议是最基本的方法，两段封锁协议主要是：任何事务在执行过程中必须要经历加锁和解锁两个阶段，并且所有加锁操作必须在解锁操作之前完成。由于分布式事务的执行是划分为多个子事务在不同的结点上执行的，子事务也是全局事务的一部分，因此当全局事务遵循2PL协议时，各个子事务也遵循2PL协议。

下面我们介绍一下基于时标的分布式并发控制。所谓时标是为了唯一标识分布式系统中的事务及其被激活次序而由系统赋予事务的一个时间标记。若事务为A，则其标记为TS(A)。时标具有唯一性，即由TS(A)唯一标识事件A；有序性，即如果事务A发生在事务B之前，则有TS(A)＜TS(B)。

基于时标的并发控制方法的基本思想是：每当一个事务在激活时由系统分配给它一个时标，作为该事务及其激活次序的唯一标识，事务中的操作具有和事务相同的时标；当事务之间发生冲突操作时，冲突操作的执行次序由时标决定，即先激活的事务先执行，后激活的事务后执行；当一个事务的时标小于另一个已执行事务的时标时，该事务被中止，在它重新启动时被赋予一个新的时标。

在基于时标的分布式并发控制方法具体实现时需要解决一个问题，即在分布环境中往往没有一个精确的全局时钟，当事务A和B在不同结点上被激活时系统赋予事务A和B的时标不能确定其发生的先后次序。而且，在不同结点上的事务有可能同时被激活。为此，时标不能简单地使用时钟读数来标识，而需要由本地时钟值和结点标识两部分组成。各个结点有其全局唯一的标识，从而使得时标的唯一性得到满足。本地时钟可以是一个计数器，每当激活一个事务时计数器加1，从而解决了同一结点事务的次序问题。对于不同的结点可以采用一定的同步机制予以解决。

在分布式并发控制中，当采用基于封锁的机制就有可能产生死锁的情况。与集中式数据库死锁类似，分布式死锁的解决方法也有两种：一种是预防，另一种是检测和处理。

（1）死锁预防

形成死锁的原因是由多个事务并发执行，相互等待另外一事务所持有的锁，且形成等待回路而引起的。如果事务T1请求一资源，而该资源被另外一事务T2所持有时，则进行一次预防性检测。若测试结果表明有死锁危险时，或者不让T1进入等待状态，并且重新启动T1或中止并重新启动T2。

有两种死锁预防策略：抢占式和非抢占式，两种策略存在多种形式。

最简单的非抢占式策略根本不允许等待发生。如果一个事务T1请求一个与另一个事务T2冲突的锁，它必须自动夭折，并重新启动。这种策略简化了锁处理，但会导致大量重新启动。

另一种策略是设定事务的性质，允许事务比以前拥有更高的权限。于是，当T1请求由T2持有资源上的锁时，如果Tl的权限比T2低的话，就有非抢占性回答。由于是具有所有优先权类型的调度，低优先权事务将有可能永远不会完成。

第三个策略是有关事务年龄的。每个事务都被赋予一个唯一的诞生时刻。当发生锁冲突时，就必须考虑相对年龄。在等待-死亡策略里，当Ti请求由Tj持有数据上的锁时，如果Ti比Tj年轻，就允许Ti等待，否则夭折Ti。这也是一种非抢占式策略。

回卷-等待是一种抢占式策略，当Ti请求由Tj持有数据上的锁时，如果Ti比Tj老，就允许Ti等待，否则Tj抢先重启动。这两种情况下，在重新启动时保持它们的最初创建时刻是重要的。

与集中式数据库处理相同，也可以通过让所有事务按照一定的顺序请求锁。但因为这种约束使应用程序员在开发程序时需要考虑并发问题，从而违反了并发透明性原则。

（2）死锁检测

对于分布式死锁的检测，可以采用集中控制、分层次控制和分布式控制3种方法来实现。

■ 集中式控制检测全局死锁。选择系统中的某一个结点运行集中式的全局死锁检测程序，它负责接受各个结点的局部等待图并将它们连接成全局等待图，然后在全局等待图中检查是否存在回路。如果存在回路，则发现死锁，需按规定进行解除死锁的处理。这种方法比较简单，但容易受集中式的全局死锁检测程序所在结点的故障影响，而且通信费用较大。

■ 分层次控制检测死锁。系统中的每一个结点都配置一个局部死锁检测程序，并将这些检测程序在整体上构成一个树型结构。其中，叶结点仅负责所在结点的局部死锁检测。非叶结点除了要完成自身结点的局部检测，还要接受其子结点传送的局部等待图和有关信息，与自身等待图合并形成新的等待图，分析其中是否有潜在的全局死锁，并将简化后的等待图向上层结点传送。重复上述过程，直到根结点，便完成了对整个系统的全局死锁检测工作。这种方法降低了对单一结点的依赖，并减少了通信开销，但实现起来比较复杂。

■ 分布式控制检测死锁。系统中的每一个结点都配置一个死锁检测程序，它不仅负责局部的死锁检测而且要完成全局的死锁检测任务。在执行全局死锁检测任务时，需接收从其他结点发来的局部等待图及有关信息，并采用统一的规则和方法修改与生成新的局部等待图，然后沿潜在死锁回路发送信息。当某一结点接收到其他结点发送来的潜在死锁信息后，将潜在死锁回路加入本地的局部等待图中，以形成新的局部等待图。在新的等待图中检测是否存在死锁，如果存在，则进行死锁解除，否则将潜在死锁信息继续传送给下一个结点，再由下一个结点重复上述操作，直到整个系统检测完毕。

无论采用哪一种检测死锁的方法，一旦检测出系统发生全局死锁，就必须进行解除死锁的处理。其方法是在涉及死锁的分布式事务中选择尽可能少的事务，中止或重新启动这些事务，释放其占用的资源，从而消除等待图中的回路，使得其他事务能够继续执行。