封锁使可串行化
专栏内容：
- 手写数据库toadb
本专栏主要介绍如何从零开发，开发的步骤，以及开发过程中的涉及的原理，遇到的问题等，让大家能跟上并且可以一起开发，让每个需要的人成为参与者。
本专栏会定期更新，对应的代码也会定期更新，每个阶段的代码会打上tag，方便阶段学习。
开源贡献：
前言
随着信息技术的飞速发展，数据已经渗透到各个领域，成为现代社会最重要的资产之一。在这个大数据时代，数据库理论在数据管理、存储和处理中发挥着至关重要的作用。然而，很多读者可能对数据库理论感到困惑，不知道如何选择合适的数据库，如何设计有效的数据库结构，以及如何处理和管理大量的数据。因此，本专栏旨在为读者提供一套全面、深入的数据库理论指南，帮助他们更好地理解和应用数据库技术。
数据库理论是研究如何有效地管理、存储和检索数据的学科。在现代信息化社会中，数据量呈指数级增长，如何高效地处理和管理这些数据成为一个重要的问题。同时，随着云计算、物联网、大数据等新兴技术的不断发展，数据库理论的重要性日益凸显。
因此，本专栏的分享希望可以提高大家对数据库理论的认识和理解，对于感兴趣的朋友带来帮助。
概述
数据库并发控制，最常用的调度器结构，就是在数据库访问元素上加锁，防止非串行化的行为。
简单来讲，就是事务访问某个元素，先获取它的锁，避免其它事务的非串行化访问。
本文就来介绍这种通过封锁的模式，让调度器产生可串行化动作序列，以及它存在的问题。
锁
在并发编程中，我们会接触到很多类型的系统变量，可以让我们对某一代码区域串行化执行，同样数据库中也会使用这些系统变量来实现数据库中的锁。
使得被锁保护的数据库元素，只能以串行的方式访问，在访问之前获取锁，如果获取不同，只能等待或者中止，获取到锁的就可以进行操作，操作完后释放锁。
在实际的数据库中，会有多种锁的类型，这在以后会进行详细介绍。
对于调度器使用锁时，必须在两种结构上都要保持正确：
- 事务结构，
一是只有在加锁后，释放锁前，才能进行读写操作；
二是如果加锁了某个元素，那么使用后必须释放锁；
- 调度结构
同一元素只能被一个事务加锁；而另一尝试加锁事务，要么中止，要么等待；这在不同的数据库实现不一样。
封锁调度器
下图展示了一个封锁的调度器模型架构。
我们来用一个简单的锁模型介绍一下，假如对于每个数据库元素我们只有一种锁，必须获取锁后才能进行读写，使用完后释放锁。
为了调度器进行决策，调度器有一个锁表，记录了每个数据库元元系的锁状态，如果其上有锁，说明有事务正在使用该数据库元素，其它事务不能访问。
- 举例如下：
| 事务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) 被拒绝 |
现在，两个事务都不能继续向下进行，都将永远等待，这将在后面的介绍中继续分享，会对这种问题进行解决。
总结
通过封锁的模式，可以让调度器产生冲突可串行化的调度，但是对于每个事务中涉及多个数据库元素的情况时，又存在死锁的风险。
结尾
非常感谢大家的支持，在浏览的同时别忘了留下您宝贵的评论，如果觉得值得鼓励，请点赞，收藏，我会更加努力！
作者邮箱：[email protected]
如有错误或者疏漏欢迎指出，互相学习。