分布式事务管理和恢复及数据库并发控制

分布式事务管理和恢复及数据库并发控制

摘要：分布式数据库系统由分布于多个计算机结点上的若干个数据库系统组成,它提供有效的存取手段来操纵这些结点上的子数据库。分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。在一个分布式的数据库系统中往往需要维护同一个数据库或数据块的多个副本, 那么如何有效的维护多副本之间数据一致性的问题就摆到我们面前。本文深入研究了分布式数据库系统的事务管理和恢复以及数据库的并发控制。关键字：分布式数据库，事务管理和恢复，分布式并发控制

1 分布式数据库的概述

随着传统的数据库技术日趋成熟、计算机网络技术的飞速发展和应用范围的扩大，以分布式为主要特征的数据库系统的研究与开发受到人们的注意。分布式数据库是数据库技术与网络技术相结合的产物，在数据库领域已形成一个分支。分布式数据库的研究始于20世纪70年代中期。世界上第一个分布式数据库系统SDD-1是由美国计算机公司（CCA）于1979年在DEC计算机上实现。20世纪90年代以来，分布式数据库系统进入商品化应用阶段，传统的关系数据库产品均发展成以计算机网络及多任务操作系统为核心的分布式数据库产品，同时分布式数据库逐步向客户机／服务器模式发展。

分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。

分布式数据库系统与集中式数据库系统相比具有可扩展性，通过增加适当的数据冗余，提高系统的可靠性。在集中式数据库中，尽量减少冗余度是系统目标之一．其原因是，冗余数据浪费存储空间，而且容易造成各副本之间的不一致性．而为了保证数据的一致性，系统要付出一定的维护代价．减少冗余度的目标是用数据共享来达到的。而在分布式数据库中却希望增加冗余数据，在不同的场地存储同一数据的多个副本,其原因是：a．提高系统的可靠性、可用性当某一场地出现故障时，系统可以对另一场地上的相同副本进行操作，不会因一处故障而造成整个系统的瘫痪。b．提高系统性能系统可以根据距离选择离用户最近的数据副本进行操作，减少通信代价，改善整个系统的性能。

2 分布式事务的管理与恢复

2.1 分布式事务管理

2.1.1 分布式事务定义

在分布式数据库系统中，任何一个应用的请求最终都将转化成对分布在网络中相应站点上数据库数据存取操作的序列，因此分布式数据库系统中的事务是一个分布式操作的序列，被操作的数据分布在不同的站点上，所以称为分布式事务。在分布式数据库系统中，一个分布式事务即全局事务.通常由一个主（父）事务和在不同站点上执行的子事务（局部事务)组成。一般地，主事务负责事务的卄始、提交和异常终止；各个子事务完成对相应站点上数据库的访问操作。所谓"全局事务"是指一个要求访问或更新多个站点上数据的事务，所谓"局部事务"是指一个仅仅访坷或更新一个站点上数据的事务。

1) 分布式事务的特点

同集中式数据库系统--样，为了保证数据库的一致性和可靠性，保证数据访问的正确性和有效性，分布式数据库系统中的事务也应具有事务的ACID四个特性，即原子性、一致性、隔离性和耐久性。

2) 原子性

分布式事务的原子性是指事务执行时的不可分割性。即要么它所包含的引起分布式数据厍改变的操作全部都成功执行，要么都不执行。事务的原了-性保证分布式数据库的状态总是从一个一致状态变换到另一个一致状态，而不会出现不一致状态。

3) 一致性

分布式事务的一致性简单地说是指事务的正确性，或者说一个分布式事务是一个使分布式数据库从一个一致状态转变为另一个一致状态的正确程序。分布式事务执行完毕时，必须以正确的状态退出系统。如果事务不能达到一个正常的结束状态，就必须把分布式数据库退回到该事务执行前的初始状态。所谓分布式数据库状态是指在某个给定时间点上，分布式数据库中存储的所有数据项(值）的集合。分布式数据库的一致性状态应该满足模式所指定的约束，以及数据库必须遵守的任何其他约束。

4) 隔离性

分布式事务的隔离性是指一个正在执行的事务在其提交之前，决不允许把它对共享数据所作改变的结果提供给其他事务使用。这就是说，事务的执行似乎与其他事务相隔离，即事务的执行不应受到其他并发事务执行的干扰。保持事务的隔离性是有许多原因的，保证维护事务的交互一致性是原因之一。如果两个并发执行的事务要操作同一个数据，且其中一个事务要使用另一个事务正在更改，但后来又因某种原因不改了的数据，就不能保证第二个事务

使用的值是正确的。

2.1.3分布式事务的结构和事务状态

1）分布式事务的结构

2）分布式数据库中进程的协作

两个概念

进程:是一个具有一定独立功能的程序关于某个数据集合的一次运行活动。它有两个侧面:

（1）进程说明：定义进程的行为模式, 包括数据和对数据的一组操作, 执行这组操作, 完成某一功能。

（2）进程执行：按进程说明中所定义的模式来启动这个进程，执行其中的那组操作。

进程的协作

为了协调地执行分布式应用的全局操作，分驻于不同站点的诸事务代理必须进行协调。为考虑事务的特性，把各站点上的诸代理组建成协作进程来完成一个全局应用，并作如下规定：

每一应用均有一个负责启动整个事务的总代理或称根代理，建立总代理的站点称为源站点；

只有总代理才能发出全局有效的事务开始，提交和撤销原语；

只有总代理才能请求建立新的事务代理；

各站点上的子事务都执行成功，总代理才能决定提交该事务，否则总代理将决定撤销该事务。

2.1.4分布式事务管理的问题和目标

1）分布式事务管理的问题

(1) 处理数据项的多个副本:分布式事务管理负责保持同一数据的多个副本间的一致性。

(2) 单个站点的故障:当故障站点得到恢复时，DDBMS协同该故障站点上的DBMS，必须在该站点与系统重新连接时，使它的局部数据与其他站点同步。

(3) 通信网络的故障:系统必须有能力处理一个或多个连接站点的通信网络故障。这个问题的一个极端情况是发生网络分割。

(4) 分布式提交:如果在提交一个分布式事务过程中至少有一个站点发生故障的话，那么这个分布式事务的提交将会产生问题。

2）分布式事务管理的目标

事务管理的任务就是负责当若干个事务并发执行和事务执行发生错误时，使数据库仍保持一致状态。

图1.分布式事务管理

事务管理的目标是：

（1）维护分布式事务的原子性，一致性，耐久性和隔离性。

（2）获得最小的主存和CPU开销，降低控制报文的传输个数和加快分布式事务的响应速度；

（3）获得最大限度的系统可靠性和可用性。

2.1.5分布式事务的管理

事务管理的任务就是负责当若千个事务并发执行和事务执行发生错误时，使数据库仍保持一致状态。

1) 分布式事务管理的抽象模型

在分布式数据库系统中，事务管理功能分成两个层次。在每个站点上，又类似于集中式数据库系统中的局部事务管理器（LTM）进行局部事务的管理,负责本站点事务的执行，完成对本站点数据库数据的访问；对整个分布式数据库系统，由驻留在各个站点上的分布式事务管理器（DTM）共同协作，实现对分布式事务的协调和管理。

图2分布式事务管理的抽象模型

局部事务管理器LTM的结构和功能在许多方面与集中式系统类似，主要包括：（1）保证本地事务的ACID特性；

（2）维护一个用于恢复的日志，代替DTM把用于分布式事务执行和恢复的信息记入日志。

（3）参与适当的并发控制模式，以协调在该站点上执行的事务的并发执行。接收并听从本站点上DTM代理发来的LOG原语，记入日志并执行之。

分布式事务管理器DTM的功能包括：

（1）保证分布式事务的ACID特性，尤其是执行分布式事务的原子性,使每个站点的子事务都成功执行，或都不执行。这是通过向各个站点begin_transaction,commitabort,create 原语来实现的。

（2）负责协调由该站点发出的所有分布式事务的执行。包括：启动分布式事务的执行；将分布式事务分解为一些子事务，并将这些子事务分派到恰当的站点上去执行；决定分布式事务的终止，即决定在该分布式事务中所包含的所有站点上的子事务都撤销或都提交。

（3）支持分布式事务的执行位置透明性，这也是分布式事务管理的最基本要求。分布式事务管理器根据事务内部的逻辑划分为若干子事务，按某种要求分布到相应站点上执行，最后由源发站点提供事务的最终结果。它实现了对网络上各站点的各个子事务的监督与管理，完成对整个分布式事务执行过程的调度和管理，从而保证分布式数据库系统的高效率。

2) 分布式事务执行的控制模型

分布式事务控制模型是指协调分布式事务中各成员DBMS执行其子事务的通用方法。控制分布式事务执行的控制模型有：主从模型、三角模型和层次模型。

主从控制模型

这种控制模型由分布式事务管理器作为主控器，而用一个或几个局部半务管理器作为从控制器。在这种模型中，分布式事务管理器通过对局部半务管理器发送消息和接受从它们那里返回的消息，来控制所有的需要同步的操作。分布式事务管理器激活每一个局部事务管理器，且指示其做什么。根据这些指示，由局部事务管理器完成各自对本地数据库的访问，并把结果返回到分布式亊务管理器。

三角控制模型

在这种控制模型中，控制是在分布式事务管理器与局部事务管理器之间分享的。局部事务管理器与局部事务管理器之间可以发送和接收数据，而不必通过分布式事务管理器作为中介。这种控制模型避免/在分布式事务管理器与局部事务管理器之间不必要的数据传输。

层次控制模型

在这种控制模型中，每个局部事务管理器本身又可作为分布式事务管理器。这种控制模型允许进行追加设计，当某个局部事务管理器接受到来自另一个局部亊务管理器的请求时，该局部亊务管理器自身即成为一个全局事务管理器。它可以把接收到的事务优化成为另一个分布式事务，并将其分布到相关的其他局部亊务管理器上去执行。可见，这种控制模型比前两种控制模型更为复杂。

2.2 分布式数据库事务恢复

2.2.1分布式数据库系统中的故障

数据库在运行过程中故障和错误总是难免的。不同的故障会造成数据库不同

程度的损害, 轻则事务不能正常运行, 重则造成数据库数据不一致性。更严重的情况, 会使部分或整个数据库遭到破坏。

2.2.2 事务故障恢复的基本概念

研究数据库系统中故障的恢复，主要是指如何恢复因故障而破坏的数据库，使数据库恢

复到一个正确，一致的状态。恢复的基本原理是数据冗余，即利用冗余存储在别处的信息和

数据，部分或全部重建数据库。

1）事务故障和事务恢复

当发生事务故障时，保证事务原子性的措施称为事务故障恢复，简称为事务恢复。事务

恢复主要时依靠日志来实现的。

2）事务状态及状态转移

为保证可恢复性，系统需要保存事务的起始，终止，提交或撤销的时间轨迹，事务恢复

管理器还对下列操作进行跟踪记录。

3）事务的提交点

当事务T所有的站点数据库存取操作都已成功执行，并且所有操作对数据库的影响都已

记录在日志中时，该事务T就到达提交点(committed point).提交点后事务就成为已提交的

事务，并且假定其结果已永久记录在数据库中（事务的永久性)。然后事务在日志中写入提

交记录[commit,T].在系统发生故障时，需要扫描日志，检查那些已在日志中写入

[start_transaction,T],但没有写入[commit,T]的所有事务T；恢复时必须回滚这些事务以

取消他们对数据库的影响。此外，还必须对日志中记录的已提交事务的所有写操作进行恢复，

这样他们对数据库的作用才可根据这些记录重做。需要注意的是，必须将日志文件保存在磁

盘上。在事务到达提交点以前，还未写到磁盘的日志的任何部分，必须被写入磁盘，这称为事务提交前强制写(force writing)日志。

4）日志，档案库和检查点

（1）日志：为了能够从故障状态中恢复由影响的事务，系统维护一个日志(log)来保存所有影响数据库项的值的事务操作的信息，这些信息可以用于故障时的恢复。日志保存在磁盘上，这样除了磁盘和灾难性故障外，它不会受到任何影响。另外，日志会被定期备份到归档存储设备（例如磁带）中，以预防磁盘和灾难性故障。下面列出的是日志的条目类型（称为日志记录）和每个类型设计的相关动作。在条目中。T表示唯一事务标识(transaction_id)用于标识每个事务。

（2）档案库：一个大型的系统一天可以很容易地产生大量的Log记录．因此，将日志全部存放在盘中是不现实的。故一般将日志划分为两部分，一部分是当前活动的联机部分，存放在直接存取设备上，称为直接存取数据集(direct access data set)或简称日志数据集(log data set).另一部分是档案存储部分，存放在二级存储设备上，例如磁带上。每当数据集满时就转存到档案存储设备中去。存放日志的档案存储设备称日志档案库(log archive).为了防止因介质故障而破坏数据库，要定期将整个数据库的全部内容转储到档案库中去。存放数据库的档案存储设备称数据库档案库(DB archive).

（3）检查点：为了便于恢复，在日志中增加一类新的记录——检查点(checkpoint),以标识检查点前已执行完的事务是正确的，增加一个重启动文件。

2.2.5 事务故障的恢复

1) 事务恢复的原则

孤立和逐步退出事务的原则:对于不影响其他事务的可排除性局部故障．例如事务操作的删除、超时、违反完整性规则、资源、限制、死锁等，应令某个事务孤立地和逐步地退出．将其所做过的修改复原，即做UND0。

成功结束事务原则:成功结束事务所做过的修改应超越各种故障而存在,也就是重做(REDO)它所做过的所有修改数据库的操作。

夭折事务的原则:若发生了非局部性的不可排除的故障，例如系统崩溃，则撤消全部事务，恢复到初态：这有两种做法，一种是利用数据库的备份实现；另一种是按逆向顺序操作，复原其启动以来所做过的一切修改。

2) 本地事务的恢复

本地事务的恢复过程类似于集中式数据库系统中事务的恢复。当故障排除后，由局部事

务管理器的恢复子系统执行事务恢复，过程如图所示。

3）分布式事务的恢复

在分布式事务恢复中，本地事务的恢复类同于集中式事务的恢复，由本地事务管理器具体执行；而整个分布式事务的恢复由分布式事务管理器与本地事务管理器协同完成。

图6分布式事务恢复的参考模型

3 分布式数据库中的并发控制

3.1 并发控制的概述

并发控制是指在多用户的环境先，对数据库进行并发操作进行规范的机制。并发控制是以事务为单位进行的，其作用主要是协调同一时间访问同一数据库文件的多个事务之间的关系，

防止这些事务间发生冲突，产生一个可串行化得调度。如果不对并发执行的程序进行必要的控制，那么即使没有故障和程序出错也会破坏数据库的一致性和完整性。因此，一个数据库系统有无并发控制机制，以及并发控制机制的优劣是衡量一个数据库系统功能强弱和性能好坏的重要标志之一

3.2 并发的目的

并发控制是分布式数据库系统中分布式事务管理的基本任务之一，在数据库管理系统中对事务采用并发机制的主要目的有两个：

1）改善系统的资源利用率

对于一个事务来讲，在不同的执行阶段需要的资源不同，有时需要CPU，有时需要访问磁盘，有时需要I/O、有时需要通信如果事务串行执行，有些资源可能会空闲；如果事务并发执行，则可以交叉利用这些资源，有利于提高系统资源的利用率

2）改善短事务的响应时间

设有两个事务T1 和T2，其中T1是长事务，交付系统在先；T2是短事务，交付系统比T1稍后。如果串行执行，则须等T1执行完毕后才能执行T2。而T2的响应时间会很长。一个长事务的响应时间长一些还可以得到用户的理解，而一个短事务的响应时间过长，用户一般难以接受。

如果T1 和T2并发执行，则T2可以和T1重叠执行，可以较快地结束，明显地改善其响应时间。

3.3 并发控制的方法

分布式并发控制的主要目的是保证分布事务和分布式数据库的一致性, 实现分布事务的可串行性, 保持事务具有良好的并发度以保证系统具有用户满意的效率。

分布式并发控制技术是以集中式数据库的并发控制技术为基础, 针对分布式系统的特点扩充而来的。集中式数据库的并发控制是以可串行性为准则来检验并发控制方法的正确性, 这一点在分布式数据库系统中同样起作用。在分布式系统中, 每个节点上的事务是可以串行的, 而不同节点的事务处理则完全是可以并行的。

可以假定每个局部结点都是以集中式数据库的并发控制机制为基础, 在局部结点上己实现了局部的可串行化调度, 那么分布式并发控制重点就是要构造一个可保证全局顺序的可串行化调度。即:

(1)每个局部结点的调度S 是可串行化的;

(2)可通过一个等价性获得一个分布事务T1,T2,?,Tn 的全局顺序。

常用的分布式并发控制方法有基于封锁的方法、时标方法及乐观并发控制方法, 其中基于封锁的方法为大多数实际系统所采用。

3.3.1 封锁方法

封锁方法是最常用的并发控制方法。它的基本思想是: 要求一事务在对一数据对象进行操作前必须先申请对该数据对象的封锁(Lock), 获准后才能进行操作。如果该数据对象己经被其它事务封锁, 且操作方式冲突, 那么该事务必须处于等待状态, 直到该数据对象被释放为止。确切的控制则由封锁类型决定, 封锁方法通过规定相应的加锁原则和封锁相容机制实现冲突操作的可串行调度。最简单的封锁模型有共享锁(Share Locks 简称S 锁)和排它锁(Exclusive Locks, 简称X 锁)两种。

在该模型中, S 锁是对数据项进行读操作时要加的锁, X 锁是对数据项进行写入操作时要加的锁。S 锁和X 锁的相容矩阵如表1 所示, 其中列表示锁的持有者, 行表示锁的申请者: “十”表示相容, “一”表示不相容。

S 锁与X 锁的相容性矩阵从该矩阵中可以看出, 只要一事务拥有对数据对象的X 锁,就禁止其它事务访问该数据。如果两事务同时以互斥方式申请对同一数据对象的封锁, 则说这两个事务发生冲突。当可共享时事务可并发执行, 当排斥时事务需串行执行。

3.3.2 基于时标的并发控制方法

时标并发控制方法的基本思想是: 利用系统内唯一的事务时标和数据对象上记录的最新读和写的时标来保证数据库及事务所得结果的一致性。每个事务在被激活时分配一个时标, 这个时标可以唯一标识一个事务和事务的激活次序。事务中的操作拥有该事务的时标, 事务对数据对象进行操作时把自己的时标赋给该数据对象, 当事务间存在冲突操作时, 冲突操作的执行次序由时标决定, 时标小的先执行, 时标大的后执行。

当一个事务的时标大于另一个事务的时标时, 该事务被中止, 重新启动后被赋以另一个时标。该方法的最大优点是事务不会出现中断, 因而不会发生无限期的等待, 所以也不存在死锁的现象。采用这种方法的事务具有较好的并发度。但是该方法也存在一些缺点: 首先, 它是采用重启的方法作为保持事务全局顺序的基本手段, 重启意味着要退回到事务的原始起点, 因此对事务(特别是长事务)来说其代价是比较大的; 其次, 在冲突发生比较多情况下, 重启次数过多会导致大量的浪费; 再次, 在分布式系统中维护一个全局统一的时标并不容易。

采用时标的并发控制算法主要有两种: 基本时标方法和保守时标方法。基本时标方法的规则是:

(1)每个事务在激活时得到系统赋予的时标;

(2)该事务在执行每一个读写操作时均具有该事务的时标;

(3)对于每一个数据项x, 记录了最大读操作的时标RTM(x)和最大写操作的时标的WTM(x);

(4)假设TS 为对x 进行读操作的时标, 如果TS

(5)假设TS 为对x 进行写操作的时标, 如果TS

在基本时标方法中, 由于不存在等待状态, 不会产生死锁问题, 因此也就不需死锁检测和解除机制。它的主要缺点是事务重新启动的次数较多。

为了解决基本时标方法存在大量事务重启的问题, 人们提出了保守时标方法。该方法的主要特点是不拒绝任何操作, 因此不会重新启动事务。其处理方法是: 当冲突发生时, 把时标大的操作缓冲起来, 等待时标小的操作执行完毕后再执行被缓冲起来的操作, 所以它不拒绝任何操作。但由于保守时标方法中有等待状态,因此可能出现死锁的情况。另外还有可能出现某一场地被阻塞的情况。

3.3.3 乐观并发控制方法

与封锁方法和时标方法把冲突操作暂时停止或拒绝执行不同, 乐观方法总是让一事务执行完成。该方法的一个基本前提是事务间极少发生冲突, 大多数事务可以无冲突正确执行完毕。因此可以不考虑冲突, 让事务执行完毕, 把写操作的结果暂时保存,而不是对数据库进行操作。事务结束之后, 由一个专门的检测确认过程来检测事务的执行是否可串行化, 若通过检测, 则把写操作的结果永久化, 即写入到数据库中去, 否则重新启动该事务。为完成上述检测, 必须保留事务执行时的某些信息, 直到检测执行完成为止。乐观并发控制方法的执行过程分成三个阶段:

(1)读出阶段(read phase): 读出所需的数据项, 进行数据处理并决定回写结果的值, 然后把此值保存在一个暂存空间, 而不是写入数据库;

(2)检测阶段(validation phase): 检测对数据库的更新操作是否会引起数据库的不一致性。若通过检测, 则执行(3), 否则重新启动该事务;

(3)写入阶段(write phase): 把(1)中暂存的数据写入数据库。在该方法中, 读出阶段是事务执行的主要阶段; 检测阶段是该方法的关键阶段, 用于检查事务所进行的更新是否会破坏数据库的一致性, 如有这种可能性则应采取相应的措施; 写入阶段则实际完成对数

据库的更新操作。分布式并发控制方法的检测主要以数据对象上的时标及事务上的时标为基本手段。目前这种方法仍停留在研究阶段, 实际上很少使用。

4 结束语

本文通过阐述了分布式数据库系统的概念以及分布式事务管理以及数据库并发控制,了解到了数据库的功能是强大的，面对目前的信息化社会，在整理、查找、分析数据方面是一个强有力的工具。并发控制是分布式数据库系统为了适应多用户操作所必须解决的问题。各种分布式数据库并行控制算法有其各自的优点和缺点，分布式数据系统是在集中式数据库系统技术的基础上发展起来的，并发控制也是分布式数据库研究的最关键热点问题之一。

参考文献：

[1] 分布式数据库系统及其应用邵佩英著科学出版社 2005.3:105-107

[2] 基于分布式数据库系统的故障恢复技术研究张传宏苗苗著信息资源建设与管理 2007.9

[3] 分布式并发控制技术弓耀龙著山西电子技术 2010.4

[4] 分布式数据库并发控制方法研究蒋亚虎著数据库及信息管理 2007.7

[5] 分布式数据库系统中的事务管理杨志伟著内蒙古科技与经济 2008.4

[6] 分布式数据库操作中的并行控制理论与算法胡忠顺著上海海运学院学报1997.5

[7] 分布式并发控制算法分析[ J]. 王学军. 福建电脑,2006( 12): 74, 86- 87.

[8] 分布式数据库系统实现技术. 周龙祥北京科学出版社 1998