CN112099961A - 一种基于锁状态缓存的分布式锁管理器的实现方法 - Google Patents

Abstract

本发明涉及一种基于锁状态缓存的分布式锁管理器的实现方法，包括步骤1、上层模块调用锁模块，进入锁模块并进行快速加锁；步骤2、检查是否有其他事务已经持有锁，处理锁冲突；步骤3、等待本节点事务放锁；步骤4、向主节点请求加锁，主节点处理加锁请求；步骤5、向持有锁的远程节点请求放锁，从节点处理放锁请求；步骤6、加锁成功，记录加锁信息并返回到上层模块。本发明设计合理，其通过主节点锁管理器和从节点锁状态缓存方式，即可以协调各个节点的加锁请求，保证数据库的一致性，又利用了数据库事务DML操作为主的特性，即节点上的锁状态缓存在大部分情况下都是有效的，有效减少了远程节点的访问开销，提高了加锁效率。

Description

一种基于锁状态缓存的分布式锁管理器的实现方法

技术领域

本发明属于数据库技术领域，涉及分布式锁管理器，尤其是一种基于锁状态缓存的分布式锁管理器的实现方法。

背景技术

随着信息技术的飞速发展，应用系统的并发请求越来越高，仅靠一台数据库服务器对外提供服务已经不能满足用户高频、高并发的访问需求。通过将数据库实例分散在多台服务器上，对外提供统一的数据库服务，可以将请求压力均匀分散到各个服务器，达到提高吞吐量的目的。

基于上述背景，神通数据库提供了基于共享存储的数据库集群系统。共享存储集群拥有多个数据库节点，每个节点可以独立的对外提供服务，多个节点操作位于共享存储设施上的数据内容。集群内部各个节点间通过高速网络进行交互，保证数据库的一致性。通过多个节点并行服务，提高了数据库的吞吐量，同时提供了高可用性，能够保证在集群中只要有一个节点存活，就能正常对外提供服务。

数据库集群中的各个节点在提供服务的同时，可能对数据库中的某项资源进行或读或写的操作。当有多个节点同时访问同一资源时，因为并发操作的原因，可能造成数据的不一致。协调不同节点对资源的并发操作，可以通过分布式锁实现。

由于数据库集群中的所有成员都可以同时接受客户端的读写请求，这些来自不同节点的请求可能在同一时刻访问数据库中的同一资源，因此，为了保证数据库的分布式一致性，不同的节点需要通过分布式锁来访问共享资源，防止互相干扰。

传统单机数据库提供的锁机制，只能协调单个实例多个线程之间的加锁请求。在分布式集群环境中，有必要实现一套分布式锁定装置，能够协调多个节点对同一共享资源的锁定请求，从而保证分布式一致性。

发明内容

本发明的目的在于克服现有技术的不足，提出一种设计合理、效率高且能够有效保证集群数据库一致性的基于锁状态缓存的分布式锁管理器的实现方法。

本发明解决其技术问题是采取以下技术方案实现的：

一种基于锁状态缓存的分布式锁管理器的实现方法，包括以下步骤：

步骤1、上层模块调用锁模块，进入锁模块并进行快速加锁；

步骤2、检查是否有其他事务已经持有锁，处理锁冲突；

步骤3、等待本节点事务放锁；

步骤4、向主节点请求加锁，主节点处理加锁请求；

步骤5、向持有锁的远程节点请求放锁，从节点处理放锁请求；

步骤6、加锁成功，记录加锁信息并返回到上层模块。

进一步，所述步骤1的具体实现方法包括以下步骤：

⑴检查当前请求锁的事务是否已经持有锁，若已经持有，则加锁成功，转到步骤6；

⑵检查请求的锁是否存在；

⑶若当前节点是主节点，且锁不存在，则加锁成功，转到步骤6；

⑷若当前节点是从节点，或锁存在，则转到步骤2。

进一步，所述步骤2的具体实现方法包括以下步骤：

⑴如果没有其他事务持有该锁，则进行如下处理：

①如果是从节点，检查锁状态缓存是否有效；如果该锁的锁状态缓存有效，则加锁成功，转到步骤6，否则转到步骤4；

②如果是主节点，则加锁成功，转到步骤6；

⑵如果已经有事务持有该锁，则进行如下处理：

①如果是从节点，则继续执行步骤3；

②如果是主节点，则判断持有锁的事务是否属于远程节点，如果属于远程节点，则转到步骤5，否则转到步骤3。

进一步，所述步骤3的具体实现方法包括以下步骤：

⑴将当前线程加入到持有锁的事务的等待链表；

⑵持有锁的事务结束时，唤醒等待链表上的线程，等待线程被唤醒后，转到步骤2重新尝试加锁。

进一步，所述步骤4的具体实现方法包括以下步骤：

⑴本节点封装加锁请求，向远程主节点发起同步请求，等待返回；

⑵主节点收到从节点的加锁请求后，进行如下处理：

①检查请求节点是否已经持有锁，若已持有，则加锁成功，返回到请求节点；

②检查是否有其他节点已经持有锁：

若已经持有，且持有锁的是本节点，则等待持有锁的事务放锁，直到加锁成功后返回到请求节点；

若已经持有，且持有锁的是其他节点，则向持有锁的节点请求放锁，直到加锁成功后返回到请求节点；

若未持有，则加锁成功，返回到请求节点。

⑶加锁请求从主节点返回后，将锁状态缓存到本节点，转到步骤2。

进一步，所述步骤5的具体实现方法包括以下步骤：

⑴主节点封装放锁请求，向持有锁的从节点发起同步请求，等待返回；

⑵从节点收到主节点的放锁请求，检查锁是否仍被持有：

①若有事务持有锁，则等待持有锁的事务放锁；

②若锁未被持有或持有锁的事务已经放锁，则失效本节点的锁状态缓存，返回放锁成功；

⑶放锁请求从从节点返回后，更新主节点上的锁信息，转到步骤2。

本发明的优点和积极效果是：

本发明采用分布式锁管理器，在集群启动之后，通过仲裁盘选举出集群主节点，主节点负责维护全局的锁信息。当某个节点需要锁定某项资源时，先在本地中尝试加锁，若已经缓存加锁状态且缓存有效，加锁成功。没有缓存或缓存失效时，才会向主节点发起加锁请求，主节点锁管理器判断是否满足加锁条件。若满足加锁条件，将锁分配给请求节点，若不满足，向持有锁的节点发送解锁请求，待成功解锁后再将锁分配给请求节点。这种通过主节点锁管理器和从节点锁状态缓存方式，即可以协调各个节点的加锁请求，保证数据库的一致性，又利用了数据库事务DML操作为主的特性，即节点上的锁状态缓存在大部分情况下都是有效的，有效减少了远程节点的访问开销，提高了加锁效率。

附图说明

图1为本发明的分布式锁实现的整体结构图；

图2为本发明的处理快速加锁的流程图；

图3为本发明的处理锁冲突的流程图；

图4为本发明的处理加锁请求的流程图；

图5为本发明的处理放锁请求的流程图。

具体实施方式

以下结合附图对本发明做进一步详述。

本发明采用分布式锁来实现，如图1所示，根据集群数据库节点的性质，共享存储集群中的节点可以分为主节点(主节点中设有主节点锁模块)和从节点(从节点中设有从节点锁模块)。

主节点只有一个，从节点有多个。

主节点了解全局加锁情况，包括本节点和其他节点。从节点只了解本节点的加锁情况。

从节点加锁时，可能会向主节点发起请求。主节点负责协调各个节点的加锁请求，同时可能会向从节点发起放锁请求，从而保证加锁一致性。

数据库接受外部请求，请求需要锁定数据库资源时，调用锁模块提供的接口，完成加锁。

锁模块内部处理加锁请求，根据本节点的性质和加锁对象以及锁状态缓存，决定是否向远程节点发起加锁或者放锁的请求。通过分布式锁管理器处理，当满足加锁条件后，将加锁结果返回给上层模块。

基于上述设计思想，本发明提供一种基于锁状态缓存的分布式锁管理器的实现方法，包括以下步骤：

步骤1、上层模块调用锁模块，进行快速加锁处理。

如图2所示，本步骤的具体处理过程如下：

(1)根据锁标签，检查当前请求锁的事务对该锁的持有情况。如果已经持有该锁，表明此前已经加过锁，返回加锁成功。

(2)如果还未持有锁，尝试获取锁对象。

(3)如果锁对象存在，需要进一步处理锁冲突，尝试加锁。

(4)锁对象不存在，若当前节点是主节点，可以加锁成功，因为主节点拥有全局的加锁信息，其他节点此时肯定不会持有该锁。

(5)锁对象不存在，若当前节点是从节点，不能认为加锁成功，因为此时可能该锁被其他节点持有，需要请求主节点协调加锁。

步骤2、检查是否有其他事务已经持有锁，处理锁冲突。

由于快速加锁失败，锁可能被其他事务或者其他节点持有，因此，需要进一步处理锁冲突，判断是否能够加锁。

如图3所示，处理锁冲突的过程如下：

(1)锁被某个事务持有后，加锁信息会记录到与该锁相关的持有链表中。检查请求加锁的持有链表，获得锁被持有的情况。

(2)如果锁已经被其他事务或节点持有，则：

如果当前节点是从节点，那么肯定是本节点的事务持有锁，需要等待持有锁的事务放锁后再次尝试加锁。

如果当前节点是主节点，可能是本节点的事务持有锁，也可能是远程节点持有锁。如果是本节点持有锁，等待持有锁的事务放锁后再次尝试加锁。如果是远程节点持有锁，因为远程节点不会主动放锁，需要主节点发起放锁请求，得到远程节点持有锁的情况。

(3)如果锁没有被持有，则：

如果当前节点是主节点，加锁成功。因为主节点拥有全局的加锁信息，此时肯定没有其他事务或者节点持有锁。

如果当前节点是从节点，从节点不会主动放锁，如果之前加锁后主节点还未要求从节点放锁，本地锁状态缓存有效，加锁成功。本地锁缓存状态无效或没有锁状态缓存，需要重新向主节点请求加锁。

步骤3：等待本节点事务放锁处理：当前线程加入到持有锁的事务的等待链表；持有锁的事务结束时，唤醒等待链表上的线程。等待线程被唤醒后，重新尝试加锁。

步骤4：向主节点请求加锁，主节点处理加锁请求。

如图4所示，主节点收到从节点的加锁请求后，处理过程如下：

(1)从锁的持有链表中，获得此时锁被持有情况。

(2)如果锁已被请求节点持有(因为从节点可能并发的请求锁，锁已经被从节点的另外一个线程请求成功了)，加锁成功，返回到请求节点。

(3)持有锁的是主节点，需要等待主节点上的事务放锁后再次尝试加锁。

(4)持有锁的是另外一个从节点，需要向从节点发起放锁请求，等待从节点放锁后，再次尝试加锁。

步骤5：向持有锁的远程节点请求放锁，从节点处理放锁请求。

如图5所示，从节点收到主节点的放锁请求，进行如下处理：

(1)从锁的持有链表中，获得此时锁被持有情况。

(2)在从节点，如果锁被持有，肯定是本地事务持有，需要等待本地事务放锁，直到没有事务持有该锁，放锁成功。

(3)放锁成功，需要失效本节点锁状态缓存，返回到主节点。

步骤6：加锁成功，记录加锁信息并返回到上层模块。

需要强调的是，本发明所述的实施例是说明性的，而不是限定性的，因此本发明包括并不限于具体实施方式中所述的实施例，凡是由本领域技术人员根据本发明的技术方案得出的其他实施方式，同样属于本发明保护的范围。

Claims (6)

1.一种基于锁状态缓存的分布式锁管理器的实现方法，其特征在于：包括以下步骤：

步骤1、上层模块调用锁模块，进入锁模块并进行快速加锁；

步骤2、检查是否有其他事务已经持有锁，处理锁冲突；

步骤3、等待本节点事务放锁；

步骤4、向主节点请求加锁，主节点处理加锁请求；

步骤5、向持有锁的远程节点请求放锁，从节点处理放锁请求；

步骤6、加锁成功，记录加锁信息并返回到上层模块。

2.根据权利要求1所述的一种基于锁状态缓存的分布式锁管理器的实现方法，其特征在于：所述步骤1的具体实现方法包括以下步骤：

⑴检查当前请求锁的事务是否已经持有锁，若已经持有，则加锁成功，转到步骤6；

⑵检查请求的锁是否存在；

⑶若当前节点是主节点，且锁不存在，则加锁成功，转到步骤6；

⑷若当前节点是从节点，或锁存在，则转到步骤2。

3.根据权利要求1所述的一种基于锁状态缓存的分布式锁管理器的实现方法，其特征在于：所述步骤2的具体实现方法包括以下步骤：

⑴如果没有其他事务持有该锁，则进行如下处理：

①如果是从节点，检查锁状态缓存是否有效；如果该锁的锁状态缓存有效，则加锁成功，转到步骤6，否则转到步骤4；

②如果是主节点，则加锁成功，转到步骤6；

⑵如果已经有事务持有该锁，则进行如下处理：

①如果是从节点，则继续执行步骤3；

②如果是主节点，则判断持有锁的事务是否属于远程节点，如果属于远程节点，则转到步骤5，否则转到步骤3。

4.根据权利要求1所述的一种基于锁状态缓存的分布式锁管理器的实现方法，其特征在于：所述步骤3的具体实现方法包括以下步骤：

⑴将当前线程加入到持有锁的事务的等待链表；

⑵持有锁的事务结束时，唤醒等待链表上的线程，等待线程被唤醒后，转到步骤2重新尝试加锁。

5.根据权利要求1所述的一种基于锁状态缓存的分布式锁管理器的实现方法，其特征在于：所述步骤4的具体实现方法包括以下步骤：

⑴本节点封装加锁请求，向远程主节点发起同步请求，等待返回；

⑵主节点收到从节点的加锁请求后，进行如下处理：

①检查请求节点是否已经持有锁，若已持有，则加锁成功，返回到请求节点；

②检查是否有其他节点已经持有锁：

若已经持有，且持有锁的是本节点，则等待持有锁的事务放锁，直到加锁成功后返回到请求节点；

若已经持有，且持有锁的是其他节点，则向持有锁的节点请求放锁，直到加锁成功后返回到请求节点；

若未持有，则加锁成功，返回到请求节点。

⑶加锁请求从主节点返回后，将锁状态缓存到本节点，转到步骤2。

6.根据权利要求1所述的一种基于锁状态缓存的分布式锁管理器的实现方法，其特征在于：所述步骤5的具体实现方法包括以下步骤：

⑴主节点封装放锁请求，向持有锁的从节点发起同步请求，等待返回；

⑵从节点收到主节点的放锁请求，检查锁是否仍被持有：

①若有事务持有锁，则等待持有锁的事务放锁；

②若锁未被持有或持有锁的事务已经放锁，则失效本节点的锁状态缓存，返回放锁成功；

⑶放锁请求从从节点返回后，更新主节点上的锁信息，转到步骤2。

Images