集群功能是数据库产品高可用性的重要一环，集群架构是保障业务连续性的核心架构，体现着数据产品的高可用性和技术水准。但在业界集群架构有多种方案和技术，其中最具稳定性、最能够保障业务连续性的架构当属于RAC集群，即Real Application Cluster。RAC集群特点是多个数据库节点共享存储，节点多活，可同时处理业务请求，具有负载均衡和故障转移两大特性，以此为系统提供业务连续性和高性能保障，经过多年电信、金融等关键行业的核心业务检验，RAC集群技术已经成为业界数据库集群的首选方案。

目前，甲骨文的Oracle数据库和浪潮的K-DB数据库是仅有的两个支持RAC集群架构的数据库产品。 RAC需要支持多个节点的并行读写操作，节点之间协同工作的复杂度远超出其他集群方案，这也是RAC集群技术难以突破的重要原因。其中，RAC集群技术的重中之重是锁机制的管理，也是实现RAC架构的核心技术。

K-DB数据库突破了锁机制管理的技术难点，实现了真正的RAC集群。

锁与数据库的基本架构等紧密结合，涉及到内存管理、请求调度等其他相关技术。所以，从今天起，我们将发布系列的文章，介绍K-DB演进、K-DB基本架构、锁机制的构成、及锁的运行和测试数据等各个方面，让您对浪潮锁机制管理有全面的了解。

K-DB与锁技术的进化

锁技术是伴随着K-DB数据库的发展而不断进化的，在谈锁技术之前，先简单回顾一下K-DB的历史。

K-DB第一代产品可以满足用户的基本需求，具备行级锁、MVCC基于在线重做日志及增量日志的备份与恢复等功能，但不足也十分明显——解决不了扩展和单点故障两大问题。

第二代产品基于日志同步的 Active-Standby容灾架构，将在主库中的操作产生的redo日志，传送到备库中。备库以read only 方式打开，供用户做查询服务，帮助主库降低一定的负载。当主库发生故障时，备库以normal方式打开，给用户进行正常的读写服务，主库和备库的切换时间不长，数据库经过短暂的停顿后，就可以继续对外服务，满足了灾备需求。

现在的K-DB是第三代产品，实现了RAC技术，具备负载均衡能力，解决了扩展性和单点故障问题。从此，浪潮K-DB具备了RAC架构，可实现真正的共享存储、多活节点的集群方案。浪潮将该技术称为“K-RAC”。

从单机架构到Active-Standby架构，从Active-Standby架构到RAC架构，RAC架构为技术实现提出了挑战，多个节点共享同一存储设备，为保障数据一致性，避免节点之间争抢数据的情况发生，锁机制管理技术使这一技术难题得以完美解决。

K-DB架构演变图