5-1. 锁的概念及封锁的原理在线视频

同学们好，上一节课我们讲了关于并发调度的基本概念

我们知道了如果让事务来并发执行的话，最好能够制造出冲突可串行化调度

但是冲突可串行化调度如何去制作呢

今天我们就来讲传统关系型数据库他们采用了最为朴素的一种方式

基于锁的并发控制协议

这一部分我们要介绍四个内容

第一是锁的概念及封锁的基本原理

第二是介绍两阶段锁协议

第三部分，多粒度锁及意向锁

第四部分，我们来介绍死锁的处理

首先我们来看第一部分，锁的概念及封锁的原理

锁的概念实际上大家并不陌生

在操作系统原理这门课里面大家实际上已经接触过

那个时候叫做信号量，锁本身就和信号量是一样，是一种标志

就说我们数据库里面多个事务去访问数，共同资源的时候的一种标志

这种标志可以标志一个事务对数据进行读操作，对事务进行写操作

由此，锁的基本模式也分为读锁和写锁

读锁，我们把它叫做共享锁，Shared，也叫S锁

它允许事务进行读操作

也就是说当一个数据项想对一个事务进行读的时候

它必须在这个数据项上加一个共享锁，也叫读锁

锁的另一种模式叫做排它锁，Exclusive，X锁

它允许事务在数据项中进行写操作

也就是说当我们要更新数据项的时候

我们首先要对数据项进行排它锁的标志

这样的话，我们锁的调度策略基本上就出来了

也就是说，当一个事务需要对数据进行读的时候，我们就加共享锁

一个数据可以加若干个共享锁，因为读并不改变数据

所以有多个事务都读数据的话，这个数据上可以加若干个共享锁

但是由于写数据会更新数据库

所以一个数据上面只能加一个排它锁

也就是说当一个事务在一个数据上加了一个排它锁之后

如果它不解除，其他事务是不允许对数据加任何锁的

这样的话就引出了锁的一个相容矩阵

这两种锁模式，S锁和X锁在什么情况下是相容的呢

只有S锁和S锁是相容的，而X锁和X锁，以及两类锁之间都是不相容的

我们用T来表示相容，F来表示不相容

我们可以举个例子来说明

如果两个事务对数据项A和B进行读写操作

我们就可以先对它们进行加锁

比如，事务1要对A和B进行写操作，那么它首先要申请A和B的写锁

我们用Lock-X（）表示它要对数据项进行加锁

加锁之后才能够读数据、对它进行更改，进行写

写完之后再对它进行解锁，我们用UnLock( )来进行解锁操作

某一个事务T2要对A、B进行读操作，我们就给它加S锁，Lock-S( )

读完之后，我们对它进行解锁操作

我们现在看，T1和T2都对事务在同一时间段内进行操作

如果我们加了锁之后，显然由于T1先加了锁，T2后加的锁

所以再根据锁的相容矩阵，那么我们就发现T1、T2加锁之后

我们发现T2如果想对A、B进行读的话，它必须要等到T1解锁之后才行

这就强制性的使得T1和T2在对数据项A和B的操作上，执行了串行操作

强制性地让它们进行了串行操作

那么这就是加锁，通过锁来实现并发控制

但是加锁也不能任意的加，或者说不加控制的加

就是说，我想什么时候加就去加，想什么时候解就去解

也是不可以的，如果不正确地加锁会产生这样一些问题

首先，第一个会产生一些不正确的结果

我们用左边这个例子来说

比如说，A和B的初始值，B是200，A是100

T1这个事务对B进行一个减的操作，比如减50

那么它对A进行加50的操作

显然事务T1执行完了之后，实际上A和B的和还是不变的

如果事务T2再去读A和B的话

那么显然它的值，如果T1没有对它进行修改的话

T2读出来的值应该是300

当T1对它进行修改之后，T2读出来的值还应该是300

那也就是说事务T1和T2如果并发执行的话

结果仍然是T2读出来的值仍然是300

但是在我们这个例子里面，如果我采用这样一种加锁方式

比如说，T1先对B进行了加锁

然后对它进行了操作，操作完之后马上进行解锁

但在这个之后T2马上就要对它进行读

读完之后它要进行一个加和处理

接下来，T1再对A进行读操作，读进来之后再进行写修改

这样一种加锁，从理论上来说应该是没有任何问题的

但实际上由于没有进行控制，所以T2读出来的数据已经不是300了

它是什么？少了50

所以这样就说明，我们随意的进行加锁

虽然可以控制两个数据源对数据进行操作的一种冲突

但是显然它产生了一种不正确的结果，这是一个

另外一个就是，如果一些不正确的加锁还会产生死锁的问题

比如这个例子之中，T1先去读了B，再去读了A

T2也是一样，它要读A读B，然后进行显示

假设像我们这个时间轴，T1先读B，然后再去读A

先对B进行了加锁，那么T2先读A，所以它对A进行加锁

接下来两个事务向下执行，T1对A操作完了之后，还要对B进行加锁

但是这个时候它并没有解锁

所以T2如果再去读B的话，它就要等待T1去释放B上的锁

实际上T1要对A进行加锁，发现锁已经被T2持有

这个时候两个事务都不能向下执行

它们处于一个相互等待的状态，这种状态就叫做死锁的状态

进入了死锁的状态，事务是不能够向下执行的

机器就像死机一样，等在那里，不再进行任何的处理

这个是非常可怕的

还有一种现象叫做饿死现象

这种饿死现象就是说，某一种事务它永远也得不到锁

比如这个例子，有三个事务T1、T2、T3

如果T1加的是共享锁对A，它加完共享锁之后要对A进行处理

这个时候T2要想加写锁的话，它是加不上的，它必须等待

但是在它等待的过程中，如果有其他的事务要想读A的话

还能加共享锁，显然它是可以加得到的

这个情况下，如果T3执行完了之后

还有T4、T5都要加共享锁的话，显然T2永远也得不到锁

T2就会被饿死，这就是饿死的现象

当然对于饿死的现象我们可以采用其他的方式来进行解决

比如说，我们可以对长期等待的事务赋予一个优先权

也就是给它一个优先级别

它目前所要加的数据项上有了另外一把锁

当它要加锁的时候不允许其他事务再加另外一种锁，这样是可以的

因此，我们需要对事务的加锁进行控制

只有进行控制才能够达到我们说的这种理想的情况

比如说，我可以承载出正确的冲突可串行化并发调度