多种锁模式的封锁系统

​专栏内容：

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

​开源贡献：

• toadb开源库

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

前言

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

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

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

概述

对于封锁模式的调度器，如何只用一种锁模式，虽然简单，但会存在这样的情况，当有两个事务对同一数据库元素分别进行读和写的动作时，此时它们是冲突的，只能串行进行；而当两个事务对同一数据库元素分别进行读操作时，也需要串行操作，这就有点说不过去了。

因此，在本文中将介绍多种锁模式，这更贴近实际的数据库使用，以及多种锁模式之间关系的规范方法。

共享锁与排它锁

对数据库元素的读，我们可以同时加锁，而对于写的操作，需要更加严格的锁，因为它既可以阻止写，也可以阻止读，这就是共享锁和排它锁模式的调度器。

• 共享锁，可以多个事务同时获得共享锁，在加锁期间，只能进行读操作，不能进行写操作；当然读操作时，更倾向于加共享锁；
• 排它锁，只能有一个事务加锁，在加锁期间，可以进行读操作，也可以进行写操作；而其它事务既不能加共享锁，也不能加排它锁。

当然共享锁和排它锁模式下，也是需要符合两阶段锁条件，同时满足事务一致性和调度一致性。

一个事务可能先获得到某个数据库元素的共享锁，之后又申请了该数据库元素的排它锁，如果此时没有冲突产生，这是可以的。在可预测的情况下，可以只申请排它锁，往往大多数情况下，我们在开始时，无法预测，所以会有这种情况的发生。

• 调度举例

事务T1	事务T2
slock(A); read(A);
	slock(A); read(A);
	slock(B); read(B);
xlock(B); 被拒绝
	unlock(A);unlock(B);
xlock(B); write(B);
unlock(A);unlock(B);

相容性矩阵

存在几种锁模式时，当一个数据库元素已经有一个锁时，如果再来锁请求时，调度器需要一种策略，来判断是否可以继续加锁。
这里有一种方式，叫做相容性矩阵，它是一种简单的记录锁与申请锁之间的处理策略。

它由一个二维表来表示，列表是已经持有的锁，行表示正在申请的锁，它们交叉的地方表示是否继续可以加锁的策略。

拿共享锁和排它锁来举例，它的相容性矩阵如下：

		申请的锁
		共享锁	排它锁
持有的锁	共享锁	是	否
	排它锁	否	否

只有共享锁是可以被多个事务同时持有，其它都是不可以。

其它锁模式

对于共享锁还可以有锁升级，升级到排它锁，这样就可以只持有一个锁；但是这也会产生死锁的风险。

这里可以引入第三种锁模式，设置另外的一种锁模式，更新锁，它可以由共享锁升级而来，但是它比共享锁严格，只有它可以升级到排它锁，同时与其它共享锁和排它锁请求冲突；

另外还有一种很有用的锁模式，增量锁；有这样一类操作，只对数据库元素递增或递减，此时就可以加增量锁。增量操作有一个特性，是可以交换的，如果两个事务都对一个数据库元素递增，谁先谁后结果都是一样的。这样增量锁是可以同时持有多个，但是它与共享锁和排它锁又是冲突的。

总结

通过本文，对于多种锁模式的介绍，真实数据库的调度器封锁机制的了解更加深入。

结尾

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

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