【IT168 资讯】2016年5月12日-14日，第七届中国数据库技术大会(DTCC 2016)在北京国际会议中心拉开帷幕。今年的大会首次设立了“数据库内核技术”专场，着重突出“内核的实现技术”，以内核技术为主，围绕内核功能、性能、可靠性、可用性和易用性，介绍数据库内核技术的原理、应用与发展。

　　在这场“数据库内核技术”专场，浪潮数据库架构师霍俊路为大家分享了《数据库集群下的锁机制管理》的精彩演讲，详细介绍了数据库集群锁机制的原理和实现方式，以及浪潮K-DB集群的架构和工作原理。

▲浪潮数据库架构师 霍俊路

　　什么是K-DB 数据库集群?

　　早期的K-DB产品，首先满足的是可用的基本标准，典型的例如关系型数据库、行存数据、行级锁等。而随着稳定性的需求增加，基于日志同步的 Active-Standby容灾架构营运而生，它的特点就是在主库中操作产生的redo日志，传送到备库中，备库可以供用户做一个查询服务，当主库发生故障时，备库可以以normal方式打开，给用户进行正常的读写服务，这个架构解决了灾备方案的需求。

　　经过这几年的努力，业界公认的最成熟的高可用解决方案 – RAC技术在 K-DB数据库中得以实现。它同时具备负载均衡和解决单点故障的特点，由此 K-DB具备了基本的高可用、高性能架构。

▲K-DB RAC物理架构 

　　K-DB数据库的集群是基于共享磁盘的集群技术。数据库的单个节点上存放的是数据库的执行文件和参数配置文件等;在共享磁盘上，存放共享数据文件、日志文件和控制文件等必备文件。各个节点之间内部的通信由内网连接，数据库对外的服务则经过外网对外服务，内外网之间互不影响，最大限度保证了用户的性能。

　　K-DB数据库是一个多活集群，每一个集群节点可以同时读写。这种集群方案与市场上一些基于HA或者standby的方案有着本质的区别，要实现这个技术，依赖的是浪潮数据库架构师霍俊路所要谈到的锁管理机制。

　　高效锁管理机制的实现方式

　　数据库的缓存融合技术是K-DB 数据库集群模的一个复杂功能。由于一个数据块在多个节点中会被共同的读写，就需要解决同一对象在不同节点之间的读读、读写、写写等并发访问的争用。

　　而解决并发冲突这个问题，必然需要锁信息。RAC集群架构中的锁机制难题就在于：锁存放在什么地方比较合适?节点访问是否快捷?锁中需要记录哪些信息，又该怎么维护这个锁信息?

　　霍俊路认为，锁是针对数据块的，所以锁中的信息需要记录数据块的物理地址。在集群环境下，会存在多个实例，需要记录下具体的实例id，才能知道该数据块正在被哪个节点访问。节点在访问对象时，需要根据读写需求，申请不同的锁模式。

　　K-DB数据库内含cluster wait-lock service全局锁服务，这个服务用于维护GLD和处理用户的锁请求。当一个instacne 向数据块的master 节点申请锁时，master 节点通过cluster wait-lock service查看当前锁的使用情况，GLD 会记录下锁信息S，之后第三个节点想要修改这个数据块，就需要申请X 。

　　如果在运行的过程中，发生了故障，K-DB 会采取另一种方式去进行处理。在进行恢复的时候，从最近一次的checkpoint开始恢复，需要读取宕机节点的redo日志，Redo日志中对于该数据块的SCN 小于PI块，这部分日志无需恢复，直到SCN 大于PI块的SCN开始。同时在恢复的时候，K-DB 之前的恢复模式是由单节点进行恢复， K-DB支持在多个节点中同时执行恢复操作，大幅缩短恢复大量数据的时间，整体提升了恢复的速度。

　　K-DB 向后的技术演进

　　在原有的解决方案中，K-DB对于存储主要是支持裸设备和第三方的集群文件系统。而在最新版本的K-DB中，K-DB 支持了存储虚拟化技术，实现了自己的集群文件系统。

　　KAS(K-DB Active Storage)是优化于K-DB内的存储虚拟化技术，通过Volume Manager、Mirroring、Striping、Rebalancing功能保障性能和稳定性。它将IO平均分配给多个磁盘，达到负载均衡;通过写入多份数据，保障当某份数据出现故障后，整个数据库依然可用。

　　K-DB与K1结合还可针对数据库架构现状进行优化，对企业级的数据库进行数据分析处理，管理高效存储资源与优化操作系统，针对不同的计算资源，灵活地进行扩展，专为关键应用而生。

▲更多大会资讯，请查看大会专题：http://www.it168.com/redian/16DTCC/