数据库锁专门协调不同进程间的资源冲突，系统资源冲突的类型、频率、复杂度等决定了锁技术的发展，而资源冲突的情况又与数据库系统的基本架构高度相关。例如，在standby架构下，虽然以多节点集群运行，但是实际各个节点轮换对资源进行操作，资源冲突更多的体现为节点内进程或者是线程之间的冲突，相对简单，与之相应的锁机制也就简单。而K-RAC同时支持多个节点共同操作，由此带来的资源冲突问题远比其他架构更为复杂。因而，本文将先介绍K-DB的基本架构，由此引出K-DB锁的存储管理、构成以及锁同数据库映射关系的建立等。
基于共享磁盘的K-RAC
K-RAC是浪潮基于共享存储的集群技术。数据库实例节点存放数据库的执行文件和参数配置文件等。共享数据文件，日志文件，控制文件这些数据库的必备文件，此外还有集群控制文件（这点是区别于单机数据库），都存放在共享磁盘上。
K-DB集群物理架构图
全局缓存融合
在RAC集群中，不仅磁盘共享，从逻辑上看，各个节点之间的内存也可看做是共享的。比如，当一个节点即将读取的数据已经在另一个节点的内存中时，该节点可以从另一个节点的内存中获取数据，避免了从磁盘中读取，减少I/O的消耗。这个技术就是数据库的缓存融合，这是K-DB 数据库RAC集群的技术核心和技术难点。
K-DB锁机制的构成
在设计锁机制的时候，应先设计好以下3个问题：
- Where。锁信息存放在什么地方更加合适，也就是当节点之间发生争用数据块的时候，都可以很快捷的访问到？
- What。锁中需要记录哪些信息？
- How。怎样来维护这个锁信息？
下图是K-DB共享存储集群的进程架构图。橙色的部分表示处理缓存融合的主要模块。
K-DB 进程架构图
其中，
GLD全局锁目录存放着数据库用户锁信息；
Cluster Wait-lock Service 集群等待锁服务是用于提供全局锁管理的；
Cluster Cache Control集群数据缓存控制器，用于处理数据库中数据块的传输。
上述三个模块一起协调处理，实现了数据库集群的锁机制管理。
K-DB锁与相关的数据管理
K-DB在每一个节点都会划分出一部分内存与其他节点共享，组成share pool，GLD就是位于每一个节点的share pool 中，所有节点的GLD 汇总在一起构成完整的GLD。
介绍完了GLD之后，下一步就是让锁和相应的数据库建立可逆映射关系，这种映射关系的建立是通过为数据库指定master节点的方式实现的。每一个数据块会根据它的block address计算得出hash值，来对应一个master节点，在master 节点中记录该数据块的锁信息。
在如下图中3个节点的集群中，A,B,C三个节点中每一个节点的内存区域，都是GLD的一部分，3个内存区域组成在一起，构成了GLD所有的数据库，通过hash算法，对应的master节点平均分配到3个节点中。
原文发布时间为： 2016年7月29日
本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。
