封锁调度器的体系结构

​专栏内容：

• 手写数据库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锁，则首先授予该锁。否则，采取前面两种之一的策略。

总结

基于封锁的调度器，不依赖于事务来加解锁，通过锁表的记录来决策调度事务序列的执行。

结尾

非常感谢大家的支持，在浏览的同时别忘了留下您宝贵的评论，如果觉得值得鼓励，请点赞，收藏，我会更加努力！

作者邮箱：study@senllang.onaliyun.com
如有错误或者疏漏欢迎指出，互相学习。