第十一章——并发控制

• 数据库是一个共享资源，可以供多个用户使用。允许多个用户同时使用同一个数据库的数据库系统称为多用户数据库系统
• 事务可以一个一个地串行执行，即每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行。事务在执行过程中需要不同的资源，有时需要CPU，有时需要存取数据库，有时需要I/O，有时需要通信。如果事务串行执行，则许多系统资源将处于空闲状态。因此，为了充分利用系统资源，发挥数据库共享资源的特点，应该允许多个事务并行地执行。
• 在单处理机系统中，事务的并行执行实际上是这些并行事务的并行操作轮流交叉运行(分时系统)。这种并行执行方式称为交叉并发方式(interleaved concurrency)。虽然单处理机系统中的并行事务并没有真正地并行运行，但是减少了处理机的空闲时间，提高了系统的效率。
• 在多处理机系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并发运行。这种并发执行方式称为同时并发方式(simultaneous concurrency)。
• 当多个用户并发地存取数据库时就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会存取和存储不正确的数据，破坏事务的一致性和数据库的一致性。所以数据库管理系统必须提供并发控制机制。并发控制机制是衡量一个数据库管理系统性能的重要标志之一。

并发控制概述

• 事务是并发控制的基本单位，保证事务的ACID特性是事务处理的重要任务，而事务的ACID特性可能遭到破坏的原因之一是多个事务对数据库的并发操作造成的。为了保证事务的隔离性和一致性，数据库管理系统需要对并发操作进行正确调度。

并发操作带来的数据不一致性包括丢失修改、不可重复读和读“脏”数据。

• 丢失修改(lost update)：两个事务$T_1$和$T_2$读入同一数据并修改，$T_2$提交的结果破坏了$T_1$提交的结果，结果导致$T_1$的修改被丢失了。

• 不可重复读(non-repeatable read)：事务$T_1$读取数据后，事务$T_2$执行更新操作，使$T_1$无法再现前一次读取结果。具体地讲，不可重复读包括以下三种情况：
  (1)事务$T_1$读取某一数据后，事务$T_2$对其进行了修改，当事务$T_1$再次读该数据时，得到与前一次不同的值
  (2)事务$T_1$按一定条件从数据库中读取某些数据记录后，事务$T_2$删除了其中部分记录，当$T_1$再次按相同条件读取数据时，发现某些记录神秘地消失了。
  (3)事务$T_1$按一定条件从数据库中读取某些数据记录后，事务$T_2$插入了一些记录，当$T_1$再次按相同条件读取数据时，发现多了一些记录。
  后两种不可重复读有时也称为幻影(phantom row)现象

• 读"脏"数据(dirty read)：事务$T_1$修改某一数据并将其写回磁盘，事务$T_2$读取同一数据后，$T_1$由于某种原因被撤销，这时被$T_1$修改过的数据恢复原值，$T_2$读到的数据就与数据库中的数据不一致，则$T_2$读到的数据为"脏"数据，即不正确地数据。

• 产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其它事务的干扰，从而避免造成数据的不一致性。

• 另一方面，对数据库的应用有时允许某些不一致性，例如有些统计工作涉及数据量很大，读到一些"脏"数据对统计精度没什么影响，这时可以降低对一致性的要求以减少系统开销。

• 并发控制的主要技术有封锁(locking)、时间戳(timestamp)、乐观控制法(optimistic scheduler)和多版本并发控制(multi-version concurrency control，MVCC)等。

封锁

• 封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其他事务不能更新此数据对象。

确切的控制由封锁的类型决定。基本的封锁类型有两种：排他锁(exclusive locks，简记为X锁)和共享锁(share locks，简记为S锁)。

• 排他锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁为止。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。
• 共享锁又称为读锁。若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

排他锁和共享锁的控制方式可以用相容矩阵(compatibility matrix)来表示

$T_1$ \ $T2$	X	S	-
X	N	N	Y
S	N	Y	Y
-	Y	Y	Y

Y=Yes，相容的请求
N=No，不相容的请求
在封锁类型相容矩阵中，最左边一列表示事务$T_1$已经获得的数据对象上的类型，其中横线表示没有加锁。最上面一行表示另一事务$T_2$对同一数据对象发出的封锁请求。$T_2$的封锁请求能否被满足用矩阵中的Y和N表示，其中Y表示事务$T_2$的封锁要求与$T_1$已持有的锁相容，封锁请求可以满足。N表示$T_2$的封锁请求与$T_1$已持有的锁冲突，$T_2$的请求被拒绝。

封锁协议

在运用X锁和S锁这两种基本封锁对数据对象加锁时，还需要约定一些规则，例如，应何时申请X锁或S锁、持锁时间、何时释放等。这些规则称为封锁协议(locking Protocol)。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。下面介绍三级封锁协议，对并发操作的不正确调度可能会带来丢失修改、不可重复读和读"脏"数据等不一致性问题，三级封锁协议分别在不同程度上解决了这些问题，为并发操作的正确调度提供一定的保证。不同级别的封锁协议达到的系统一致性级别是不同的。

1. 一级封锁协议
   一级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束(COMMIT)和非正常结束(ROLLBACK)。
   一级封锁协议可防止丢失修改，并保证事务T是可恢复的。
   在一级封锁协议中，如果仅仅是读数据而不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读"脏"数据。
2. 二级封锁协议
   二级封锁协议是：在一级封锁协议基础上增加事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。
   二级封锁协议除防止了丢失修改，还可进一步防止读"脏"数据。
3. 三级封锁协议
   三级封锁协议是：在一级封锁协议的基础上增加事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。
   三级封锁协议除防止了丢失修改和读"脏"数据外，还进一步防止了不可重复读。

上述三级协议的主要区别在于什么操作需要申请封锁，以及何时释放锁(即持锁时间)。三级封锁协议可以总结如下表，表中还指出了不同的封锁协议使事务达到的一致性级别是不同的，封锁协议级别越高，一致性程度越高。

	X锁		S锁		一致性保证
	操作结束释放	事务结束释放	操作结束释放	事务结束释放	不丢失修改	不读"脏"数据	可重复读
一级封锁协议		√			√
二级封锁协议		√	√		√	√
三级封锁协议		√		√	√	√	√

活锁和死锁

• 和操作系统一样，封锁的方法可能引起活锁和死锁等问题。

活锁

• 如果事务$T_1$封锁了数据R，事务$T_2$又请求封锁R，于是$T_2$等待。$T_3$也请求封锁R，当$T_1$释放了R上的封锁之后系统首先批准了$T_3$的请求，$T_2$仍然等待。然后$T_4$又请求封锁R，当$T_3$释放了R上的封锁之后系统又批准了$T_4$的请求…$T_2$有可能永远等待，这就是活锁的情形。
• 避免活锁的简单方法是采用先来先服务的策略。当多个事务请求封锁同一数据对象时，封锁子系统按请求封锁的先后次序对事务排队，数据对象上的锁一旦释放就批准申请队列中第一个事务获得锁。

死锁

• 如果事务$T_1$封锁了数据$R_1$，$T_2$封锁了数据$R_2$，然后$T_1$又请求封锁$R_2$，因$T_2$已封锁了$R_2$，于是$T_1$等待$T_2$释放$R_2$上的锁；接着$T_2$又申请封锁R1，因$T_1$已封锁了$R_1$，$T_2$也只能等待$T_1$释放$R_1$上的锁。这样就出现了$T_1$在等待$T_2$，而$T_2$又在等待$T_1$的局面，$T_1$和$T_2$两个事务永远不能结束，形成死锁。
• 死锁的问题在操作系统和一般并行处理中已做了深入研究，目前在数据库中解决死锁问题主要有两类方法，一类方法是采取一定措施来预防死锁的发生，另一类方法是允许发生死锁，采用一定手段定期诊断系统中有无死锁，若有则解除之。

1. 死锁的预防

• 在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法：

(1)一次封锁法

• 一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。
• 一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，第一，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度；第二，数据库中数据是不断变化的，原来不要求封锁的数据在执行过程中可能会变成封锁对象，所以很难事先精确地确定每个事务所要封锁的数据对象，为此只能扩大封锁范围，将事务在执行过程中可能要封锁的数据对象全部加锁，这就进一步降低了并发度。

(2)顺序封锁法

• 顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。
• 顺序封锁法可以有效地防止死锁，但也同样存在问题，第一，数据库系统中封锁的数据对象极多，并且随数据的插入、删除等操作而不断地变化，要维护这样的资源的封锁顺序非常困难，成本很高；第二，事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。
• 可见，在操作系统中广为采用的预防死锁的策略并不太适合数据库的特点，因此数据库管理系统在解决死锁的问题上普遍采用的是诊断并解除死锁的方法。

2. 死锁的诊断与解除
   数据库系统中诊断死锁的方法与操作系统类似，一般使用超时法或事务等待图法。

(1)超时法

• 如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，如事务因为其他原因使等待时间超过时限，系统会误认为发生了死锁；二是时限若设置得太长，死锁发生后不能及时发现。

(2)等待图法

• 事务等待图是一个有向图G=(T，U)。 T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若$T_1$等待$T_2$，则在$T_1$、$T_2$之间画一条有向边，从$T_1$指向$T_2$。
• 事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地(比如每隔1分钟)检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。
• DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其他事务得以继续运行下去。当然，对撤销的事务所执行的数据修改操作必须加以恢复。

并发调度的可串行性

• 数据库管理系统对并发事务不同的调度可能会产生不同的结果，显然，串行调度是正确的。执行结果等价于串行调度的调度也是正确的。这样的调度叫作可串行化调度。

1. 可串行化调度

• 定义：多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务的结果相同，称这种调度策略为可串行化(serializable)调度
• 可串行性(serializability)是并发事务正确调度的准则。按这个准则规定，一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度。

2. 冲突可串行化调度

• 冲突操作是指不同的事务对同一个数据的读写操作和写写操作：
  $R_i(x)$与$W_j(x)$ $/\ast 事务T_i读x，T_j写x，其中i\ne j\ast /$
  $W_i(x)$与$W_j(x)$ $/\ast 事务T_i写x，T_j写x，其中i\ne j\ast /$
  其他操作是不冲突操作
• 不同事务的冲突操作和同一事务的两个操作是不能交换(swap)的。对于$R_i(x)$与$W_j(x)$，若改变二者的次序，则事务$T_i$看到的数据库状态就发生了改变，自然会影响到事务$T_i$后面的行为。对于$W_i(x)$与$W_j(x)$，改变二者的次序也会影响数据库的状态，x的值由等于$T_j$的结果变成了等于$T_i$的结果。
• 一个调度Sc在保证冲突操作的次序不变的情况下，通过交换两个事务不冲突操作的次序得到另一个调度Sc’，如果Sc’是串行的，称调度Sc为冲突可串行化的调度。若一个调度是冲突可串行化，则一定是可串行化的调度。因此可以用这种方法来判断一个调度是否是冲突可串行化的。
• 应该指出的是，冲突可串行化调度是可串行化调度的充分条件，不是必要条件。还有不满足冲突可串行条件的可串行化调度。

两段锁协议

• 为了保证并发调度的正确性，数据库管理系统的并发控制机制必须提供一定的手段来保证调度是可串行化的。目前数据库管理系统普遍采用两段锁(TwoPhase Locking，简称2PL)协议的方法实现并发调度的可串行性，从而保证调度的正确性。

所谓两段锁协议是指所有事务必须分两个阶段对数据项加锁和解锁

• 在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁
• 在释放一个封锁之后，事务不再申请和获得任何其他封锁

所谓"两段"锁的含义是，事务分为两个阶段：

1. 获得封锁，也称为扩展阶段，可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁
2. 释放封锁，也称为收缩阶段，可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁

可以证明，若并发执行的所有事务均遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的。

• 需要说明的是，事务遵循两段锁协议是可串行化调度的充分条件，而不是必要条件。也就是说，若并发事务都遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的；但是，若并发事务的一个调度是可串行化的，不一定所有事务都符合两段锁协议。
• 另外，要注意两段锁协议和防止死锁的一次封锁法的异同之处。一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。因此一次封锁法遵守两段锁协议；但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁，因此遵循两段锁协议的事务可能发生死锁。

封锁的粒度

• 封锁对象的大小称为封锁粒度(granularity)。封锁对象可以是逻辑单元，也可以是物理单元。以关系数据库为例，封锁对象可以是这样一些逻辑单元：属性值、属性值的集合、元组、关系、索引项、整个索引直至整个数据库；也可以是这样一些物理单元包括：页(数据页或索引页)、物理记录等。
• 封锁粒度与系统的并发度和并发控制的开销密切相关。直观地看，封锁的粒度越大，数据库所能够封锁的数据单元就越少，并发度就越小，系统开销也越小；反之，封锁的粒度越小，并发度较高，但系统开销也就越大。
• 因此，如果在一个系统中同时支持多种封锁粒度供不同的事务选择是比较理想的，这种封锁方法称为多粒度封锁(multiple granularity locking)。选择封锁粒度时应该同时考虑封锁开销和并发度两个因素，适当选择封锁粒度以求得最优地结果。一般来说，需要处理某个关系的大量元组的事务可以以关系为封锁粒度；需要处理多个关系的大量元组的用户事务可以以数据库为封锁粒度；而对于一个处理少量元组的用户事务，以元组为封锁粒度就比较合适了。

多粒度封锁

• 讨论多粒度封锁，首先定义多粒度树。多粒度树的根结点是整个数据库，表示最大的数据粒度。叶结点表示最小的数据粒度。

粒度封锁协议允许多粒度树中的每个结点被独立地加锁。对一个结点加锁意味着这个结点的所有后裔结点也被加以同样类型的锁。因此，在多粒度封锁中一个数据对象可能以两种方式封锁：显式封锁和隐式封锁。

• 显式封锁是应事务的要求直接加到数据对象上的封锁
• 隐式封锁是该数据对象没有独立加锁，是由于其上级结点加锁而使该数据对象加上了锁。

多粒度封锁方法中，显式封锁和隐式封锁的效果是一样的，因此系统检查封锁冲突时不仅要检查显式封锁还要检查隐式封锁。

• 一般地，对某个数据对象加锁，系统要检查该数据对象上有无显式封锁与之冲突；再检查其所有上级结点，看本事务的显式封锁是否与该数据对象上的隐式封锁(即由于上级结点已加的封锁造成的)冲突；还要检查其下级所有结点，看它们的显式封锁是否与本事务的隐式封锁(将加到下级结点的封锁)冲突。显然，这样的检查方法效率很低。为此人们引进了一种新型锁，称为意向锁(intention lock)。有了意向锁，数据库管理系统就无须逐个检查下一级结点的显示封锁。

意向锁

• 意向锁的含义是如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。

三种常用的意向锁：意向共享锁(Intent Share Lock，IS锁)；意向排他锁(Intent Exclusive Lock，IX锁)；共享意向排他锁(Share Intent Exclusive Lock，SIX锁)。
1. IS锁

• 如果对一个数据对象加IS锁，表示它的后裔结点拟(意向)加S锁

2. IX锁

• 如果对一个数据对象加IX锁，表示它的后裔结点拟(意向)加X锁

3. SIX锁

• 如果对一个数据对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX

下图给出了这些锁的相容矩阵，从中可以发现这5种锁的强度有如图的偏序关系。所谓锁的强度是指它对其他锁的排斥程度。一个事务在申请封锁时以强锁代替弱锁是安全的，反之则不然。

$T_1$ \ $T_2$	S	X	IS	IX	SIX	-
S	Y	N	Y	N	N	Y
X	N	N	N	N	N	Y
IS	Y	N	Y	Y	Y	Y
IX	N	N	Y	Y	N	Y
SIX	N	N	Y	N	N	Y
-	Y	Y	Y	Y	Y	Y

在具有意向锁的多粒度封锁方法中,任何事务T要对一个数据对象加锁，必须先对它的上层结点加意向锁。申请封锁时应按自上而下的次序进行，释放封锁时则应该按自下而上的次序进行。

其他并发控制机制

并发控制的方法除了封锁技术外还有时间戳方法、乐观控制法和多版本并发控制等

• 时间戳方法给每一个事务盖上一个时标，即事务开始执行的时间。每个事务具有唯一的时间戳，并按照这个时间戳来解决事务的冲突操作。如果发生冲突操作，就回滚具有较早时间戳的事务，以保证其他事务的正常执行，被回滚的事务被赋予新的时间戳并从头开始执行。
• 乐观控制法认为事务执行时很少发生冲突，因此不对事务进行特殊的管制，而是让它自由执行，事务提交前再进行正确性检查。如果检查后发现该事务执行中出现过冲突并影响了可串行性，则拒绝提交并回滚该事务。乐观控制法又被称为验证方法(certifier)。
• 多版本并发控制(MultiVersion Concurrency Control，MVCC)是指在数据库中通过维护数据对象的多个版本信息来实现高效并发控制的一种策略。

多版本并发控制

• 版本(version)是指数据库中数据对象的一个快照，记录了数据对象某个时刻的状态
• 多版本并发控制利用物理存储上的多版本来维护数据的一致性。这就意味着当检索数据库时，每个事务都看到一个数据的一段时间前的快照，而不管正在处理的数据当前的状态。多版本并发控制和封锁机制相比，主要的好处是消除了数据库中数据对象读和写操作的冲突，有效地提高了系统的性能加粗样式。
• 多版本并发控制方法有利于提高事务的并发度，但也会产生大量的无效版本，而且在事务结束时刻，其所影响的元组的有效性不能马上确定，这就为保存事务执行过程中的状态提出了难题。

改进的多版本并发控制

• 多版本协议可以进一步改进。区分事务的类型为只读事务和更新事务。对于只读事务，发生冲突的可能性很小，可以采用多版本时间戳。对于更新事务，采用比较保守的两阶段封锁(2PL)协议。这样的混合协议成为MV2PL。
• 除了传统的读锁(共享锁)和写锁(排他锁)外，引进一个新的封锁类型，称为验证锁(certify-lock，或C锁)
• 封锁的相容矩阵如表：

	R-Lock	W-Lock	C-Lock
R-Lock	Y	Y	N
W-Lock	Y	N	N
C-Lock	N	N	N