CN111949673B - 基于Hbase存储的分布式悲观锁及其实现方法 - Google Patents

Abstract

本发明公开了一种基于Hbase存储的分布式悲观锁及其实现方法，属一种数据库悲观锁的实现方法，分布式悲观锁包括锁管理器，锁管理器用于安装在Hbase系统的RegionServer节点的Region上；锁管理器具有加锁与解锁接口，且由锁、操作事务与锁持有者构成十字链表格式，其中横向维度为当前数据行的行键，纵向维度为操作事务，纵向维度与纵向维度之间的交点为锁持有者。通过在HBase存储系统的节点Region上安装锁管理器，从而可对HBase系统的数据操作进行悲观锁加锁与解锁的操作，利用悲观锁所故有的特性，使得数据存储系统可支持更高频次的事务并发操作，可有效降低系统资源消耗；并且HBase存储系统可在廉价PC服务器上搭建起大规模结构化存储集群，从而可进行线性拓展，摆脱单机的束缚。

Description

基于Hbase存储的分布式悲观锁及其实现方法

技术领域

本发明涉及一种数据库悲观锁的实现方法，更具体的说，本发明主要涉及一种基于Hbase存储的分布式悲观锁及其实现方法。

背景技术

数据库技术主要是指关系型数据库。从早期的单机数据库到现在逐渐成为发展主流的分布式数据库，但其要解决的问题主要分为两大类：在线分析处理OLAP(OnlineAnalytics Processing)和在线业务处理OLTP(Online Transactional Processing)。以下简称OLAP和OLTP。

OLAP，也叫联机分析处理(Online Analytical Processing)系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，一条语句的执行时间可能会非常长，并且不会有大量语句并行执行。

OLTP，也叫联机事务处理(Online Transaction Processing)，表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主。在这样的系统中，单个数据库每秒处理的事务往往超过几千甚至几万个，对事务的并发程度要求极高，出现事务冲突的情况相对于OLAP要多很多。

数据库中事务并发控制的实现，主要可以分为两大类，分别是乐观锁，悲观锁，下面阐述两种机制在OLAP和OLTP中的表现以及主流数据库选择的方案。

乐观锁假设多用户并发的事务在处理时不会彼此互相影响造成事务冲突，各事务能够在不使用锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚，并给用户报告事务冲突的错误，用户碰到此类错误需要重复执行整个事务。

悲观锁对于事务要访问的数据,假定其必定会发生冲突,在读取或修改过程中都会用锁来保护，只有当这个事务提交并释放锁以后，其他事务才能够执行与该锁冲突的操作，通过让事务等待锁的方式,使并行的操作串行执行.

分析目前主流分布式数据库，比如Apache Trafodion,TiDB都是使用的乐观锁的事务并发机制，这种机制默认事务冲突的情况很少，在冲突较少的场景下表现较好，但是在事务并发冲突高的情况下就不是十分合适，另外乐观锁需要对应用进行改造，对于很多应用程序比较难实现。

分析目前主流单机数据库，比如Oracle,MySQL使用的都是悲观锁的事务并发机制，现如今，随着互联网、物联网、5G和云计算等新兴技术的发展，数据量爆发式增长。单机数据库受到单个物理机器的配置的影响，事务并发性受到限制，同时分布式数据库是目前主流的数据库发展方向，那么在分布式数据库上实现悲观锁就成了迫在眉睫的问题。

上述乐观锁相信事务之间的数据竞争的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，进行必要的冲突检测，确保事务的隔离性和一致性，当在并发高的场景下，比如商品抢购，只有少数的人能抢购到商品，其他人抢购失败，由于是乐观锁机制，可能到商品结算的环节才会告知用户未抢到商品，大部分事务要做很多多余的操作之后进行事务回滚，这样会造成资源的大量消耗，针对这样的情况需要用悲观锁来解决，先加锁再进行数据访问，也就是说在抢购环节就能告诉用户是否抢购成功，避免了多余的资源消耗。

目前使用悲观锁机制的数据库都是单机数据库，当前的硬件条件下，单机数据库可以支持单表千万级数据量的存储，但是难以支撑密集的并发读写，存在性能瓶颈，若采用分区表方案，数据不能跨实例存储，扩展性和维护性较差，若采用分库方案，客户端需要自行管理各库连接，数据库连接管理和升级复杂，扩容迁移困难，普通服务器支撑能力有限，品牌厂商的服务器价格高昂，通过增加硬件规格来提升并发性能的成本太高，且能到达的性能高度有限。因而有必要针对在分布式系统上使用上述悲观锁的技术进行研究和改进。

发明内容

本发明的目的之一在于针对上述不足，提供一种基于Hbase存储的分布式悲观锁及其实现方法，以期望解决现有技术中悲观锁事务并发机制无法在分布式数据库系统上使用，单机难以支撑密集的并发读写，存在性能瓶颈，而分区分库的方案存在扩展性和维护性较差，数据库连接管理和升级复杂，扩容迁移困难，服务器使用成本高等技术问题。

为解决上述的技术问题，本发明采用以下技术方案：

本发明一方面提供了一种基于Hbase存储的分布式悲观锁，所述分布式悲观锁包括锁管理器，所述锁管理器用于安装在Hbase系统的RegionServer节点的Region上；所述锁管理器具有加锁与解锁接口，且由锁、操作事务与锁持有者构成十字链表格式，其中横向维度为当前数据行的信息，纵向维度为操作事务信息，所述横向维度与纵向维度之间的交点为锁持有者。

作为优选，进一步的技术方案是：所述操作事务为访问并操作各种数据项的一个数据库操作序列，所述数据库操作序列内所加的锁全部保存在锁管理器的Transaction对象集合中。

更进一步的技术方案是：所述锁包括表锁和行锁，所述表锁对象对应Region表，其rowKey属性值为空；所述行锁对象对应Region表的一个数据行，其rowKey属性值为当前数据行的行键。

更进一步的技术方案是：所述锁持有者为操作事务通过锁管理器对数据加锁时所新建，所述锁持有者包括锁类型、锁模式与操作事务。

更进一步的技术方案是：所述锁模式包括共享读锁、排它锁、更新锁、意向读锁与意向排它锁。

本发明另一方面提供了一种上述基于Hbase存储的分布式悲观锁的实现方法，所述的方法包括如下步骤：

在对Hbase系统执行操作事务前，操作事务首先向锁管理器申请加锁，如加锁成功则执行当前的操作事务，反之则等待重新尝试加锁；

加锁的过程由锁管理器首先查询当前操作事务的事务号，如存在则继续查询当前操作事务操作的数据行的行号，反之则先创建事务号后，再继续查询当前操作事务操作的数据行的行号；

如当前操作事务操作数据行的行号存在，则继续查询锁持有者信息，反之则先创建当前数据行的行号后，再继续查询锁持有者信息；

如查询到锁持有者信息，则判断是否允许加锁，反之则先创建持有者信息，再判断是否允许加锁；

如允许加锁，则修改锁持有者信息并加锁，加锁成功，反之则拒绝加锁并等待重新尝试，如重新尝试N次后仍然拒绝加锁，则加锁失败。

作为优选，进一步的技术方案是：所述的方法包括解锁，在当前操作事务提交或者回滚后，由锁管理器查询当前操作事务的事务号，然后遍历删除当前事务号对应的所有锁持有者，再删除当前事务号对应的全部事务对象，当前操作事务操作的数据行解锁完成。

更进一步的技术方案是：所述判断是否允许加锁的方式为通过已经存在的锁持有者信息获取到当前操作事务在当前数据行已经加过锁的信息，通过对应的数据行号得到当前行所有事务加过锁的信息，将两者相减得到除当前操作事务外加过锁的信息，得到关键锁信息后通过冲突矩阵和相容矩阵判断是否允许添加当前锁类型。

更进一步的技术方案是：所述对Hbase系统执行的操作事务包括Get操作、Scan操作、Put操作与Delete操作，所述Get操作为通过Key取一行数据，Scan操作为通过StartKey和EndKey取一段连续的数据，Put操作为通过Key添加一条数据，Delete操作为通过Key删除一条数据。

更进一步的技术方案是：所述操作事务向锁管理器申请加锁的所类型包括共享读锁、排它锁、更新锁、意向读锁与意向排它锁。

与现有技术相比，本发明的有益效果之一是：通过在HBase存储系统的节点Region上安装锁管理器，从而可对HBase系统的数据操作进行悲观锁加锁与解锁的操作，利用悲观锁所故有的特性，使得数据存储系统可支持更高频次的事务并发操作，相对于乐观锁而言，可有效降低系统资源消耗；并且HBase存储系统是一种具有高可靠性、高性能可伸缩的分布式存储系统，可在廉价PC服务器上搭建起大规模结构化存储集群，从而可进行线性拓展，摆脱单机的束缚，因此不存在性能瓶颈问题，且在PC服务器上使用的成本较低，同时本发明所提供的一种基于Hbase存储的分布式悲观锁架构简单，易于实现，适于在各类HBase数据系统上使用，应用范围广阔。

附图说明

图1为用于说明本发明一个实施例的锁管理器结构示意框图；

图2为Hbase存储分布式悲观锁的设计架构图；

图3为用于说明本发明一个实施例的方法流程图；

图4为用于说明本发明一个实施例的悲观锁加锁流程图。

具体实施方式

下面结合附图对本发明作进一步阐述。

本发明的一个实施例是一种基于Hbase存储的分布式悲观锁，该分布式悲观锁包括锁管理器，该锁管理器用于安装在Hbase系统的RegionServer节点的Region上，锁管理器的结构如图1所示，其具有加锁与解锁接口，且由锁、操作事务与锁持有者构成十字链表格式，其中横向维度为当前数据行的信息，纵向维度为操作事务信息，所述横向维度与纵向维度之间的交点为锁持有者，如此的十字哈希链表方式设计简单明了，易于维护复杂的锁信息。

现基于前述所描述的悲观锁结构，对上述的概念解释如下：

上述的操作事务为访问并操作各种数据项的一个数据库操作序列，所述数据库操作序列内所加的锁全部保存在锁管理器的Transaction对象集合中。这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。在锁管理器中有一个操作事务(Transaction类对象)集合。

上述的锁包括表锁和行锁，所述表锁对象对应Region表，其rowKey属性值为空；所述行锁对象对应Region表的一个数据行，其rowKey属性值为当前数据行的行键。具体来说，锁使用Lock类对象表示，锁代表资源，一个表对应一个表锁(Lock)对象，其rowKey属性值为空；一个表的数据行对待一个行锁(Lock)对象，其rowKey属性值为当前行的行键。

上述的锁持有者为操作事务通过锁管理器对数据加锁时所新建，所述锁持有者包括锁类型、锁模式与操作事务。前述的锁模式包括S锁(共享读锁)、X锁(排它锁)、U锁(更新锁)、IS锁(意向读锁)、IX锁(意向排它锁)。操作事务间的锁冲突由冲突矩阵(见表1)控制，事务内锁的相容由相容矩阵(见表2)控制。具体来说，前述锁持有者包括3个属性(操作事务transaction、锁lock、锁模式lockMode)，即操作事务transaction在锁lock上加了哪种锁模式。加锁时，会新建一个LockHolder，这个锁持有者会加到锁对象Lock上锁持有者链表末尾；同时这个锁持有者也会加到操作事务中的锁持有者链表末尾。

即上述的锁、操作事务、锁持有者这三者构成了十字链表的格式，横向维度是数据行信息，纵向维度是操作事务信息，它们的交点就是锁持有者。

表1：冲突矩阵

	X	U	IX	S	IS
						IS	1	0	0	0	0
S	1	0	1	0	0
						IX	1	1	0	1	0
U	1	1	1	0	0
						X	1	1	1	1	1

上表中，1代表冲突，0代表不冲突。

表2：相容矩阵

	X	U	IX	S	IS
						IS	0	0	0	0	1
S	0	0	0	1	1
						IX	0	0	1	0	1
U	0	1	0	1	1
						X	1	1	1	1	1

上表中，1代表相容，0代表不相容

在本实施例中，通过在HBase存储系统的节点Region上安装锁管理器，从而可对HBase系统的数据操作进行悲观锁加锁与解锁的操作，利用悲观锁所故有的特性，使得数据存储系统可支持更高频次的事务并发操作，相对于乐观锁而言，可有效降低系统资源消耗；并且HBase存储系统是一种具有高可靠性、高性能可伸缩的分布式存储系统，可在廉价PC服务器上搭建起大规模结构化存储集群，从而可进行线性拓展，摆脱单机的束缚，因此不存在性能瓶颈问题，且在PC服务器上使用的成本较低。

基于上述所描述的，HBase是一个高可靠性、高性能、可伸缩的分布式存储系统，利用HBase技术可在廉价PC服务器上搭建起大规模结构化存储集群。HBase系统中每个管理数据的节点称为RegionServer,每个RegionServer管理一个或多个Region,数据存储在Region上面，通过作用于每个Region上的HBase Coprocessor实现悲观锁，通常对HBase的数据操作可以简单的分为Get,Scan，Put,Delete三种，其中，Get操作是通过Key取一行数据，Scan操作时通过StartKey和EndKey取某一段连续的数据，Put操作是通过Key添加一条数据，Delete操作是通过Key删除一条数据，按照悲观锁需要加锁的逻辑，在上述四种操作前分别要在Get前加S锁，Scan前加多行S锁，Put前加X锁，Delete前加X锁。对这些加锁的操作以及操作事务完成提交事务释放锁都需要进行管理，管理锁的对象称为锁管理器，每个锁管理器仅管理当前所在Region上面的数据，其设计架构如图2所示。

本发明的另一个实施例是一种上述基于Hbase存储的分布式悲观锁的实现方法，该方法包括如下步骤：

在对Hbase系统执行操作事务前，操作事务首先向锁管理器申请加锁，如加锁成功则执行当前的操作事务，反之则等待重新尝试加锁；具体如图3所示，以Get操作为例，对数据加锁进行阐述；

上述对Hbase系统执行的操作事务包括Get操作、Scan操作、Put操作与Delete操作，所述Get操作为通过Key取一行数据，Scan操作为通过StartKey和EndKey取一段连续的数据，Put操作为通过Key添加一条数据，Delete操作为通过Key删除一条数据；且操作事务向锁管理器申请加锁的所类型包括S锁(共享读锁)、X锁(排它锁)、U锁(更新锁)、IS锁(意向读锁)、IX锁(意向排它锁)。

结合图4所示，加锁的过程由锁管理器首先查询当前操作事务的事务号，如存在则继续查询当前操作事务操作的数据行的行号，反之则先创建事务号后，再继续查询当前操作事务操作的数据行的行号；

如当前操作事务操作数据行的行号存在，则继续查询锁持有者信息，反之则先创建当前数据行的行号后，再继续查询锁持有者信息；

如查询到锁持有者信息，则判断是否允许加锁，反之则先创建持有者信息，再判断是否允许加锁；

上述判断是否允许加锁的方式为通过已经存在的锁持有者信息获取到当前操作事务在当前数据行已经加过锁的信息，通过对应的数据行号得到当前行所有事务加过锁的信息，将两者相减得到除当前操作事务外加过锁的信息，得到关键锁信息后通过冲突矩阵和相容矩阵判断是否允许添加当前锁类型；

如允许加锁，则修改锁持有者信息并加锁，加锁成功，反之则拒绝加锁并等待重新尝试，如重新尝试N次后仍然拒绝加锁，则加锁失败。

并且在本实施例所述的方法中，还包括解锁，即在当前操作事务提交或者回滚后，由锁管理器查询当前操作事务的事务号，由于已经成功加过所，因此该事务号必定存在，通过事务号查询到锁持有者后，删除当前事务号对应的所有锁持有者，再删除当前事务号对应的全部事务对象，当前操作事务操作的数据行解锁完成。

基于上述所提到的悲观锁加锁流程，发明人结合图4再次对其进一步说明如下：

加锁过程需要确定的参数有事务号，行号，锁类型，参数传入锁管理器后根据事务号查找是否有对应的操作事务，若没有需要新建操作事务，若有就可以确定纵向维度，下一步查找是否有对应的行，若没有也需要新建行，若有就可以确定横向维度，根据横纵两个维度就可以锁定需要修改的锁持有者，若没有也需要新建，若存在可以获取到当前操作操作事务在当前行已经加过锁的信息，通过对应的行号可以得到当前行所有操作事务加过锁的信息，两者相减就可以得到除当前操作事务外加过锁的信息，得到这些关键锁信息后根据冲突矩阵和相容矩阵判断是否可以添加当前锁类型，若拒绝加锁进行一定次数的重试，始终未成功则本次加锁失败，若某次成功则修改锁持有者信息后返回加锁成功。

基于上述的实施例，锁管理器采用十字哈希链表方式，使纵向维度均是当前操作事务的信息，横向维度仅是当前行的信息，其交点位置确定了某个操作事务在某行上的锁信息，也就是锁持有者，其设计简单明了，易于维护复杂的锁信息。并且锁管理器仅管理当前Region级别的数据，极大的提高了OLTP场景中关键操作事务的并发性，提高了性能效率。同时通过HBase Coprocessor实现悲观锁，充分利用HBase现有机制，降低开发复杂度，缩减开发周期。

因此本发明兼具了悲观锁的事务并发方式和分布式系统两个方面的优点，与采用悲观锁方式的主流单机数据库相比，本申请提案不存在性能瓶颈问题，可以进行线性拓展，摆脱单机的束缚，与采用乐观锁的主流分布式数据库相比，本申请提案可以支持更高的事务并发，更高OLTP性能。

在本说明书中所谈到的“一个实施例”、“另一个实施例”、“实施例”、等，指的是结合该实施例描述的具体特征、结构或者特点包括在本申请概括性描述的至少一个实施例中。在说明书中多个地方出现同种表述不是一定指的是同一个实施例。进一步来说，结合任一实施例描述一个具体特征、结构或者特点时，所要主张的是结合其他实施例来实现这种特征、结构或者特点也落在本发明的范围内。

尽管这里参照本发明的多个解释性实施例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。更具体地说，在本申请公开、附图和权利要求的范围内，可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变型和改进外，对于本领域技术人员来说，其他的用途也将是明显的。

Claims (8)

1.一种基于Hbase存储的分布式悲观锁，其特征在于：所述分布式悲观锁包括锁管理器，所述锁管理器用于安装在Hbase系统的RegionServer节点的Region上；

所述锁管理器具有加锁与解锁接口，且由锁、操作事务与锁持有者构成十字链表格式，其中横向维度为当前数据行的信息，纵向维度为操作事务信息，所述横向维度与纵向维度之间的交点为锁持有者；

所述锁持有者为操作事务通过锁管理器对数据加锁时所新建，所述锁持有者包括锁类型、锁模式与操作事务；所述锁模式包括共享读锁、排它锁、更新锁、意向读锁与意向排它锁。

2.根据权利要求1所述的基于Hbase存储的分布式悲观锁，其特征在于：所述操作事务为访问并操作各种数据项的一个数据库操作序列，所述数据库操作序列内所加的锁全部保存在锁管理器的Transaction对象集合中。

3.根据权利要求1所述的基于Hbase存储的分布式悲观锁，其特征在于：所述锁包括表锁和行锁，所述表锁对象对应Region表，其rowKey属性值为空；所述行锁对象对应Region表的一个数据行，其rowKey属性值为当前数据行的行键。

4.一种权利要求1至3任意一项所述基于Hbase存储的分布式悲观锁的实现方法，其特征在于所述的方法包括如下步骤：

在对Hbase系统执行操作事务前，操作事务首先向锁管理器申请加锁，如加锁成功则执行当前的操作事务，反之则等待重新尝试加锁；

加锁的过程由锁管理器首先查询当前操作事务的事务号，如存在则继续查询当前操作事务操作的数据行的行号，反之则先创建事务号后，再继续查询当前操作事务操作的数据行的行号；

如当前操作事务操作数据行的行号存在，则继续查询锁持有者信息，反之则先创建当前数据行的行号后，再继续查询锁持有者信息；

如查询到锁持有者信息，则判断是否允许加锁，反之则先创建持有者信息，再判断是否允许加锁；

如允许加锁，则修改锁持有者信息并加锁，加锁成功，反之则拒绝加锁并等待重新尝试，如重新尝试N次后仍然拒绝加锁，则加锁失败。

5.根据权利要求4所述的方法，其特征在于：所述的方法包括解锁，在当前操作事务提交或者回滚后，由锁管理器查询当前操作事务的事务号，然后遍历删除当前事务号对应的所有锁持有者，再删除当前事务号对应的全部事务对象，当前操作事务操作的数据行解锁完成。

6.根据权利要求4所述的方法，其特征在于：所述判断是否允许加锁的方式为通过已经存在的锁持有者信息获取到当前操作事务在当前数据行已经加过锁的信息，通过对应的数据行号得到当前行所有事务加过锁的信息，将两者相减得到除当前操作事务外加过锁的信息，得到关键锁信息后通过冲突矩阵和相容矩阵判断是否允许添加当前锁类型。

7.根据权利要求4所述的方法，其特征在于：所述对Hbase系统执行的操作事务包括Get操作、Scan操作、Put操作与Delete操作，所述Get操作为通过Key取一行数据，Scan操作为通过StartKey和EndKey取一段连续的数据，Put操作为通过Key添加一条数据，Delete操作为通过Key删除一条数据。

8.根据权利要求4所述的方法，其特征在于：所述操作事务向锁管理器申请加锁的锁类型包括共享读锁、排它锁、更新锁、意向读锁与意向排它锁。