封锁调度器的体系结构

专栏内容

  • 手写数据库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
如有错误或者疏漏欢迎指出,互相学习。