【技术分享】揭秘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余名,为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供了极具价值的交流平台。

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

 ↓↓↓ 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值