数据库理论之并发控制

并发控制概述

多用户数据库:允许多个用户同时使用的数据库(订票系统)

不同的多事务执行方式:

  1. 串行执行:每个时刻只有一个事务运行,其他事务必须等到这个事务结束后方能运行。
  2. 交叉并发方式:单处理机系统中,事务的并发执行实际上是这些并行事务的并行操作轮流交叉运行(不是真正的并发,但是提高了系统效率)
  3. 同时并发方式:多处理机系统中,每个处理机可以运行一个事务,多个处理机可以同时运行多个事务,实现多个事务真正的并行运行

并发执行带来的问题:
+ 多个事务同时存取同一数据(共享资源)
+ 存取不正确的数据,破坏事务一致性和数据库一致性

并发操作带来的数据不一致性包括
1. 丢失修改(lost update)
2. 不可重复读(non-repeatable read)
3. 读脏数据(dirty read)

并发控制机制的任务:
1. 对并发操作进行正确的调度
2. 保证事务的隔离性
3. 保证数据库的一致性

并发控制的主要技术:
1. 封锁(locking)(主要使用的)
2. 时间戳(timestamp)
3. 乐观控制法(optimistic scheduler)
4. 多版本并发控制(multi-version concurrency control ,MVCC)

封锁

封锁:封锁就是事务 T 在对某个数据对象(例如表、记录等)操作之前,先向系统发出请求,对其加锁。加锁后事务 T 就对该数据对象有了一定的控制,在事务 T 释放它的锁之前,其它的事务不能更新此数据对象

确切的控制由封锁的类型决定,基本的封锁类型有两种:排它锁(X 锁,exclusive locks)、共享锁(S 锁,share locks)

排它锁又称写锁,对 A 加了排它锁之后,其他事务不能对 A 加 任何类型的锁(排斥读和写)

共享锁又称读锁,对 A 加了共享锁之后,其他事务只能对 A 加 S 锁,不能加 X 锁(只排斥写)

封锁协议

在运用 X 锁和 S 锁对数据对象加锁时,需要约定一些规则:封锁协议(Locking Protocol)

  • 何时申请 X 锁或 S 锁
  • 持锁时间、何时释放

对封锁方式制定不同的规则,就形成了各种不同的封锁协议。

常用的封锁协议:三级封锁协议

三级封锁协议在不同程度上解决了并发问题,为并发操作的正确调度提供一定的保证。

一级封锁协议

事务 T 在修改数据 R 之前,必须先对其加 X 锁,直到事务结束(commit/rollback)才释放。

一级封锁协议可以防止丢失修改。

如果是读数据,不需要加锁,所以它不能保证可重复读和不读“脏”数据。

数据库理论之并发控制

数据库理论之并发控制

二级封锁协议

在一级封锁协议的基础(写要加 X 锁,事务结束释放)上,增加事务 T 在读入数据 R 之前必须先对其加 S 锁,读完后即可释放 S 锁。(读要加 S 锁,读完即释放)

二级封锁协议除了可以防止丢失修改,还可以防止读脏数据

由于读完数据即释放 S 锁, 不能保证不可重复读

数据库理论之并发控制

三级封锁协议

注意事务的隔离级别,如果事务的隔离级别是重复读(即MySQL默认的隔离级别,那么二级封锁协议和三级封锁协议没有区别,因为在T1执行的时候T2不能操作)

在一级封锁协议基础上增加事务 T 在读取数据 R 之前必须先对其加 S 锁,直到事务结束后释放。

三级封锁协议除了可以防止丢失修改和读脏数据外,还防止了不可重复读。

数据库理论之并发控制

饥饿和死锁

饥饿

事务 T1 封锁了数据 R,事务 T2 又请求封锁 R,于是 T2 等待。T3 也请求封锁 R,当
T1 释放了 R 上的封锁之后,系统首先批准了 T3 的请求,T2 仍然等待。 T4 又请求封锁 R,
当 T3 释放了 R 上的封锁之后系统又批准了 T4 的请求……T2 有可能永远等待,这就是饥饿
的情形

数据库理论之并发控制

避免饥饿的方法:先来先服务

当多个事务请求封锁同一数据对象时,按请求封锁的先后次序对这些事务排队。
该数据对象上的锁一旦释放,首先批准申请队列中第一个事务获得锁。

死锁

死锁:事务 T1 封锁了数据 R1,T2 封锁了数据 R2。T1 又请求封锁 R2,因 T2 已封锁了 R2, 于是 T1 等待 T2 释放 R2 上的锁。接着 T2 又申请封锁 R1 ,因 T1 已封锁了 R1 ,T2 也只能等待 T1 释放 R1 上的锁。这样 T1 在等待 T2,而 T2 又在等待 T1 ,T1 和 T2 两个事务永远不能结束,形成死锁。

解决死锁的方法: 预防、诊断和解除

死锁的预防

产生死锁的原因是两个或多个事务都已经封锁了一些数据对象,然后又都请求对已被其他事务封锁的数据对象加锁,从而出现死等待。

预防死锁发生就是破坏产生死锁的条件

方法

  1. 一次封锁法:

要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行。

存在的问题:降低系统的并发度;难以实现精确确定封锁对象

  1. 顺序封锁法:

预先对数据对象规定一个封锁顺序,所有事务都按这个顺序实施封锁。

存在的问题:
+ 维护成本:数据库系统中的封锁对象极多,并且在不断地变化
+ 难以实现:很难实现确定每一个事务要封锁哪些对象

DBMS普通采用采用的诊断并解除死锁的方法

死锁的诊断和解除

方法:超时法和事务等待图法

超时法:如果一个事务的等待时间超过了规定的时限,就认为发生了死锁。优点是实现简单,缺点是会误判。

事务等待图法:用事务等待图动态反映所有事务的等待情况。

事务等待图是一个有向图 G=(T,U),T 为结点的集合,每个结点表示正运行的事务,U为边的集合,每条边表示事务等待的情况。若 T1 等待 T2 ,则 T1 、T2 之间划一条有向边,从 T1 指向 T2。

如果图中形成了环说明发生了死锁。

解除死锁:并发控制子系统选择一个处理死锁代价最小的事务,将其撤销。释放该事务持有的所有的锁,使其他事务能够继续运行下去。

并发调度的可串行性

可串行化调度

执行结果等价于串行调度的调度就是正确的,这样的调度称为可串行化调度。

可串行性是并发事务正确调度的准则。按这个准则规定,一个给定的并发调度,当且仅当它是可串行化的,才认为是正确调度。

例:现在有两个事务,分别包含下列操作:
+ 事务T1:读B;A=B+1;写回A
+ 事务T2:读A;B=A+1;写回B

串行调度

可串行化调度

冲突可串行化调度

冲突操作:不同的事务对同一个数据的读写和写写操作。

判断可串行化调度的充分条件:

不同事务的冲突操作和同一事务的两个操作是不能交换的。

我们用Ri(x)表示事务Ti读x,Wi(x)表示事务Ti写x。则Ri(x)和 Wj(x)不可交换,Wi(x)和Wj(x)不可交换

冲突可串行化调度:
一个调度 Sc 在保证冲突操作的次序不变的情况下,通过交换两个事务不冲突操作的次序得到另一个调度 Sc’ ,如果 Sc’ 是串行的,称调度 Sc 为冲突可串行化的调度。

数据库理论之并发控制

若一个调度是冲突可串行化,则一定是可串行化的。冲突可串行化调度是可串行化调度的充分条件而非必要条件,同样存在不满足冲突可串行化调度的可串行化调度。

两段锁协议

DBMS 的并发控制机制必须提供一定的手段来保证调度是可串行化的。目前 DBMS 普遍采用两段锁协议(TwoPhase Locking,简称 2PL)的方法来显示并发调度的可串行性。

两段锁协议是指所有事务必须分两个阶段对数据对象进行加锁和解锁:
1. 在对任何数据进行读写操作以前,首先要申请并获得对该数据的锁 。
2. 在释放一个锁之后,事务不再申请和获得其他任何的锁。

“两段” 锁的含义:事务分为两个阶段:

第一阶段是获得封锁,也称为扩展阶段
事务可以申请获得任何数据对象上的任何类型的锁,但是不能释放任何锁

第二阶段是释放封锁,也称为收缩阶段
事务可以释放任何数据对象上的任何类型的锁,但是不能再申请任何锁

数据库理论之并发控制

事务遵守两段锁协议是可串行化调度的充分条件,而不是必要条件。
若并发事务都遵守两段锁协议,则对这些事务的任何并发调度策略都是可串行化的
若并发事务的一个调度是可串行化的,不一定所有事务都符合两段锁协议

两段锁协议与防止死锁的一次封锁法:

一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行,因此一次封锁法遵守两段锁协议

但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁,因此遵守两段锁协议的事务可能发生死锁

封锁的粒度

封锁对象的大小称为封锁粒度(granularity)。

封锁的对象可以是逻辑单元(属性值、属性值集合、元组、关系、索引项、数据库),也可以是物理单元(页、物理记录)

选择封锁粒度原则:

封锁粒度和系统的并发度和并发控制的开销密切相关

  • 封锁的粒度越大,数据库所能够封锁的数据单元就越少,并发度就越低,系统开销也越小;
  • 封锁的粒度越小,并发度较高,但系统开销也就越大。

数据库理论之并发控制

多粒度封锁

如果在一个系统中同时支持多种封锁粒度供不同的事务选择,这种封锁方法称为多粒度封锁。(multiple granularity locking)

选择封锁粒度应该同时考虑封锁开销和并发度两个因素,适当选择封锁粒度以求得最优的效果。

  • 需要处理多个关系的大量元组的用户事务:以数据库为封锁单位
  • 需要处理大量元组的用户事务:以关系为封锁单元
  • 只处理少量元组的用户事务:以元组为封锁单位

多粒度树:

以树形结构来表示多级封锁粒度。根结点是整个数据库,表示最大的数据粒度,叶结点表示最小的数据粒度

数据库理论之并发控制

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

  • 显式封锁:直接加到数据对象上的封锁
  • 隐式封锁:该数据对象没有独立加锁,是由于其上级结点加锁而使该数据对象加上了锁
  • 显式封锁和隐式封锁的效果是一样的

系统检查封锁冲突时要检查显式封锁,还要检查隐式封锁

例如事务 T 要对关系 R1 加 X 锁,系统必须搜索其上级结点数据库、关系 R1,还要搜索 R1 的下级结点,即 R1 中的每一个元组 。 如果其中某一个数据对象已经加了不相容锁,则 T 必须等待。

对某个数据对象加锁,系统要检查该数据对象上有无显式封锁与之冲突;再检查其所有上级节点,看本事务的显式封锁是否与该数据对象上的隐式封锁 (由于上级节点已加的封锁造成的)冲突 ;还要检查其所有下级节点,看它们的显式封锁是否与本事务的隐式封锁(将加到下级节点的封锁)冲突 。

这种检查方法效率较低,引入一种新的锁:意向锁。有了 意向锁,DBMS 就无须逐个检查下一级节点的显式封锁。

意向锁

意向锁:如果对一个节点加意向锁,则可说明该节点的下层节点正在被加锁;对任一节点加锁时,必须先对它的上层节点加意向锁。

例如,对任一元组加锁时,必须先对它所在的数据库和关系加意向锁。

三种常用的意向锁:意向共享锁(Intent Share Lock,IS 锁);意向排它锁(Intent Exclusive Lock,IX 锁);共享意向排它锁(Share Intent Exclusive Lock ,SIX 锁)。

IS 锁

如果对一个数据对象加 IS 锁,表示它加的子节点拟加 S 锁。

例如:事务 T1 要对 R1 中某个元组加 S 锁,则要首先对关系 R1 和数据库加 IS 锁。

IX 锁

如果对一个数据对象加 IX 锁,表示它的子节点拟加 X 锁。

例如:事务 T1 要对 R1 中某个元组加 X 锁,则要首先对关系 R1 和数据库加 IX 锁。

SIX 锁

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

例如:对某个表加 SIX 锁,则表示该事务要读整个表(所以要对该表加 S 锁),同时会更新个别元组(所以要对该表加 IX 锁)。

意向锁的强度:锁的强度是指它对其他锁的排斥程度。一个事务在申请封锁时以强锁代替弱锁是安全的,反之则不然。

具有意向锁的多粒度封锁方法:
+ 申请封锁时应该按自上而下的次序进行
+ 释放封锁时则应该按自下而上的次序进行

优点:
1. 提高了系统并发度。
2. 减少了加锁和解锁的开销。

其他并发控制机制

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

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

原创文章,作者:彭晨涛,如若转载,请注明出处:https://www.codetool.top/article/%e6%95%b0%e6%8d%ae%e5%ba%93%e7%90%86%e8%ae%ba%e4%b9%8b%e5%b9%b6%e5%8f%91%e6%8e%a7%e5%88%b6/

发表评论

电子邮件地址不会被公开。