CN112099962A - 分布式锁实现方法、装置和电子设备 - Google Patents

Abstract

本申请提供一种分布式锁实现方法、装置和电子设备，应用终端在获得全局锁和内部锁的基础上，在进行锁释放时，可监测当前分布式系统中是否存在其他应用终端向缓存服务器发送过加锁请求，即是否存在全局竞争，若存在，则将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点。若不存在，则保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。如此，在不存在全局竞争的情况下，可保留全局锁仅对内部锁进行加锁或释放，可减少应用终端与缓存服务器之间的网络交互，提升系统性能。

Description

分布式锁实现方法、装置和电子设备

技术领域

本申请涉及分布式技术领域，具体而言，涉及一种分布式锁实现方法、装置和电子设备。

背景技术

随着业务的不断发展，在传统单机业务系统中，可以通过不断增加线程的方式，来提升服务的吞吐量，同时单机环境中可以实现各种方式的锁机制来保证线程安全。但是单机系统存在天然的缺陷，单机的能力不可能无限提升，同时单机无法保证服务的高可用。因此，分布式系统的出现，使得单机业务的缺陷得以弥补，但是也带来了新的问题，其中一个最大问题就是分布式环境的线程安全问题，于是引入了分布式锁来解决分布式环境下的线程安全问题。

但是目前基于zookeepeer或redis实现的分布式锁中，一般需要利用中间件来实现，在各种应用场景下，应用终端在确定是否具有分布式锁时，均需与zookeepeer或redis进行一次网络数据交互才可实现。这样的方式不仅占用大量的网络资源且对双方性能造成影响。

发明内容

本申请的目的包括，例如，提供了一种分布式锁实现方法、装置和电子设备，其能够减少网络交互、提升系统性能。

本申请的实施例可以这样实现：

第一方面，本申请提供一种分布式锁实现方法，应用于包含多个应用终端的分布式系统中的任一应用终端，各所述应用终端与缓存服务器通信连接，各所述应用终端创建有多个线程，所述方法包括：

针对任一所述应用终端，向所述缓存服务器发送锁释放请求时，监测当前所述分布式系统中是否存在其他应用终端向所述缓存服务器发送过加锁请求；

若存在，则将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将所述全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点；

若不存在，则保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。

在可选的实施方式中，所述方法还包括预先获得全局锁和内部锁的步骤，该步骤包括：

针对任一所述应用终端，监测当前是否具有创建加锁节点的权限，若具有，则按预设顺序编号方式创建对应的加锁节点；

获取所述缓存服务器的节点列表中已存在的加锁节点；

根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功；

若确定加锁成功，则获得对应的全局锁，并基于获得的全局锁为包含的各线程设置对应的内部锁。

在可选的实施方式中，当前创建的加锁节点和所述节点列表中已存在的加锁节点的锁类型均为读锁；

所述根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功的步骤，包括：

检测当前创建的加锁节点的编号是否为最小，若为最小则判定加锁成功；

若不为最小，则查看所述节点列表中已存在的加锁节点中编号比当前创建的加锁节点的编号更小的加锁节点的锁类型是否为读锁，若为读锁，则判定加锁成功，否则判定加锁不成功。

在可选的实施方式中，当前创建的加锁节点和所述节点列表中已存在的加锁节点对应的锁类型均为写锁，或者包含读锁和写锁；

所述根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功的步骤，还包括：

检测当前创建的加锁节点的编号是否为最小，若为最小则判定加锁成功，否则，判定加锁不成功。

在可选的实施方式中，所述监测当前是否具有创建加锁节点的权限的步骤，包括：

监测所述缓存服务器中的用于管理节点列表的持久性节点的访问路径是否存在，若不存在，则判定具有创建加锁节点的权限，否则，不具有创建加锁节点的权限。

在可选的实施方式中，所述按预设顺序编号方式创建对应的加锁节点的步骤，包括：

根据待创建的加锁节点对应的锁类型设置名称前缀；

按预设编号方式创建对应的加锁节点，并根据所述名称前缀为所述加锁节点设置节点名称。

在可选的实施方式中，所述监测当前所述分布式系统中是否存在其他应用终端向所述缓存服务器发送过加锁请求的步骤，包括：

获取所述缓存服务器的监视器所监听到的所述缓存服务器的节点列表信息；

在所述节点列表信息表征所述节点列表中新增加锁节点时，判定当前所述分布式系统中存在其他应用终端向所述缓存服务器发送过加锁请求。

第二方面，本申请提供一种分布式锁实现装置，应用于包含多个应用终端的分布式系统中的任一应用终端，各所述应用终端与缓存服务器通信连接，各所述应用终端创建有多个线程，所述装置包括：

监测模块，用于向所述缓存服务器发送锁释放请求时，监测当前所述分布式系统中是否存在其他应用终端向所述缓存服务器发送过加锁请求；

第一释放模块，用于当前所述分布式系统中存在其他应用终端向所述缓存服务器发送过加锁请求，将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将所述全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点；

第二释放模块，用于当前所述分布式系统中不存在其他应用终端向所述缓存服务器发送过加锁请求，保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。

在可选的实施方式中，所述装置还包括加锁模块，用于：

针对任一所述应用终端，监测当前是否具有创建加锁节点的权限，若具有，则按预设顺序编号方式创建对应的加锁节点；

获取所述缓存服务器的节点列表中已存在的加锁节点；

根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功；

若确定加锁成功，则获得对应的全局锁，并基于获得的全局锁为包含的各线程设置对应的内部锁。

第三方面，本申请提供一种电子设备，包括一个或多个存储介质和一个或多个与存储介质通信的处理器，一个或多个存储介质存储有处理器可执行的机器可执行指令，当电子设备运行时，处理器执行所述机器可执行指令，以执行前述实施方式中任意一项所述的方法步骤。

本申请实施例的有益效果包括，例如：

本申请提供的分布式锁实现方法、装置和电子设备，应用终端在获得全局锁和内部锁的基础上，在进行锁释放时，可监测当前分布式系统中是否存在其他应用终端向缓存服务器发送过加锁请求，即是否存在全局竞争，若存在，则将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点。若不存在，则保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。如此，在不存在全局竞争的情况下，可保留全局锁仅对内部锁进行加锁或释放，可减少应用终端与缓存服务器之间的网络交互，提升系统性能。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的分布式锁实现方法的应用场景图；

图2为本申请实施例提供的分布式锁实现方法的流程图；

图3为本申请实施例提供的分布式锁实现方法的另一流程图；

图4为本申请实施例提供的分布式锁实现方法中，监测节点列表信息的方法的流程图；

图5为本申请实施例提供的分布式锁实现方法中，判定加锁成功的方法的流程图；

图6为本申请实施例提供的分布式锁实现方法中，设置加锁节点的方法的流程图；

图7为本申请实施例提供的分布式锁实现装置的功能模块框图；

图8为本申请实施例提供的电子设备的结构框图。

图标：10-应用终端；100-分布式锁实现装置；110-监测模块；120-第一释放模块；130-第二释放模块；210-处理器；220-存储器；230-总线；20-缓存服务器。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本申请的描述中，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在不冲突的情况下，本申请的实施例中的特征可以相互结合。

本申请实施例提供一种基于zookeepeer的分布式锁实现方法，请参阅图1，为该分布式锁实现方法的应用场景图，该场景中包括缓存服务器20以及包含多个应用终端10的分布式系统，该分布式系统中的各个应用终端10与缓存服务器20通信连接。该缓存服务器20可以是zookeepeer集群，应用终端10可以是服务器、计算机等设备。各个应用终端10可与缓存服务器20通信连接，以实现对数据的读写操作。

现有技术中，大多是基于数据库提供的事物来解决并发情况下对数据库的读写，这种情形下的并发控制，对数据库本身会带来较大的性能损失，从而难以整体提高服务的并发吞吐量。并且，如果有些服务并不使用传统关系数据库的，则无法依赖数据库提供的事物来解决并发场景下的数据库读写，需要另找解决方案。

基于上述研究，本申请中提供的分布式锁实现方案，基于zookeepeer集群实现，zookeepeer是一种分布式高可用的应用程序协调服务，可以用以解决高并发场景下的数据读写，保障分布式全局的一致性。

首先对本实施例中可能涉及到的技术名称进行解释，参见如下：

zookeeper：一种分布式高可用的应用程序协调服务；

instance：实例，独立的进程；

ephemeral_sequential：zookeeper临时顺序节点，该节点在与zookeeper的通信断开后会自动清除，每次创建节点会自增序号；

read/write：读/写，在创建锁节点的时候，根据锁的类型作为创建临时顺序节点的前缀，用以标识加的锁是读锁还是写锁；

Lock：全局锁，Lock对象，记录zookeeper的路径，以及当前实例的锁状态，以及持有一个内部的读写锁；

RW Lock：内部锁，Lock对象内部的读写锁对象，使用可重入锁实现，为单机锁；

contend：全局锁Lock内部标记是否有全局锁竞争，默认为false；

readLock：加读锁；

readUnLock：解除读锁；

writeLock：加写锁；

writeUnLock：解除写锁；

lock path：在zookeeper中以一个path节点作为一个锁实例。

下面结合上述图1所示的应用场景中描述的内容，对本申请实施例提供的分布式锁实现方法进行详细说明。

参照图2所示，为本申请实施例提供的一种实时报表数据管理方法的流程示意图，该方法可以由上述分布式系统中的任一应用终端10来执行。应当理解，在其它实施例中，本实施例所述的分布式锁实现方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。该分布式锁实现方法的详细步骤介绍如下。

步骤S210，针对任一所述应用终端10，向所述缓存服务器20发送锁释放请求时，监测当前所述分布式系统中是否存在其他应用终端10向所述缓存服务器20发送过加锁请求，若存在，则执行以下步骤S220，若不存在，则执行以下步骤S230。

步骤S220，将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将所述全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点。

步骤S230，保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。

本实施例中，各个应用终端10可与缓存服务器20通信连接，各个应用终端10可通过向缓存服务器20注册以获取分布式锁的方式，从而在成功获得分布式锁后执行向缓存服务器20进行数据写入，或者从缓存服务器20进行数据读取的操作。本实施例中，各个应用终端10相对于缓存服务器20而言，相当于多个并发进程，各个进程之间可相互竞争以向缓存服务器20获得分布式锁。一般性地，在任一应用终端10获得分布式锁之后，其他应用终端10需要等待该应用终端10完成相应的操作后将分布式锁释放，或者是因为其他情况分布式锁得以释放后，才能获得进行分布式锁的加锁，进而在加锁成功后向缓存服务器20执行相应的操作。

而各个应用终端10内部又具有多个线程，各个线程之间也相互竞争以获得数据写入或数据读取的权限。因此，在分布式系统中，缓存服务器20作为全局唯一控制，可以管理面向所有应用终端10的全局锁。而针对各个应用终端10，该应用终端10可管理其内部的面对各个线程的内部锁。

在现有技术中，各个应用终端10在获得全局锁之后，并在完成相应的操作后，均会释放全局锁以及内部锁，后续需要执行操作时，再通过与缓存服务器20的信息交互，以判断目前的全局锁的状态。但有些场景下，当前可能并不存在全局锁的竞争，也即当前没有其他的应用终端10需要获得全局锁，因此，若每次在释放锁时，均将全局锁和内部锁进行释放，后续又通过与缓存服务器20进行信息交互的方式查看全局锁的状态，这样将导致一些不必要的交互流程，不仅占用网络资源还会造成双方的处理负担。

因此，本实施例中，任一应用终端10在加锁成功并完成相应的操作之后，向缓存服务器20发送锁释放请求时，同时会监测当前分布式系统中是否存在其他应用终端10向缓存服务器20发送过加锁请求，若存在，则表明当前还有其他的应用程序需要进行全局锁的加锁，即存在全局锁竞争。此种情形下，该应用终端10则可将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点。

而若当前分布式系统中不存在其他应用终端10向缓存服务器20发送过加锁请求，则当前分布式系统中没有其他的应用终端10需要进行全局锁的加锁，即没有全局锁竞争。此种情形下，该应用终端10则无需将全局锁释放，可保留自身对应的全局锁，仅将自身包含的各线程对应的内部锁释放即可。

如此，在后续需要执行读写操作时，无需执行与缓存服务器20之间的网络交互，基于保持的全局锁即可执行相应的操作。

本实施例中，通过上述方式，可以在不存在全局锁竞争的情形下，减少系统中的网络信息交互，降低不必要的网络资源占用。

以下首先对应用终端10预先获得全局锁及内部锁的方式，也即加锁的过程进行介绍。

请参阅图3，在本实施例中，应用终端10可通过以下方式进行加锁：

步骤S110，针对任一所述应用终端10，监测当前是否具有创建加锁节点的权限，若具有，则按预设顺序编号方式创建对应的加锁节点。

步骤S120，获取所述缓存服务器20的节点列表中已存在的加锁节点。

步骤S130，根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功，若确定加锁成功，则执行以下步骤S140。

步骤S140，获得对应的全局锁，并基于获得的全局锁为包含的各线程设置对应的内部锁。

由上述可知，分布式系统中的应用终端10可并发执行操作，缓存服务器20中具有持久性节点，在该持久性节点下可以创建多个加锁节点，加锁节点即为基于应用终端10的加锁请求进行创建。因此，应用终端10在创建相应的加锁节点之后，后续可以执行相应地加锁操作。因此，应用终端10在加锁时，首先需要监测当前是否具有创建加锁节点的权限，在具有加锁请求的权限时，则进行加锁节点的创建，否则，需要等待。

在zookeeper中持久性节点作为一个锁实例，可定义为/lock。应用终端10可监测缓存服务器20中的用于管理节点列表的持久性节点的访问路径是否存在，若不存在，则判定具有创建加锁节点的权限，否则，不具有创建加锁节点的权限。其中，节点列表中可以保存各个应用终端10向缓存服务器20所请求的加锁节点的信息。

而由上述可知，应用终端10在进行锁释放时，可根据当前是否存在全局锁竞争来判断是否释放全局锁，判断是否存在全局竞争的方式可通过监测是否有其他应用终端10向缓存服务器20发送过加锁请求。而在缓存服务器20中通过节点列表保存各个应用终端10所创建的加锁节点信息，因此，请参阅图4，上述步骤S210中监测是否存在其他应用终端10向缓存服务器20发送过加锁请求时，可以通过以下方式实现：

步骤S211，获取所述缓存服务器20的监视器所监听到的所述缓存服务器20的节点列表信息。

步骤S212，在所述节点列表信息表征所述节点列表中新增加锁节点时，判定当前所述分布式系统中存在其他应用终端10向所述缓存服务器20发送过加锁请求。

本实施例中，缓存服务器20中的监视器可监听节点列表信息，应用终端10可通过注册方式监听所关系的节点列表信息，当节点列表信息发生变化，例如，新增加锁节点信息、删除加锁节点信息、数据改变等，应用终端10均可通过监视器获取到。因此，应用终端10在监听到节点列表信息表征节点列表中新增加解锁节点时，则表明当前具有其他的应用终端10向缓存服务器20发送过加锁请求。此种情形下，即表明存在全局锁竞争，则应用终端10在进行锁释放时，需要将全局锁和内部锁进行释放。

此外，创建了加锁节点并不意味着加锁成功，需要满足一定条件时，在成功创建加锁节点的基础上才能成功加锁。

本实施例中，在某个应用终端10创建加锁节点后，可获取缓存服务器20的节点列表中已存在的加锁节点。基于自身所创建的加锁节点对应的锁类型以及节点列表中已存在的加锁节点的锁类型，判断是否加锁成功。

其中，应用终端10向缓存服务器20所执行的操作主要包括数据读取和数据写入操作，相应地，所需的全局锁的锁类型为读锁和写锁，通过获得的读锁执行数据读取操作，通过获得的写锁执行数据写入操作。

本实施例中，创建加锁节点时，会按照预设顺序编号方式为加锁节点编号，每个加锁节点的编号依次递增。本实施例中的加锁节点的类型为临时性顺序节点，由上述可知，在进行锁释放时，若进行全局锁的释放，则对应所创建的加锁节点将删除。此外，若持有全局锁的应用终端10存在宕机等现象导致无法进行锁释放操作时，由于临时性顺序节点的特性，在该应用终端10宕机而与缓存服务器20断开网络连接时，则其对应的加锁节点将被删除。如此，可以避免应用终端10宕机无法进行锁释放所占用全局锁导致其他应用终端10无法加锁的弊端。

各个应用终端10均可向缓存服务器20请求加锁节点，创建的加锁节点的编号时间越靠前编号越小。而其他的已被释放的加锁节点已从节点列表中删除，也就是说，若某个应用终端10所创建的加锁节点的编号最小，则表明其加锁节点是最先创建的。

但是，考虑到应用终端10的执行业务包括数据读取和数据写入，其中，从缓存服务器20中进行数据读取并不会造成缓存服务器20中数据的变化，因此，可以允许多个应用终端10同时进行数据读取。但是，向缓存服务器20中进行数据写入将导致缓存服务器20中数据的变化，因此，为了保障后续执行的数据读取和数据写入针对的是最新的数据源，数据写入需要依次进行。

因此，应用终端10在判断是否成功获得加锁时，需要根据自身以及其他的应用终端10的加锁类型来判断。当然，若当前节点列表中不存在其他应用终端10所创建的加锁节点，即表明当前不存在全局锁的竞争，则在创建当前的加锁节点后，可以确定加锁成功。

在一种实现方式中，请参阅图5，若当前创建的加锁节点和节点列表中已存在的加锁节点的锁类型均为读锁，则可以通过以下方式判断是否加锁成功：

步骤S131，检测当前创建的加锁节点的编号是否为最小，若为最小则执行以下步骤S133，若不为最小，则执行以下步骤S132。

步骤S132，查看所述节点列表中已存在的加锁节点中编号比当前创建的加锁节点的编号更小的加锁节点的锁类型是否为读锁，若为读锁，则执行以下步骤S133，否则，执行以下步骤S134。

步骤S133，判定加锁成功。

步骤S134，判定加锁不成功。

在本实施例中，若某个应用终端10当前创建的加锁节点的编号为最小，则表明相对于其他的应用终端10，该应用终端10创建的加锁节点的时间点最早，则可以确定加锁成功，获得全局锁。而若比该应用终端10所创建的加锁节点的编号更小的加锁节点其同样为读锁，由于多个读锁之间相互不相斥，则同样可以成功获得全局锁，以执行相应的数据读取操作。

在另一种实现方式中，若当前创建的加锁节点和节点列表中已存在的加锁节点对应的锁类型均为写锁，或者包含读锁和写锁，由于存在写锁，则将导致数据源的变化，因此，此种情形下，可检测当前创建的加锁节点的编号是否为最小，若为最小可判定加锁成功，否则，判定加锁不成功。

本实施例中，通过区分应用终端10的加锁类型，将应用终端10的加锁类型区分为均为读锁、均为写锁、包含读锁和写锁的三种类型，从而针对不同类型分析在加锁时的具体情况，可以针对不同的应用场景采用适应性的判定标准，使得不同应用场景下的执行逻辑更加合理、科学。

本实施例中，应用终端10在创建加锁节点时，可通过相关的信息以对加锁节点进行标注，可选的，请参阅图6，可通过以下方式实现：

步骤S111，根据待创建的加锁节点对应的锁类型设置名称前缀。

步骤S112，按预设编号方式创建对应的加锁节点，并根据所述名称前缀为所述加锁节点设置节点名称。

本实施例中，若待创建的加锁节点对应的锁类型为读锁，相应地，可以read为名称前缀，按上述的预设编号方式创建对应的加锁节点，例如，可得到节点名称为read_000000000001的临时性顺序节点ephemeral_sequential。

应用终端10在成功获得全局锁后，可基于获得的全局锁为内部各线程设置内部锁。例如，在应用终端10获得全局的读锁时，则表明该应用终端10可从缓存服务器20中进行数据读取，而应用终端10内部包含多个线程，为各个线程设置锁类型为读锁的内部锁，则多个线程可实现并发读取操作。此外，在应用终端10获得全局的写锁时，则表明该应用终端10可向缓存服务器20进行数据写入。应用终端10可为内部各线程设置写锁的内部锁，使得各个线程可实现并发数据写入操作。

进一步地，在本实施例中，若某个应用终端10需要在数据读取和数据写入之间切换时，同样地，可以通过上述方式获得全局的读锁之后，完成数据读取操作。在进行全局读锁的释放时，同理，监测是否存在全局锁竞争，若存在全局锁竞争，则将内部锁和全局锁释放。若不存在全局锁竞争，则保留全局锁仅释放内部锁。在锁释放之后，再按上述方式进行全局的写锁的获取，在成功获得写锁之后，执行相应的数据写入操作。

为了能够更为清楚地对本申请提供的分布式锁实现方法的技术方案进行介绍，以下将结合具体的应用场景进行介绍：

假设分布式系统包含应用终端A和应用终端B，可相应地理解为实例instance A和实例instance B。作为一种可能的实施方式，在实例A和实例B均为数据读取实例时，可通过以下方式执行加锁和锁释放操作：

（1）实例A和实例B在构建锁实例Lock时，可创建zookeeper下的加锁节点（zookeeper节点）。创建时，实例A和实例B可分别判断是否存在zookeeper下的持久性节点的路径，若不存在，则可创建加锁节点，若存在，则需要等待；

（2）实例A或实例B在进行加读锁时，首先在持久性节点创建以read为前缀的ephemeral_sequential节点，自动生成的节点编号及名称可为read_000000000001。并且，获取持久性节点中的节点列表，如果当前创建的加锁节点编号为最小，或者是比当前加锁节点的编号更小的加锁节点的类型均为读锁时，可判定加锁成功，否则需要等待；

（3）在加锁成功后，通过zookeeper的监视器可监听节点列表中的信息变化，若监听到节点变化，则将全局锁内部的状态标识变更为true，即存在全局锁竞争；

（4）在实例A或实例B成功获取到zookeeper的全局读锁后，标记内存中的Lock对象为加读锁状态，并且给内部锁RW Lock加上读锁；

（5）在实例A或实例B的全局锁一致保持读锁状态时，可使用内部线程的内部读锁RWLock执行读取操作，无需与zookeeper进行锁信息交互；

（6）在实例A或实例B进行锁释放readUnLock时，判断内部contend状态，若为false表明不存在全局锁竞争，可释放内部锁RW Lock。若为true表明存在全局锁竞争，可释放内部锁RW Lock和全局锁Lock，并修改contend的状态为false，将全局锁Lock设置为未加锁状态，并删除创建的加锁节点read_000000000001。

在另一种实现方式中，若实例A和实例B均为数据写入实例时，可通过以下方式执行加锁和锁释放操作：

（1）实例A和实例B在构建锁实例Lock时，可创建zookeeper下的加锁节点（zookeeper节点）。创建时，实例A和实例B可分别判断是否存在zookeeper下的持久性节点的路径，若不存在，则可创建加锁节点，若存在，则需要等待；

（2）实例A或实例B在进行加写锁时，首先在持久性节点创建以write为前缀的ephemeral_sequential节点，自动生成的节点编号及名称可为write_000000000003。并且，获取持久性节点中的节点列表，如果当前创建的加锁节点编号为最小，可判定加锁成功，否则需要等待；

（3）在加锁成功后，通过zookeeper的监视器可监听节点列表中的信息变化，若监听到节点变化，则将全局锁内部的状态标识变更为true，即存在全局锁竞争；

（4）在实例A或实例B成功获得zookeeper的全局写锁后，标记内存中的Lock对象为加写锁状态，并且给RW Lock加上写锁；

（5）在实例A或实例B内存中的Lock对象一直为写锁状态时，可使用内部线程的内部写锁RW Lock执行读取操作，无需与zookeeper进行锁信息交互；

（6）在实例A或实例B进行锁释放writeUnLock时，判断内部contend状态，若为false表明不存在全局锁竞争，可释放内部锁RW Lock。若为true表明存在全局锁竞争，可释放内部锁RW Lock和全局锁Lock，并修改contend的状态为false，将全局锁Lock设置为未加锁状态，并删除创建的加锁节点read_000000000003。

在又一种实施方式中，若实例A为数据写入实例、实例B为数据读取实例，或者实例A为数据读取实例、实例B为数据写入实例。由于读写锁之间互斥，为了保证数据的强一致性，此种情形下的处理流程与上述实例A和实例B均为写锁类型时相同。

此外，在一种实施方式中，实例A或实例B内部读写锁切换时，则可按上述加读锁的方式进行全局读锁获得，只是在判定全局读锁是否加锁成功时，需要在其创建的加锁节点的编号为最小时，可判定加锁成功，否则需要等待。在进行全局读锁的释放时，其处理流程与上述的释放流程相同。在释放成功后，再按上述相同的全局写锁加锁的方式进行写锁加锁。

本申请所提供的分布式锁实现方案，在全局上，引入zookeeper作为全局唯一性的控制，在不存在全局锁竞争的情况下，应用终端10可仅释放内部锁保留全局锁，可保障数据的一致性的基础上，避免每次加锁均需与zookeeper进行锁信息交互，造成的对性能的影响的问题。此外，使用内部锁，可保障应用终端10的线程安全。

进一步地，划分系统中存在的锁类型，在没有读写竞争的情况下，即全部为读锁时，可只使用内部锁，以减少网络交互，保证分布式全局一致性的情况下减少网络交互，提升性能。

进一步地，通过zookeeper临时顺序节点判定加锁可保障每个实例都能获取到全局锁并避免实例宕机时锁释放缺陷的问题。

基于同一申请构思，本申请实施例中还提供了与分布式锁实现方法对应的分布式锁实现装置100，请参阅图7，由于本申请实施例中的装置解决问题的原理与本申请实施例上述分布式锁实现方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

请参阅图7，为本申请提供的一种分布式锁实现装置100的示意图，所述装置包括：监测模块110、第一释放模块120和第二释放模块130。

监测模块110，用于向所述缓存服务器20发送锁释放请求时，监测当前所述分布式系统中是否存在其他应用终端10向所述缓存服务器20发送过加锁请求。

可以理解，该监测模块110可以用于执行上述步骤S210，关于该监测模块110的详细实现方式可以参照上述对步骤S210有关的内容。

第一释放模块120，用于当前所述分布式系统中存在其他应用终端10向所述缓存服务器20发送过加锁请求，将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将所述全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点。

可以理解，该第一释放模块120可以用于执行上述步骤S220，关于该第一释放模块120的详细实现方式可以参照上述对步骤S220有关的内容。

第二释放模块130，用于当前所述分布式系统中不存在其他应用终端10向所述缓存服务器20发送过加锁请求，保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。

可以理解，该第二释放模块130可以用于执行上述步骤S230，关于该第二释放模块130的详细实现方式可以参照上述对步骤S230有关的内容。

在一种可能的实现方式中，上述分布式锁实现装置100还包括加锁模块，该加锁模块用于：

针对任一所述应用终端10，监测当前是否具有创建加锁节点的权限，若具有，则按预设顺序编号方式创建对应的加锁节点；

获取所述缓存服务器20的节点列表中已存在的加锁节点；

根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功；

若确定加锁成功，则获得对应的全局锁，并基于获得的全局锁为包含的各线程设置对应的内部锁。

在一种可能的实现方式中，当前创建的加锁节点和所述节点列表中已存在的加锁节点的锁类型均为读锁；

上述加锁模块具体可以用于：

检测当前创建的加锁节点的编号是否为最小，若为最小则判定加锁成功；

若不为最小，则查看所述节点列表中已存在的加锁节点中编号比当前创建的加锁节点的编号更小的加锁节点的锁类型是否为读锁，若为读锁，则判定加锁成功，否则判定加锁不成功。

在一种可能的实现方式中，当前创建的加锁节点和所述节点列表中已存在的加锁节点对应的锁类型均为写锁，或者包含读锁和写锁；

上述加锁模块具体可以用于：

所述根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功的步骤，还包括：

检测当前创建的加锁节点的编号是否为最小，若为最小则判定加锁成功，否则，判定加锁不成功。

在一种可能的实现方式中，上述加锁模块具体可以用于：

监测所述缓存服务器20中的用于管理节点列表的持久性节点的访问路径是否存在，若不存在，则判定具有创建加锁节点的权限，否则，不具有创建加锁节点的权限。

在一种可能的实现方式中，上述加锁模块具体可以用于：

根据待创建的加锁节点对应的锁类型设置名称前缀；

按预设编号方式创建对应的加锁节点，并根据所述名称前缀为所述加锁节点设置节点名称。

在一种可能的实现方式中，上述监测模块110具体可以用于：

获取所述缓存服务器20的监视器所监听到的所述缓存服务器20的节点列表信息；

在所述节点列表信息表征所述节点列表中新增加锁节点时，判定当前所述分布式系统中存在其他应用终端10向所述缓存服务器20发送过加锁请求。

请参阅图8，本申请实施例还提供了一种电子设备，该电子设备可为上述的应用终端10。该电子设备包括：处理器210、存储器220和总线230。所述存储器220存储有所述处理器210可执行的机器可读指令，当电子设备运行时，所述处理器210与所述存储器220之间通过总线230通信，所述机器可读指令被所述处理器210执行时执行如下处理：

一种可能的实施方式中，处理器210执行的指令中，包括如下过程：

向所述缓存服务器20发送锁释放请求时，监测当前所述分布式系统中是否存在其他应用终端10向所述缓存服务器20发送过加锁请求；

若存在，则将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将所述全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点；

若不存在，则保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。

关于电子设备运行时，处理器210执行的指令中所涉及的过程，可以参照上述方法实施例中的相关说明，这里不再详述。

综上所述，本申请提供的分布式锁实现方法、装置和电子设备，应用终端10在获得全局锁和内部锁的基础上，在进行锁释放时，可监测当前分布式系统中是否存在其他应用终端10向缓存服务器20发送过加锁请求，即是否存在全局竞争，若存在，则将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点。若不存在，则保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。如此，在不存在全局竞争的情况下，可保留全局锁仅对内部锁进行加锁或释放，可减少应用终端10与缓存服务器20之间的网络交互，提升系统性能。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种分布式锁实现方法，其特征在于，应用于包含多个应用终端的分布式系统中的任一应用终端，各所述应用终端与缓存服务器通信连接，各所述应用终端创建有多个线程，所述方法包括：

针对任一所述应用终端，向所述缓存服务器发送锁释放请求时，监测当前所述分布式系统中是否存在其他应用终端向所述缓存服务器发送过加锁请求；

若存在，则将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将所述全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点；

若不存在，则保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。

2.根据权利要求1所述的分布式锁实现方法，其特征在于，所述方法还包括预先获得全局锁和内部锁的步骤，该步骤包括：

针对任一所述应用终端，监测当前是否具有创建加锁节点的权限，若具有，则按预设顺序编号方式创建对应的加锁节点；

获取所述缓存服务器的节点列表中已存在的加锁节点；

根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功；

若确定加锁成功，则获得对应的全局锁，并基于获得的全局锁为包含的各线程设置对应的内部锁。

3.根据权利要求2所述的分布式锁实现方法，其特征在于，当前创建的加锁节点和所述节点列表中已存在的加锁节点的锁类型均为读锁；

所述根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功的步骤，包括：

检测当前创建的加锁节点的编号是否为最小，若为最小则判定加锁成功；

若不为最小，则查看所述节点列表中已存在的加锁节点中编号比当前创建的加锁节点的编号更小的加锁节点的锁类型是否为读锁，若为读锁，则判定加锁成功，否则判定加锁不成功。

4.根据权利要求2所述的分布式锁实现方法，其特征在于，当前创建的加锁节点和所述节点列表中已存在的加锁节点对应的锁类型均为写锁，或者包含读锁和写锁；

所述根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功的步骤，还包括：

检测当前创建的加锁节点的编号是否为最小，若为最小则判定加锁成功，否则，判定加锁不成功。

5.根据权利要求2所述的分布式锁实现方法，其特征在于，所述监测当前是否具有创建加锁节点的权限的步骤，包括：

监测所述缓存服务器中的用于管理节点列表的持久性节点的访问路径是否存在，若不存在，则判定具有创建加锁节点的权限，否则，不具有创建加锁节点的权限。

6.根据权利要求2所述的分布式锁实现方法，其特征在于，所述按预设顺序编号方式创建对应的加锁节点的步骤，包括：

根据待创建的加锁节点对应的锁类型设置名称前缀；

按预设编号方式创建对应的加锁节点，并根据所述名称前缀为所述加锁节点设置节点名称。

7.根据权利要求2所述的分布式锁实现方法，其特征在于，所述监测当前所述分布式系统中是否存在其他应用终端向所述缓存服务器发送过加锁请求的步骤，包括：

获取所述缓存服务器的监视器所监听到的所述缓存服务器的节点列表的信息；

在所述节点列表的信息表征所述节点列表中新增加锁节点时，判定当前所述分布式系统中存在其他应用终端向所述缓存服务器发送过加锁请求。

8.一种分布式锁实现装置，其特征在于，应用于包含多个应用终端的分布式系统中的任一应用终端，各所述应用终端与缓存服务器通信连接，各所述应用终端创建有多个线程，所述装置包括：

监测模块，用于向所述缓存服务器发送锁释放请求时，监测当前所述分布式系统中是否存在其他应用终端向所述缓存服务器发送过加锁请求；

第一释放模块，用于当前所述分布式系统中存在其他应用终端向所述缓存服务器发送过加锁请求，将自身对应的全局锁以及自身包含的各线程对应的内部锁进行释放，并将所述全局锁设置为未加锁状态，删除自身在进行加锁时所创建的加锁节点；

第二释放模块，用于当前所述分布式系统中不存在其他应用终端向所述缓存服务器发送过加锁请求，保留自身对应的全局锁并将自身包含的各线程对应的内部锁进行释放。

9.根据权利要求8所述的分布式锁实现装置，其特征在于，所述装置还包括加锁模块，用于：

针对任一所述应用终端，监测当前是否具有创建加锁节点的权限，若具有，则按预设顺序编号方式创建对应的加锁节点；

获取所述缓存服务器的节点列表中已存在的加锁节点；

根据当前创建的加锁节点对应的锁类型以及所述节点列表中已存在的加锁节点的锁类型，判断是否加锁成功；

若确定加锁成功，则获得对应的全局锁，并基于获得的全局锁为包含的各线程设置对应的内部锁。

10.一种电子设备，其特征在于，包括一个或多个存储介质和一个或多个与存储介质通信的处理器，一个或多个存储介质存储有处理器可执行的机器可执行指令，当电子设备运行时，处理器执行所述机器可执行指令，以执行权利要求1-7中任意一项所述的方法步骤。

Images