【数据库】基于封锁的数据库调度器，以及等待锁处理的优先级策略

本文主要是介绍【数据库】基于封锁的数据库调度器，以及等待锁处理的优先级策略，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

封锁调度器的体系结构

专栏内容：

手写数据库toadb
本专栏主要介绍如何从零开发，开发的步骤，以及开发过程中的涉及的原理，遇到的问题等，让大家能跟上并且可以一起开发，让每个需要的人成为参与者。
本专栏会定期更新，对应的代码也会定期更新，每个阶段的代码会打上tag，方便阶段学习。

开源贡献：

toadb开源库

个人主页：我的主页
管理社区：开源数据库
座右铭：天行健，君子以自强不息；地势坤，君子以厚德载物.

文章目录

封锁调度器的体系结构
前言
概述
封锁调度器的原则
插入锁动作的调度器结构
锁表
解锁处理
等待的锁优先级
总结
结尾

前言

随着信息技术的飞速发展，数据已经渗透到各个领域，成为现代社会最重要的资产之一。在这个大数据时代，数据库理论在数据管理、存储和处理中发挥着至关重要的作用。然而，很多读者可能对数据库理论感到困惑，不知道如何选择合适的数据库，如何设计有效的数据库结构，以及如何处理和管理大量的数据。因此，本专栏旨在为读者提供一套全面、深入的数据库理论指南，帮助他们更好地理解和应用数据库技术。

数据库理论是研究如何有效地管理、存储和检索数据的学科。在现代信息化社会中，数据量呈指数级增长，如何高效地处理和管理这些数据成为一个重要的问题。同时，随着云计算、物联网、大数据等新兴技术的不断发展，数据库理论的重要性日益凸显。

因此，本专栏的分享希望可以提高大家对数据库理论的认识和理解，对于感兴趣的朋友带来帮助。

概述

前面分享了几种封锁的机制，那么使用这些模式之一的调度器如何工作呢，本文将分享封锁调度器的一种体系结构。

封锁调度器的原则

事务本身不会申请封锁，或者不能依赖于事务做这件事。而是在读，写以及其它访问数据的动作中插入锁的动作，这是调度器的任务；
事务不释放锁，而是调度器在事务管理器告诉它事务提交或者中止时释放锁；

这样调度器就可以独立进行工作，进行调度决策。

插入锁动作的调度器结构

基于封锁的调度器，由两部分构成，它的输入来自由事务的读，写，提交，中止等请求，调度器还维护一个锁表。
在这里插入图片描述

事务请求的动作，通常通过调度器传送并在数据库上执行，但是在某些情况下，事务等待一些锁而被推迟。
调度器的两部分分别执行以下动作：

第一部分接受事务产生的请求流，并在所有数据库访问操作如读，写，增量，更新等前面插入对应的锁动作。不管调度器使用的是什么样的封锁模式，调度器的第一部分都将从中选择适当的封锁方式；
第二部分接收第一部分传来的封锁和数据库元素访问动作序列，并正确的执行它们中的每一个。如果接收到一个封锁或数据库访问请求，那么它要决定提出请求的事务T是否由于某个锁不能被获得，因而需要被推迟。
如果是的话，这个动作将被推迟，并被加入到一个最终必须为事务T执行的动作列表中，直到条件允许时再执行；
如果不是，那么就不会推迟，前面所申请的锁已经被授予，动作将送到数据库上执行。
当事务T提交或中止时，事务管理器通知第一部分，第一部分将释放T持有的所有的锁；同时，如果有事务正在等待这些锁，第一部分将通知第二部分，执行那些被推迟的动作；
当第二部分被告知某个数据库元素上的锁可以获得时，它决定接下来能获取锁的一个或多个事务，并尽可能多的执行这些事务被推迟的动作，直到它们完成或到达另一个不能被授予的锁。

锁表

锁表是将数据库元素与有关该元素的封锁信息联系起来的一个表。这个表可以用一个hash表来这现，使用数据库元素地址作为散列码。
没有被封锁的元素不会出现在锁表中，所以它的大小与被封锁的元素数目成正比，而不是整个数据库的大小。

锁表通常不是占用查询执行和日志的缓冲区，而是数据库的组成部分，它由操作系统为它分配空间。

锁表的每一项，由以下主要信息构成：

组模式，概括事务申请数据库元素A上的一个新锁时，所面临的最苛刻条件。当收到封锁请求时，并不是将它与其它事务持有的锁一个个比较，而是可以通过只比较请求与组模式，来简化授予，拒绝的决策。
比如
a) S表示被持有共享锁，那么只有共享锁的请求可以被授予；
b) U表示当前元素有一个更新锁，而且可能有一个或多个共享锁；
c) X表示有一个排它锁已经有事务持有，此时肯定没有其它锁；
等待位；表示是否有事务在等待；如果为真时，至少有一个事务在等待，等待列表不为空；
一个列表，描述所有在数据库元素A上当前持有锁，或者等待A上的锁的那些事务。

解锁处理

上面锁表描述中体现了加锁的过程，那么解锁如何处理呢？

假设事务T解锁A，那么有以下几种情况：

如果T持有的锁与组模式不同，比如持有S锁，而组模式为U，则不需要改变组模式；
如果与组模式相同，那么就不得不检查整个列表，找到新的组模式；
新的组模式只能是S，因为只有一个更新锁或者排它锁。

然后再处理等待的事务，对它们申请的锁存在一个优先级策略。

等待的锁优先级

当需要授予的申请锁列表中有一个或多个锁时，有几种不同的方法，它们各有优点：

先来先服务；同意等待时间最长的封锁请求；这种策略保证不会饿死，即一个事务永远在等待锁。
共享锁优先；首先授予所有等待的共享锁。如果有等待的更新锁，则授予一个更新锁；只有没有其它锁等待时，才授予排它锁。这一策略在读多写少时，可以处理更多的事务，允许等待U或X的事务饿死；
升级优先；如果有一个U锁的事务等待将其升到的X锁，则首先授予该锁。否则，采取前面两种之一的策略。