CN113342507A - 一种分布式锁服务实现方法、装置及计算机设备 - Google Patents

Abstract

本发明公开一种分布式锁服务实现方法、装置及计算机设备，该方法包括：接收客户端发送的上锁请求，上锁请求中携带有租约信息以及租约信息对应的至少一个上锁资源；获取预先配置的各个锁之间是否存在冲突的冲突类型配置信息；根据冲突类型配置信息，确定是否为上锁请求中上锁资源发起上锁请求，其中如果上锁不存在冲突则发起上锁请求、如果上锁存在冲突则不发起上锁请求。本发明能够避免锁竞争，同时提高数据操作性能以及系统吞吐量，且具有实现方法简单、锁粒度小、效率高以及灵活性强等优点。

Description

一种分布式锁服务实现方法、装置及计算机设备

技术领域

本发明涉及互联网技术领域，尤其涉及一种分布式锁服务实现方法、装置及计算机设备。

背景技术

在分布式系统中，如果不同的系统或者同一个系统的不同主机之间共享了一个或者一组资源，那么在访问这些资源的时候，往往需要配置为互斥，防止彼此干扰以保证一致性，为实现该功能及需要使用分布式锁。分布式锁一般具有以下特点：

(1)互斥性。即同一时刻只有一个线程能获取到锁。

(2)可重入性。即同一个节点上的同一个线程如果获取到了锁，那么也可以再次获取到这个锁。

(3)锁超时。即锁超时之后会自动释放锁，防止死锁。

(4)支持阻塞和非阻塞。即可以指定超时时间返回，在超时时间内，获取到锁立即返回获取成功，超时后则返回获取锁失败。

目前，常用的分布式锁服务实现主要为redis、zookeeper、etcd等，但是这些分布式锁中锁的粒度是固定的，由于分布式锁服务具有互斥性，因而当一个进程获取到一个资源的锁之后，其他进程则无法获取到被上锁资源的锁。而在实际应用场景中，上锁并不仅仅只有互斥的情况，锁之间也可能并不是互斥的，采用传统的分布式锁时极易使得上锁时发生冲突、锁竞争等情况，降低分布式锁系统的吞吐量。如某些读取场景中，虽然读取操作和写入操作是互斥的，但是读取和读取操作之间并不是互斥的，此时如果对读取操作使用传统的分布式锁，则会使得读取和读取操作之间也是互斥，这会大大降低读取性能。

针对上述问题，有从业者提出使用设置锁权限的方式来实现分布式锁管理，即每次在接收到加锁请求时，依据锁权限配置判断请求锁的权限是否与最高等级冲突，如果不冲突则授予锁权限。这类方式虽然可以依据设置的锁权限来管理分布式锁，但是每次仅能够授权最高等级的锁，对于不是最高等级的锁，无论是否互斥仍然无法获得授权，即仍然会存在当锁之间并不存在冲突时却会形成互斥的问题，且上述基于权限的锁判断粒度依然很大，无法适用于一些没有权限高低区分的分布式锁请求场景。

发明内容

本发明要解决的技术问题就在于：针对现有技术存在的技术问题，本发明提供一种能够避免锁竞争，同时提高数据操作性能以及系统吞吐量，且实现方法简单、锁粒度小、效率高以及灵活性强的分布式锁服务实现方法、装置及系统。

为解决上述技术问题，本发明提出的技术方案为：

一种分布式锁服务实现方法，包括：

接收客户端发送的上锁请求，所述上锁请求中携带有租约信息以及所述租约信息对应的至少一个上锁资源；

获取预先配置的各个锁之间是否存在冲突的冲突类型配置信息；

根据所述冲突类型配置信息，确定是否为所述上锁请求中所述上锁资源发起上锁请求，其中如果上锁不存在冲突则发起上锁请求、如果上锁存在冲突则不发起上锁请求。

进一步的，所述根据所述冲突类型配置信息，确定是否为所述上锁请求中所述上锁资源发起上锁请求，包括：

检查所述上锁资源是否已被获取；

当所述被上锁资源已被获取时，提取所述上锁资源的上锁状态；

比对所述上锁状态中的上锁线程与本次上锁使用的线程，确定是否线程重入；

若确定线程未重入，则根据所述冲突类型配置信息检查上锁是否冲突，在确定上锁不冲突时发起上锁请求，否则反馈上锁失败信息；

若确定线程重入，则反馈上锁成功的信息。

进一步的，所述方法还包括：

当确定所述上锁资源未被获取时，向分布式锁中间件发送携带有所述上锁资源以及上锁的超时时间的上锁请求，使得所述分布式锁中间件根据所述超时时间对所述被上锁资源进行上锁；

接收所述分布式锁中间件的反馈信息，根据所述反馈信息进行上锁反馈。

进一步的，在上锁成功之后，所述方法还包括：

定期检查当前所有锁的超时状态；

如果存在待续约锁处于超时状态，且存在未超时的线程共享所述待续约锁，则向分布式锁中间件发送锁续约请求，以使得所述分布式锁中间件更新所述待续约锁的状态。

进一步的，所述定期检查当前所有锁的超时状态包括：

接收心跳信息续约请求，所述心跳信息续约请求由占用锁的所述客户端定期发送；

根据所述心跳信息续约请求中心跳信息是否超时，判断锁的超时状态。

进一步的，该方法还包括：

获取预先配置的链表；

由所述链表中的每个元素作为一个桶，将所述租约信息按照过期时间远近依次存放在所述链表的各个桶中；

当接收到锁续约请求时，将所述锁续约请求对应的锁的租约信息从所述链表的桶中取出，移动至新的桶中以更新锁的租约信息。

进一步的，该方法还包括：

将过期时间相距在预设范围以内的多个锁的所述租约信息存放在所述链表中同一个桶中；

定期检查所述链表的桶中所述租约信息是否过期，如果过期则把整个桶的租约信息所对应的锁全部释放。

进一步的，所述方法还包括：

接收到包括待释放锁的释放锁请求后，检查本地是否存在所述待释放锁的状态信息；

当不存在时，返回释放成功信息；

当存在时，清除本次所述待释放锁的线程以及所述待释放锁的状态信息，并判断清除后所述待释放锁是否还被其他线程占用；

如果判断到没有其他线程占用所述待释放锁，发送释放锁请求给分布式锁中间件，以使得所述分布式锁中间件释放所述待释放锁，如果判断到还有其他线程占用所述待释放锁，反馈释放锁成功信息。

进一步的，该方法还包括：每当上锁成功后记录上锁状态，并在重启后，接收客户端发送的上锁状态信息，将接收到的所述上锁状态信息进行同步更新以完成数据恢复。

一种分布式锁服务实现装置，包括：

接收模块，用于接收客户端发送的上锁请求，所述上锁请求中携带有租约信息以及所述租约信息对应的至少一个上锁资源；

获取模块，用于获取预先配置的各个锁之间是否存在冲突的冲突类型配置信息；

上锁控制模块，用于根据所述冲突类型配置信息，确定是否为所述上锁请求中所述上锁资源发起上锁请求，其中如果上锁不存在冲突则发起上锁请求、如果上锁存在冲突则不发起上锁请求。

一种计算机设备，包括处理器以及存储器，所述存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，所述处理器用于执行所述计算机程序以执行如上述方法。

与现有技术相比，本发明的优点在于：

1、本发明通过获取预先配置的不同锁之间是否存在冲突的冲突类型配置信息，在上锁时根据配置的冲突类型配置信息确定是否发送上锁请求，仅是存在冲突的锁之间会发生互斥、不存在冲突的锁之间不会发生互斥，使得不存在冲突的锁之间能够同时使用，减少上锁时的不必要的冲突及竞争，有效降低锁的粒度。

2、本发明基于租约实现分布式锁服务，上锁请求中有租约信息以及租约信息对应的至少一个上锁资源，一次上锁请求可以支持一个租约同时多个上锁资源上锁，能够减少网络传输次数以及传输数据量，节省网络带宽，且便于批量上锁时灵活配置，以实现全部获取到锁、获取到尽可能多的锁等各种上锁策略。

附图说明

图1是本发明实施例分布式锁服务实现方法的应用场景示意图。

图2是本实施例分布式锁服务实现方法的实现流程示意图。

图3是本发明在具体应用实施例中冲突类型配置原理示意图。

图4是本发明在具体应用实施例中实现分布式锁服务时交互时序示意图。

图5是本发明在具体应用实施例中实现分布式锁服务时交互流程示意图。

图6是本实施例中分布式锁服务系统的结构原理示意图。

具体实施方式

以下结合说明书附图和具体优选的实施例对本发明作进一步描述，但并不因此而限制本发明的保护范围。

如图1所示，本发明分布式锁服务实现方法的一类应用前景为图数据库的数据操作。在图数据库的数据操作过程中，通常使用HBase和Elasticsearch作为图数据存储后端，其特性为：属性数据会存储在HBase和Elasticsearch中，而关系数据只会存储在HBase中。受制于数据库本身的特性，在使用过程中存在如下冲突关系：同一个节点的属性写入冲突，节点的“属性写入”与“节点删除”冲突，“关系写入”与“节点删除”冲突等。

基于上述冲突关系，本实施例首先在分布式锁服务中定义属性操作锁、关系操作锁以及删除节点锁。其中，属性操作锁与属性操作锁、删除节点锁冲突，关系操作锁与删除节点锁冲突，这样就可以通过分布式锁服务统一获取锁，然后继续下一步的操作。本发明通过对锁粒度进行自定义和细化，大大降低了锁的冲突几率，提高了对图数据库操作的吞吐量。

如图2所示，本实施例分布式锁服务实现方法的步骤包括：

步骤S1.接收客户端发送的上锁请求，上锁请求中携带有租约信息以及租约信息对应的至少一个上锁资源；

步骤S2.获取预先配置的各个锁之间是否存在冲突的冲突类型配置信息；

步骤S3.根据冲突类型配置信息，确定是否为上锁请求中上锁资源发起上锁请求，其中如果上锁不存在冲突则发起上锁请求、如果上锁存在冲突则不发起上锁请求。

本实施例通过预先配置不同锁之间是否存在冲突的冲突类型，在上锁时根据配置的冲突类型确定是否发送上锁请求，仅是存在冲突的锁之间会发生互斥、不存在冲突的锁之间不会发生互斥，使得不存在冲突的锁之间能够同时使用，减少上锁时的不必要的冲突及竞争，有效降低锁的粒度；同时一次上锁请求可以支持一个租约同时给多个上锁资源上锁，能够减少网络传输次数以及传输数据量，节省网络带宽，且便于批量上锁时灵活配置，以实现全部获取到锁、获取到尽可能多的锁等各种上锁策略。

本实施例中，租约信息具体为锁的超时时间，可以使用随机不重复的字符串来表示。租约信息具体可按照过期时间的远近顺序存储在一个预设的链表中，通过更新链表中各元素的位置即可更新锁的租约信息。在具体应用实施例中，设置链表后，由链表中的每个元素作为一个桶，依次存放一批过期时间接近的租约，链表中越靠前位置的桶的过期时间越近，过期时间相近的租约存在同一个桶中，需要对即将超过有效时间的租约更新时，从链表靠前位置的桶中取出对应的租约，再移动到链表尾部的桶中。具体可在服务端存储上述租约信息链表，以依据链表中租约信息控制上锁。

上述上锁资源具体应用时即为锁的名字，在请求锁的时候会发送一个锁的名字，所有线程通过锁的名字来竞争锁，如果某个线程获取锁成功，则对于该线程即是获取到锁资源。例如，当需要给数据库中的一条记录上锁式，那么可以使用该记录的唯一ID号作为上锁资源。

本实施例步骤S2中配置冲突类型时，可依据实际需求设置锁与锁之间是否存在冲突，如可配置读锁和读锁之间是不冲突的，写锁和写锁之间是冲突的，读锁和写锁之间是冲突的等。本实施例中锁具体分为：HBase(Hadoop Database，分布式存储系统)写锁、通用数据写锁以及数据删除锁，配置的冲突类型具体为：HBase写锁只和数据删除锁冲突，通用数据写锁和通用数据写锁以及数据删除锁冲突，以及数据删除锁和所有锁冲突，具体可根据实际需求调整或增减类型设置。上述配置具体可采用properties配置文件形式，由key表示锁类型，值为与其冲突的锁类型。

如图3所示，在具体应用实施例中数据存储在HBase和Elasticsearch中，HBase用于存储海量数据以提供多副本，Elasticsearch用于快速全文检索。若一份数据中有较多字段不需要进行全文检索，则这些字段不会存储在Elasticsearch中，而只会存储在HBase中。如图3中的通用数据插入表示该数据中的所有字段都是要插入到HBase，同时插入到Elasticsearch中，而HBase数据插入则表示该数据只需要插入到HBase中，不需要插入到Elasticsearch，通用数据删除则表示既要删除HBase中的数据，也需要删除Elasticsearch中的数据。在上述场景下，在数据插入或者删除时，需要向分布式锁服务请求获取被插入或者删除数据的ID的锁。如果在上述基础上只使用传统的分布式锁，则会造成锁竞争严重，如在写入通用数据的时候，获取了某个ID的锁，则该ID就不能再写入HBase特有字段，而实际上该两个步骤是可以同时进行的。

本实施例通过将锁的类型分为HBase写锁、通用数据写锁、数据删除锁，定义冲突类型为HBase写锁与数据删除锁冲突，通用数据写锁与通用数据写锁、数据删除锁冲突，以及数据删除锁与所有锁都冲突，使得在HBase数据写入的时候，相同ID也可以并发写入，同时又能够防止数据删除获取到锁导致写入数据的ID被删除，而在通用数据写入的时候，能够防止其他线程也对相同的ID写入和删除，避免产生HBase和Elasticsearch数据不一致的情况，由于允许HBase数据的写入，还可以增加写入数据并发。

在一个实施例中，上述步骤S3的具体步骤包括：

步骤S301.检查上锁资源是否已被获取；

步骤S302.当被上锁资源已被获取时，提取上锁资源的上锁状态；

步骤S303.比对上锁状态中的上锁线程与本次上锁使用的线程，确定是否线程重入；

步骤S304.若确定线程未重入，则根据冲突类型配置信息检查上锁是否冲突，在确定上锁不冲突时发起上锁请求，否则反馈上锁失败信息；

步骤S305.若确定线程重入，则反馈上锁成功的信息。

本实施例通过上述步骤，每当接收到上锁请求时，结合请求的锁的获取状态、是否是相同线程重入的判断确定是否需要上锁，同时结合配置的冲突类型检测上锁资源是否存在冲突，最终确定是否发送上锁请求，能够使得不存在冲突的锁同时使用，减少上锁时的不必要的冲突及竞争，同时还可支持线程重入，提高分布式锁的灵活性。

在一个实施例中，上述分布式锁服务实现方法还包括：

步骤S306.当确定上锁资源未被获取时，向分布式锁中间件发送携带有上锁资源以及上锁的超时时间的上锁请求，使得分布式锁中间件根据所述超时时间对被上锁资源进行上锁；

步骤S307.接收分布式锁中间件的反馈信息，根据反馈信息进行上锁反馈。

在具体应用实施例中，如图4、5所示，服务端接收客户端的上锁请求时，由服务端处理上锁请求，服务端处理上锁请求的详细步骤为：

检查服务端内存中是否包含本次需要上锁的资源，如果没有查询到，则判定为请求的锁未被获取，否则判定为请求的锁已被获取；

如果判定为请求的锁未被获取，向分布式锁中间件发起上锁请求，请求内容包括上锁资源、超时时间等，其中由请求中超时时间确定各请求锁的有效时间，如果分布式锁中间件返回上锁成功，则在服务端内存中记录该锁的状态，并构造上锁成功的对象返回给客户端；客户端缓存上锁成功对象，并返回上锁成功信息；如果分布式锁中间件返回上锁失败，则返回上锁失败信息；

如果判定为请求的锁已被获取，则取出被上锁资源的上锁状态，对比上锁状态中的上锁线程和本次上锁的线程是否一致，如果一致，即为线程的重入，返回上锁成功对象给客户端，客户端缓存上锁成功对象，同时返回上锁成功信息；如果不是同一个线程，则检查本次上锁的冲突类型和已上锁状态中的冲突类型，如果两次锁类型不冲突，则修改锁的状态增加本次上锁信息，并构造上锁成功对象给客户端，返回上锁成功信息，如果两次锁类型冲突，则构造上锁失败对象给客户端，返回上锁失败信息。

在一个实施例中，在上锁成功之后，上述分布式锁服务时限方法还包括锁续约处理步骤S4，步骤S4的具体步骤包括：

步骤S401.定期检查当前所有锁的超时状态；

步骤S402.如果存在待续约锁处于超时状态，且存在未超时的线程共享待续约锁，则向分布式锁中间件发送锁续约请求，以使得分布式锁中间件更新待续约锁的状态。

由于传统分布式锁具有锁超时特性，即在超时后即自动释放锁，但是这类方式锁的有效时间是固定不变的，只能维持锁在特定时长，若超时后仍需上锁，则需要重新发送上锁请求而重新上锁，致使需要频繁的执行上锁、释放锁操作，且无法在锁超时后及时的恢复上锁状态，同样也会影响分布式锁系统的吞吐量。本实施例通过依据各锁的超时状态以及线程共享状态等确定是否需要续约，使得能够监控所有锁的超时状态，在锁超时后能够及时续约而无需重新申请上锁，避免频繁的上锁操作，从而有效提高分布式锁系统的吞吐量。

本实施例中租约信息的租续约具体包括：获取预先配置的链表，由链表中的每个元素作为一个桶，将租约信息按照过期时间远近依次存放在所述链表的各个桶中，当接收到锁续约请求时，将锁续约请求对应的锁的租约信息从链表的桶中取出，移动至新的桶中以更新锁的租约信息。其中，各个桶对应不同的过期时间段，将锁的租约信息从原桶中取出移动至新的桶更新所的租约信息即刷新对应锁的过期时间状态，如具体可将续约请求对应锁的租约信息从链表中取出，并移动至链表中对应最远过期时间的位置处，以更新至当前最晚过期的位置。

本实施例中，上述步骤S401定期检查当前所有锁的超时状态的步骤具体包括：

步骤S411.接收心跳信息续约请求，心跳信息续约请求由占用锁的客户端定期发送；

步骤S412.根据心跳信息续约请求中心跳信息是否超时，判断锁的超时状态。

由于上锁成功后，需要占用锁的时间不确定，本实施例具体由客户端守护线程调用服务端续约，定期向服务端发送心跳信息以进行锁续约，如果长时间没有心跳信息发送给服务端，服务端会判定客户端已经宕机，则对应的该客户端获取到的锁需要被释放以防止死锁；服务端接收到心跳信息后，则更新上锁资源状态中的心跳信息。同时由服务端守护线程续约，服务端定期检查缓存中的所有锁的超时状态，对于已经超时的锁执行清除，对于剩下的在一定时间内有效的锁则请求一次或预设次数分布式锁中间件以执行续约。

在具体应用实施例中，服务端处理上锁请求以及续约请求的详细步骤为：

由客户端在申请锁之前生成租约信息，然后将租约信息、上锁资源、上锁的类型、上锁策略等信息发送给服务端；

服务端接收到请求后，根据预先配置的冲突类型以及优先级，判断是否能够加锁成功，其中优先级对应表示不同锁的优先级别，对于处于优先级高的锁，优先发送上锁请求，如果加锁成功，则记录客户端发送的租约信息和上锁资源、上锁类型，并返回客户端上锁成功的信息，其中上锁类型对应即为锁的具体操作类型，如读锁、写锁等类型；

客户端根据需求调用服务端获取锁，获取锁时即将上锁的参数传递给服务端，由服务端处理上锁请求，上锁的参数具体包括上锁资源、锁的冲突类型、上锁的线程、上锁的超时时间等；客户端在接到上锁成功的信息后，在本地记录租约和上锁资源的映射关系，即哪些上锁资源对应哪些租约信息；

客户端定时检查自己占用的租约，发送需要续约的租约信息到服务端，申请续约；

服务端收到续约的租约信息后，将需要续约的租约过期时间刷新。

通过上述步骤，能够实时监控所有锁的超时状态，在锁超时后能够及时、高效的完成续约而无需重新申请上锁，避免频繁的上锁操作，有效提高分布式锁系统的吞吐量。

在一个实施例中，上述分布式锁服务实现方法还包括释放锁步骤S5，步骤S5的步骤具体包括：

步骤S501.接收到包括待释放锁的释放锁请求后，检查本地是否存在待释放锁的状态信息；

步骤S502.当不存在时，返回释放成功信息；

步骤S503.当存在时，清除本次待释放锁的线程以及所述待释放锁的状态信息，并判断清除后待释放锁是否还被其他线程占用；

步骤S504.如果判断到没有其他线程占用待释放锁，发送释放锁请求给分布式锁中间件，以使得分布式锁中间件释放待释放锁，如果判断到还有其他线程占用所述待释放锁，反馈释放锁成功信息。

本实施例具体对于接收到释放锁请求需要释放的锁，按照上述步骤进行释放；对于超期的锁，则对所有上锁租约采用按照过期时间段进行分桶管理的方式，将过期时间相近，即过期时间相距在预设范围内的租约放到同一个桶中，锁超时状态判断时每次检查最后一个桶的租约是否过期，如果过期则直接把整个桶的租约对应的锁全部释放。通过结合对所有上锁租约采用按照过期时间段进行分桶管理的方式，将过期时间相近的租约放到同一个桶中，由于锁超时状态判断时每次只需要检查最后一个桶的租约是否过期，如果过期则可以直接把整个桶的租约对应的锁全部释放，而无需依次遍历各个锁进行超时判断，可以实现快速、高效的锁释放，而如果需续约仅需移动链表中租约存储位置，因而可以快速、高效的进行锁续约。

在具体应用实施例中，如图4、5所示，服务端接收到释放锁请求后，处理释放锁请求的详细步骤为：先检查是否有该锁的状态信息，也即检查是否已经上锁，如果没有则表明没有上锁，无需释放锁，对于释放锁而言也即是释放锁成功，直接返回释放锁成功给客户端；如果服务端有锁的状态信息，即已上锁，则修改内存中当前锁的状态，即增加锁的上锁次数，然后清除本次释放锁的线程、本次释放锁的锁类型相关的状态信息，如果清除后还有其他线程在占用该锁，此时对于占用的线程而言是释放锁成功的，则直接返回成功，如果没有其他线程占用该锁，表明需要执行释放锁，则请求一次分布式锁中间件，释放该锁，并清除该锁在服务端的所有缓存，返回释放成功给客户端。

本实施例上述分布式锁服务实现方法还包括：每当上锁成功后记录上锁状态，并在重启后，接收客户端发送的上锁状态信息，将接收到的所述上锁状态信息进行同步更新以完成数据恢复。即采用分布式存储方式存储所有锁的状态信息，分别在客户端、服务端记录上锁状态，当服务端重启后，将客户端记录的上锁状态同步到服务端以恢复服务端的功能，以实现去中心化的分布式锁管理服务。上述锁状态具体包括被锁住的资源、锁的获取时间、获取线程、锁的冲突类型、每个线程的租约信息、锁的最后一次心跳时间等各类所需的锁状态信息，由服务端维护锁的所有状态信息。

传统分布式锁管理服务需要依赖于服务端管理锁状态，当服务端宕机时，所有的锁状态都将失效，分布式锁服务将不可用，已经获取到的锁也会失效，会造成锁管理不正确、影响业务逻辑等问题。本实施例通过去中心化的分布式锁管理服务，使得不需要依赖于服务端的状态，即使服务端宕机，在服务端重启之后，也可以通过客户端记录的上锁状态同步到服务端之后，重新恢复服务端的功能。

以下以在具体应用实施例中采用本发明上述方法实现分布式锁服务的详细步骤为例，对本发明进行进一步说明。

如图4、5所示，本实施例实现分布式锁服务实现的详细步骤为：

步骤1.配置冲突类型：由用户定义锁的冲突类型，如读锁和读锁之间是不冲突的、写锁和写锁之间是冲突的、读锁和写锁之间是冲突的。具体可将锁的类型分为HBase写锁、通用数据写锁、数据删除锁，定义冲突类型为HBase写锁与数据删除锁冲突，通用数据写锁与通用数据写锁、数据删除锁冲突，以及数据删除锁与所有锁都冲突。

步骤2.启动分布式锁中间件，由分布式锁中间件主要提供分布式锁服务，当服务端中没有请求锁的状态时，需要请求分布式锁中间件来获取锁。

步骤3.根据配置的冲突类型、分布式锁中间件的地址启动服务端，服务端维护锁的所有状态信息，包括被锁住的资源、锁的获取时间、获取线程、锁的冲突类型、每个线程的租约信息、锁的最后一次心跳时间等各类所需的锁状态信息等各类所需的锁状态信息。

步骤4.客户端根据需求调用服务端获取锁，将上锁的参数传递给服务端，由服务端处理上锁请求，上锁的参数包括上锁资源、锁的类型、锁的冲突类型、每个线程的租约信息等各类上锁所需信息。

步骤5.服务端接收到客户端的上锁请求后，执行如下操作：

步骤5.1.检查服务端内存中是否包含本次需要上锁的资源，如果没有查询到则判定为请求的锁未被获取，执行步骤5.2，否则判定为请求的锁已被获取并执行步骤5.3；

步骤5.2.向分布式锁中间件发起上锁请求，请求内容包括被上锁的资源、超时时间等上锁所需的各类信息，其中由请求中超时时间确定各请求锁的有效时间，如果分布式锁中间件返回上锁成功，则在服务端内存中记录该锁的状态，并构造上锁成功的对象返回给客户端，客户端缓存上锁成功对象，并返回上锁成功信息；如果分布式锁中间件返回上锁失败，服务端会返回上锁失败给客户端。

步骤5.3.取出被上锁资源的上锁状态，对比上锁状态中的上锁线程和本次上锁的线程是否一致，如果是一致的，表示是线程的重入，返回上锁成功对象给客户端，客户端会缓存上锁成功对象，同时返回上锁成功信息。如果不是同一个线程，则检查本次上锁的冲突类型和已上锁状态中的冲突类型，如果两次锁类型不冲突，则修改锁的状态增加本次上锁信息，并构造上锁成功对象给客户端，返回上锁成功信息。如果两次锁类型冲突，则构造上锁失败对象给客户端，返回上锁失败信息。

步骤6.客户端根据需求调用锁服务释放锁，服务端先检查是否有该锁的状态信息，也即检查是否已经上锁，如果没有则表明没有上锁，无需释放锁，对于释放锁而言也即是释放锁成功，直接返回释放锁成功给客户端；如果服务端有锁的状态信息，即已上锁，则修改内存中当前锁的状态，即增加锁的上锁次数，然后清除本次释放锁的线程、本次释放锁的锁类型相关的状态信息，如果清除后还有其他线程在占用该锁，此时对于占用的线程而言是释放锁成功的，则直接返回成功，如果没有其他线程占用该锁，表明需要执行释放锁，则请求一次分布式锁中间件，释放该锁，并清除该锁在服务端的所有缓存，返回释放成功给客户端。

步骤7.客户端守护线程调用服务端续约，定期向服务端发送心跳信息续约，如果长时间没有心跳信息发送给服务端，释放对应的锁以防止死锁；服务端接收到心跳信息后，更新上锁资源状态中的心跳信息。

步骤8.服务端守护线程续约，定期检查缓存中的所有锁状态，对于超过心跳时间的锁状态信息执行清除，对于剩下的在预设时长内有心跳信息的锁会请求一次分布式锁中间件执行续约。

步骤9.查看锁的获取状态，获取当前所有锁的状态，包括被锁住的资源、锁的获取时间、获取线程、锁的冲突类型、每个线程的租约信息、锁的最后一次心跳时间等各类所需的锁状态信息等各类所需的锁状态信息。

经过上述步骤，可灵活配置冲突类型，使得不存在冲突的锁之间能够同时使用，减少上锁时的不必要的冲突及竞争，降低锁的粒度，同时能够监控所有锁的超时状态，在锁超时后能够及时续约而无需重新申请上锁，避免频繁的上锁操作，从而有效提高分布式锁系统的吞吐量。

为实现上述方法，本实施例分布式锁服务装置包括：

配置模块，用于配置不同锁之间的冲突类型，启动分布式锁服务；

锁服务模块，用于接收上锁请求，上锁请求中携带有需要上锁的资源、请求的锁的类型以及租约信息，租约信息包括请求的锁的有效时间，根据配置的冲突类型确定是否修改锁状态，当上锁成功时修改租约信息与上锁资源之间的映射关系；

续约控制模块，用于检查所有锁的超时状态，根据各锁的租约信息、租约信息与上锁资源之间的映射关系以及各线程之间共享锁的状态，判断是否需要生成锁的续约请求，根据续约请求刷新对应锁的有效时间。

本实施例中，锁服务模块包括上锁控制单元，上锁控制单元用于判断请求的锁的状态，如果请求的锁已被获取且不是相同线程重入，则按照配置的冲突类型检测上锁资源是否有冲突，以及在没有冲突时进行上锁。

上述锁服务模块具体包括：

接收模块，用于接收客户端发送的上锁请求，上锁请求中携带有租约信息以及租约信息对应的至少一个上锁资源；

获取模块，用于获取预先配置的各个锁之间是否存在冲突的冲突类型配置信息；

上锁控制模块，用于根据冲突类型配置信息，确定是否为所述上锁请求中所述上锁资源发起上锁请求，其中如果上锁不存在冲突则发起上锁请求、如果上锁存在冲突则不发起上锁请求。

本实施例分布式锁服务装置与上述分布式锁服务实现方法为一一对应，在此不再一一赘述。

如图6所示，在另一实施例中，为实现上述分布式锁服务实现方法，本实施例进一步提供分布式锁系统，该分布式锁系统包括：

客户端，用于将所需的锁服务请求发送给服务端，以及接收服务端返回的锁服务处理结果；

服务端，用于接收客户端发送的锁服务请求，按照上述分布式锁服务实现方法执行分布式锁服务。

如图6所示，在具体应用实施例中，上述客户端具体包括：

第一请求处理模块，用于处理获取锁请求或者释放锁请求，并将请求发送给服务端的第二请求处理模块，然后将服务端的请求结果发送给第一锁缓存模块；

第一锁缓存模块，用于缓存上锁成功的锁信息，并清除释放锁的锁信息；

第一续约处理模块，用于对缓存中的锁，调用服务端的第二续约处理模块进行续约处理，以防止心跳超时服务端释放锁。

上述服务端具体包括：

第二请求处理模块，用于接收客户端发送的上锁、释放锁请求，并调用第二锁缓存模块检查锁状态，发送需要请求分布式锁中间件的操作；

第二锁缓存模块，用于保存所有锁的状态信息，并提供状态查询功能；

第二续约处理模块，用于查询第二锁缓存模块中需要续约的锁，调用分布式中间件执行续约；

第二锁状态输出模块，用于调用第二锁缓存模块，获取缓存中锁的状态信息输出，统计包括上锁时间、上锁线程、上锁资源等信息，进一步还可以检测是否有死锁的情况，一击允许直接调用锁释放功能等。

本实施例进一步还包括分布式锁中间件，由分布式锁中间件提供分布式锁功能，保证服务端只能获取到一次锁，支持服务端续约，防止死锁。分布式锁中间件模块具体可以根据实际需求使用redis、zookeeper、mysql、etcd等来实现分布式锁功能。

本实施例中还提供计算机设备，该计算机设备包括处理器以及存储器，存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，所述处理器用于执行所述计算机程序以执行如上述分布式锁服务实现方法。

本领域技术人员可以理解，上述计算机装置的描述仅仅是示例，并不构成对计算机装置的限定，可以包括比上述描述更多或更少的部件，或者组合某些部件，或者不同的部件，例如可以包括输入输出设备、网络接入设备、总线等。所称处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。

所述存储器可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述计算机装置的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(FlashCard)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

所述计算机装置集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个基于模板标注的分布式爬虫方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信号以及软件分发介质等。

上述只是本发明的较佳实施例，并非对本发明作任何形式上的限制。虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明。因此，凡是未脱离本发明技术方案的内容，依据本发明技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均应落在本发明技术方案保护的范围内。

Claims (11)

1.一种分布式锁服务实现方法，其特征在于，包括：

接收客户端发送的上锁请求，所述上锁请求中携带有租约信息以及所述租约信息对应的至少一个上锁资源；

获取预先配置的各个锁之间是否存在冲突的冲突类型配置信息；

根据所述冲突类型配置信息，确定是否为所述上锁请求中所述上锁资源发起上锁请求，其中如果上锁不存在冲突则发起上锁请求、如果上锁存在冲突则不发起上锁请求。

2.根据权利要求1所述的分布式锁服务实现方法，其特征在于，所述根据所述冲突类型配置信息，确定是否为所述上锁请求中所述上锁资源发起上锁请求，包括：

检查所述上锁资源是否已被获取；

当所述被上锁资源已被获取时，提取所述上锁资源的上锁状态；

比对所述上锁状态中的上锁线程与本次上锁使用的线程，确定是否线程重入；

若确定线程未重入，则根据所述冲突类型配置信息检查上锁是否冲突，在确定上锁不冲突时发起上锁请求，否则反馈上锁失败信息；

若确定线程重入，则反馈上锁成功的信息。

3.根据权利要求2所述的分布式锁服务实现方法，其特征在于，所述方法还包括：

当确定所述上锁资源未被获取时，向分布式锁中间件发送携带有所述上锁资源以及上锁的超时时间的上锁请求，使得所述分布式锁中间件根据所述超时时间对所述被上锁资源进行上锁；

接收所述分布式锁中间件的反馈信息，根据所述反馈信息进行上锁反馈。

4.根据权利要求1所述的分布式锁服务实现方法，其特征在于，在上锁成功之后，所述方法还包括：

定期检查当前所有锁的超时状态；

如果存在待续约锁处于超时状态，且存在未超时的线程共享所述待续约锁，则向分布式锁中间件发送锁续约请求，以使得所述分布式锁中间件更新所述待续约锁的状态。

5.根据权利要求4所述的分布式锁服务实现方法，其特征在于，所述定期检查当前所有锁的超时状态包括：

接收心跳信息续约请求，所述心跳信息续约请求由占用锁的所述客户端定期发送；

根据所述心跳信息续约请求中心跳信息是否超时，判断锁的超时状态。

6.根据权利要求4所述的分布式锁服务实现方法，其特征在于，该方法还包括：

获取预先配置的链表；

由所述链表中的每个元素作为一个桶，将所述租约信息按照过期时间远近依次存放在所述链表的各个桶中；

当接收到锁续约请求时，将所述锁续约请求对应的锁的租约信息从所述链表的桶中取出，移动至新的桶中以更新锁的租约信息。

7.根据权利要求6所述的分布式锁服务实现方法，其特征在于，该方法还包括：

将过期时间相距在预设范围以内的多个锁的所述租约信息存放在所述链表中同一个桶中；

定期检查所述链表的桶中所述租约信息是否过期，如果过期则把整个桶的租约信息所对应的锁全部释放。

8.根据权利要求1～6中任意一项所述的分布式锁服务实现方法，其特征在于，所述方法还包括：

接收到包括待释放锁的释放锁请求后，检查本地是否存在所述待释放锁的状态信息；

当不存在时，返回释放成功信息；

当存在时，清除本次所述待释放锁的线程以及所述待释放锁的状态信息，并判断清除后所述待释放锁是否还被其他线程占用；

如果判断到没有其他线程占用所述待释放锁，发送释放锁请求给分布式锁中间件，以使得所述分布式锁中间件释放所述待释放锁，如果判断到还有其他线程占用所述待释放锁，反馈释放锁成功信息。

9.根据权利要求1～6中任意一项所述的分布式锁服务实现方法，其特征在于，该方法还包括：每当上锁成功后记录上锁状态，并在重启后，接收客户端发送的上锁状态信息，将接收到的所述上锁状态信息进行同步更新以完成数据恢复。

10.一种分布式锁服务实现装置，其特征在于，包括：

接收模块，用于接收客户端发送的上锁请求，所述上锁请求中携带有租约信息以及所述租约信息对应的至少一个上锁资源；

获取模块，用于获取预先配置的各个锁之间是否存在冲突的冲突类型配置信息；

上锁控制模块，用于根据所述冲突类型配置信息，确定是否为所述上锁请求中所述上锁资源发起上锁请求，其中如果上锁不存在冲突则发起上锁请求、如果上锁存在冲突则不发起上锁请求。

11.一种计算机设备，包括处理器以及存储器，所述存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，其特征在于，所述处理器用于执行所述计算机程序以执行如权利要求1～9中任意一项所述方法。

Images