【数据库】数据库基于封锁机制的调度器，使冲突可串行化，保障事务和调度一致性

本文主要是介绍【数据库】数据库基于封锁机制的调度器，使冲突可串行化，保障事务和调度一致性，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

封锁使可串行化

​专栏内容：

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

​开源贡献：

• toadb开源库

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

前言

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

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

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

概述

数据库并发控制，最常用的调度器结构，就是在数据库访问元素上加锁，防止非串行化的行为。

简单来讲，就是事务访问某个元素，先获取它的锁，避免其它事务的非串行化访问。

本文就来介绍这种通过封锁的模式，让调度器产生可串行化动作序列，以及它存在的问题。

锁

在并发编程中，我们会接触到很多类型的系统变量，可以让我们对某一代码区域串行化执行，同样数据库中也会使用这些系统变量来实现数据库中的锁。

使得被锁保护的数据库元素，只能以串行的方式访问，在访问之前获取锁，如果获取不同，只能等待或者中止，获取到锁的就可以进行操作，操作完后释放锁。
在实际的数据库中，会有多种锁的类型，这在以后会进行详细介绍。

对于调度器使用锁时，必须在两种结构上都要保持正确：

• 事务结构，

一是只有在加锁后，释放锁前，才能进行读写操作；
二是如果加锁了某个元素，那么使用后必须释放锁；

• 调度结构

同一元素只能被一个事务加锁；而另一尝试加锁事务，要么中止，要么等待；这在不同的数据库实现不一样。

封锁调度器

下图展示了一个封锁的调度器模型架构。

我们来用一个简单的锁模型介绍一下，假如对于每个数据库元素我们只有一种锁，必须获取锁后才能进行读写，使用完后释放锁。

为了调度器进行决策，调度器有一个锁表，记录了每个数据库元元系的锁状态，如果其上有锁，说明有事务正在使用该数据库元素，其它事务不能访问。

• 举例如下：

事务T1	事务T2	数据A	数据B
		25	25
lock(A); read(A);
A = A + 100
write(A); unlock(A);		125
	lock(A), read(A)
	A = A*2
	write(A);unlock(A)	250
	lock(B); read(B);
	B = B*2
	write(B);unlock(B);		50
lock(B); read(B);
B = B + 100
write(B);unlock(B);			150

通过这个例子，我们看到一个有趣的现象，虽然调度器已经使事务访问时加了锁，事务对相同的数据库元素也是串行访问，但是最终的调度是不可串行化的，最后状态是不一致的。

说明只是简单封锁，例中的结果不是冲突可串行化的结果。

两阶段封锁

这里介绍一种加锁的条件，叫做两阶段封锁(two-phase locking, 2PL),在这种令人吃惊的条件下，可以保证事务的调度是冲突可串性化的。

原理

两阶段封锁，加解锁需要满足这样的条件：

• 在每个事务中，所有的封锁请求必须在所有解锁请求之前；

这里就是将事务分为了两个阶段，

• 第一阶段是封锁阶段，在这个阶段，对需要访问的数据库元素依次加锁；
• 第二阶段是解锁阶段，这个阶段里，不能再有封锁请求；依次释放锁的过程；

两阶段封锁，像事务一致性一样，对事务中动作顺序进行了限制，符合这一条件的事务，叫做两阶段封锁事务。

• 举例

那我们再来看上面的例子，将它按2PL进行调度之后：

事务T1	事务T2	数据A	数据B
		25	25
lock(A); read(A);
A = A + 100
write(A); lock(B); unlock(A);		125
	lock(A), read(A)
	A = A*2
	write(A);	250
	lock(B); 被拒绝
read(B);
B = B + 100
write(B);unlock(B);			125
	lock(B); unlock(A); read(B);
	B = B*2
	write(B);unlock(B);		250

经过符合2PL条件的调度后，我们可以看到最终结果是符合冲突可串行化的，也就是与两个事务串行执行一样的结果。

分析

两阶段封锁是如何发挥作用的呢？

其实我们仔细观察，就会发现，事务执行的顺序与第一次解锁的顺序是一致的，也就是事务按照解锁的顺序串行在每个数据库元素上执行，这样保证了串行执行的效果，达到了冲突可串行化。

当然严格的可以用归纳法进行证明，这里就不再详述了。

死锁

两阶段封锁虽然可以让事务调度达到冲突可串行化，但是它有一个未解的问题——死锁，也就是调度器迫使几个事务等待另一个事务持有的锁，而该事务又需要等待前几个事务持有的锁。

举例如下：

事务T1	事务T2	数据A	数据B
		25	25
lock(A); read(A);
	lock(B); read(B);
A = A + 100
	B = B*2
write(A);		125
	write(B);		50
lock(B) 被拒绝
	lock(A) 被拒绝

现在，两个事务都不能继续向下进行，都将永远等待，这将在后面的介绍中继续分享，会对这种问题进行解决。

总结

通过封锁的模式，可以让调度器产生冲突可串行化的调度，但是对于每个事务中涉及多个数据库元素的情况时，又存在死锁的风险。

结尾

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

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

这篇关于【数据库】数据库基于封锁机制的调度器，使冲突可串行化，保障事务和调度一致性的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---