【技术分享】揭秘K-DB数据库集群下的锁管理机制

本文整理自DTCC2016主题演讲内容，录音整理及文字编辑IT168@杨璐。如需转载，请先联系本公众号获取授权！

演讲嘉宾

霍俊路

浪潮高级软件工程师

K-DB数据库高级技术服务工程师。多年一线实施测试经验，参与数百个数据库项目的集成测试。 清晰掌握 K-DB 数据库的内部原理和逻辑架构，擅长数据库的性能优化和故障诊断。快速定位和解决用户在使用 K-DB 的过程中的任何问题。

分享内容

很高兴有这么一个机会，能跟这么多朋友在一起，来聊聊技术，做一个计划的分享。希望我的讲解能够给大家带来一定的收获。

 

讲解分为三个部分：第一，主要是知识；第二，是针对主要知识一个现场展示；第三，关于K1，还有解决方案。

 

传统数据库架构的发展历程

我们数据库发展一共分为三个阶段。第一阶段，主要是一个单机的数据库，特点是基于MACC架构，闪存，闪回等，可以给用户解决一定的问题。但是架构的缺陷也非常明显。原因第一，它解决不了用户的应用扩展性的问题。第二，解决不了用户的单点故障的问题。

 

第二个阶段，就是说主库所有的操作产生的日志，都会传送到备库，在备库层面做一个恢复，这样主库宕掉以后，备库依然可以起来进行服务。那么同时在这个传输的过程中，备库是可以只读模式打开的，可以分享一部分，就是说主库的压力。

 

经过很长时间的一个研发过程和积累，我们数据库进入到第三个阶段，就是说集群阶段。那么集群阶段，它具有什么特点呢？就是它要比前面这几个增加了两个非常明显的特征。第一，负载均衡，第二，就是故障恢复。所谓负载均衡，就是说多个点是可以一起进行的，故障恢复，任何一个节点宕掉以后，都不会影响到用户的继续使用。

 

这就是要讲的一个核心。KB的集群，它是基于一个共享，由多个节点共享磁盘，在共享磁盘上有着数据库必须要的软件，数据软件等等，除此之外，这里面显示的叫做集群控制软件，这个文件的用处在什么呢？就是说它是作为集群件的一个注册表的一个信息。然后我们这个集群，各个节点之间，其实它是由两条网络进行搭建的，分别是外网还有内网。外网是处理用户的需求的，也就是所有的用户的请求，统一是从外往这边进入的。内网是集群节点之间的一个通信的一条通道。

 

多活集群，就是说它的每一个节点都是可读可写，可以同时读写。在我们数据库的集群中，我们刚才说过，我们有一条内网，它是用于处理数据在节点之间的传输。在多个节点中，如果我想要获取的这个数据块已经在别的节点中了，那么我不需要将对应的数据块刷回到磁盘，我再从磁盘进行读取，而我的这种处理方式是直接通过内网将这个数据块传输过来。这样就减少一个IO的消耗。这种技术，在我们数据库称为一种缓存的融合技术。也就是说，多个节点的这种内存，我们可以把它当成统一来处理。

 

实现缓存融合需解决问题

 

第一，  多个节点有可能会同时共同读取数据块。

第二，  节点和节点之间，然后有读有写，同一个数据块。

第三，  就是写和读。

第四，写和写。我们需要处理多个节点的对于同一个数据块的稳定。在数据库中，对于同一个数据块的，就是说对同一个对象之间处理，统一的方案，这个锁在数据库当中是普遍来解决并发的，我们在单节点当中也是经常看到的。如何把这个锁在多个节点，在集群环境下设计出来，那么来解决这样的问题呢？我们需要考虑哪些因素呢？我自己做了一个总结，主要是从三个方面，第一，就是说这个锁放在什么地方？因为它是一个多节点的环境，我这个锁放在哪个地方是很重要的一个东西，那么我需要多个节点都能感测到。这个锁里面会存放哪些信息，我们知道，在单节点当中，大部分主要就是先放一个锁，申请一个模式就OK了，在集群一下，这样够不够呢？ 

主要数据库就通过这三个模块进行处理。刚说到GLD，它是一部分内存，那么它究竟是什么样的内存呢？放在什么地方呢？可能通过这个图大家能够找到答案。

从这个图里面，每一个节点，在它的共享内存当中，所有的内存，然后就放在一起，组成在一起，就是构成了整个的GLD，也就是说，每一个节点，它都是GLD的一部分，所有的节点放在一起，内存这个信息，大家可能还有一些疑惑，疑惑在哪儿呢？它怎么跟数据连在一块的，是说任何一个数据块，它的锁的这个信息，我们都会放在它的master节点中。那么这节点和这个数据块之间是怎么联系起来的呢？其实是中间有一个算法，就是说任何一个节点它都会映射到这个节点，这是一个三节点的集群，是影射的一个关系。

 

在集群中，它的并发，我们的对象是数据块，那么我们需要在master节点中需要记录什么呢？第一，这个数据块它的地址在哪儿，这是一定要的，这是第一个信息。第二个信息，这个数据块它是在一个多节点并发访问的一个环境下，那么谁访问谁正在占用，这个信息也是需要的。也就是说，我们需要记录当前正在访问的，正在使用的实例ID(Instance id)这是两个。第三，我们对于一个锁的申请，那么在不同的状态下它是不一样的，如果我们是读写的数据块，我们一般申请一个共享锁，如果我们要想写这个数据块进行一个改写，我们会直接申请一个，这个是在单节点方面适用的，同样在这里我们必然也会需要。就是说我们的模式，我们是想申请。这个锁，一旦被申请到了，这个数据块的状态它必然会不一样。那么这个数据块的状态，我们大家在单节点当中经常遇到，就是CR,CURRET 等等，那么这些在集群的环境下多多少少还不太一样，在这里面它多了一个状态，叫做 Past Imange,这个状态在单节点当中是永远看不到的，这个状态是在集群中有。

 

第三个问题是怎么来维护。按照逻辑梳理，读写数据块，找master节点，它借助锁模块。就是说当我们需要申请一个锁的时候，它都会有一个记录。当新的用户申请，然后也在申请这个锁的时候，那么这个锁，新的用户能否马上分配到，打一个比方，A节点正在读这个数据块，B节点也想要读这个数据块，OK了，这两个读的时候，都是需要申请X的，这个时候既然是兼容的，我们就可以直接分配。把这个锁直接分配了，分配在这个链条里面。那么用户有可能在想，如果不兼容怎么办？再来一个用户，他想写这个块，他跟原来不一样，不兼容，他申请一个X，那怎么办？让他等待，这个时候他的另一个就起到了作用，就是说它会把相关锁的结构，该申请的还是申请，但是要等待它状态的一个变化。比如说等到A节点、B节点，刚才那两个节点读完了，锁释放了，或者是其他状态，就可以直接转过去。好处就是先把结构申请了，然后只做一个状态转换，处理效率更快。

 

理论知识后面的几组场景

 

第一个场景，想表达的事件。

第二个场景，C节点，怎样申请对应数据块的排他锁。

第三个场景，节点宕机怎么办？

 

如果就是说一个节点宕机了以后，怎样处理？我们原来的处理方式，就是由一个节点进行读取，然后进行恢复。那么我们现在做的，多个节点并行的恢复。这个我们认为还是比较先进的一个技术。就是说当某一个节点宕机以后，它由多个节点并行恢复，那么它的恢复的时间是很快的。多节点的并行恢复要比单节点的恢复，它的性能要多一倍。

 

关于KPS技术

 

浪潮主要是做硬件，做服务器的。K1小机是自主研发的一款小机，我们在K1的基础上加上了KPB，推出一体化的优化方案，因为我们在上面做了很多很多的优化。不管是从硬件、软件，包括数据库的参数，操作系统的参数，CPU指令集，甚至非常非常重要的代码编辑，这个地方我们都做了深度的优化。在整个我们实验的环境中，测试了很多很多人，最终我们把性能提升的非常非常好，在我们原有的基础上提升了大约1倍。

 

总结：

 

由K-DB和天梭K1搭建的数据处理系统性能接近Oracle，很多场景下，甚至有所超越。从技术层面看，这源于多进程多线程、多版本并发控制、存储虚拟化等众多领先的技术。K-DB拥有高可用集群KRAC、异地容灾K-SC等高级功能。当数据库集群节点出现故障或者人为关机时， K-DB可以多节点同时执行恢复操作，大幅缩短系统恢复的时间。

总之，K1和KDB结合在一起，浪潮整合了从服务器到操作系统、存储、数据库，再到应用，整体一体化的优化方案，也可以看出浪潮欲服务更多关键业务的信心和决心！

关于DTCC

中国数据库技术大会（DTCC）是目前国内数据库与大数据领域最大规模的技术盛宴，于每年春季召开，迄今已成功举办了七届。大会云集了国内外顶尖专家，共同探讨MySQL、NoSQL、Oracle、缓存技术、云端数据库、智能数据平台、大数据安全、数据治理、大数据和开源、大数据创业、大数据深度学习等领域的前瞻性热点话题与技术，吸引IT人士参会5000余名，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供了极具价值的交流平台。

关注大会官方公众号，获取更多详情！

 ↓↓↓