一种分布式锁管理方法和装置

本发明涉及计算机技术领域，尤其涉及一种分布式锁管理方法和装置。

由于现今工作负载可以容纳在少数几台计算机的内存中，同时通过支持远程直接内存访问(RDMA)网络协议可以比使用传统架构更快地处理工作负载，因此分布式内存系统变得更加普遍。

锁管理器是现代分布式系统的重要组成部分，其构成了许多分布式系统通过网络访问共享资源的支柱。在事务管理中，锁管理器的主要职责是确保竞争性事务的可串行化或其他形式的隔离和无饥饿行为。目前，分布式锁管理器主要包括集中式锁管理器(CLM)和分散式锁管理器(DLM)。其中，CLM的优点是具有全局知识，缺点是它的CPU限制了高吞吐量操作和工作负载的扩展、以及存在单点故障问题，因此许多分布式系统在实践中并不采用CLM，而是采用DLM。

在实现本发明的过程中，本发明的发明人发现：第一、现有的基于RDMA的DLM采用完全牺牲全局知识或者通过昂贵的网络通信来维持全局知识的极端处理方式，前者将导致锁饥饿和访问延迟等问题，后者将导致吞吐量下降等问题。第二、在复杂的异构融合网络场景下，若对所有来源的锁请求放在一个队列中进行处理，会存在处理效率低、容易出现锁冲突等问题。

因此，针对以上不足，需要提供一种适用于多层异构带宽的分布式锁管理方法和装置。

(一)要解决的技术问题

本发明要解决的技术问题是解决在多层异构带宽网络下应用现有的分布式锁管理方法时所存在的处理效率低、容易出现锁冲突等问题。

(二)技术方案

为了解决上述技术问题，一方面，本发明提供了一种分布式锁管理方法。

本发明提供的分布式锁管理方法包括：在接收到事务的加锁请求后，通过查询局部知识配置表判断所述事务的访问数据是否位于本计算机集中；其中，所述局部知识配置表记录有本计算机集中的数据的信息；在所述事务的访问数据位于本计算机集的情况下，根据该事务的预估处理时间或者该事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中，并为所述事务分配唯一锁申请码；在所述事务的加锁请求位于队列头部时，根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件，并在满足锁授权条件时为所述事务授予锁。

可选地，所述方法还包括：在所述事务的访问数据不位于本计算机集的情况下，将所述事务的加锁请求发送至访问数据所在的计算机集，以由所述访问数据所在的计算机集对所述事务的加锁请求进行处理。

可选地，所述唯一锁申请码包括：ticket.nx、ticket.ns、ticket.maxx和ticket.maxs；其中，ticket.nx表示在为所述事务分配唯一锁申请码时已处理独占锁的事务数、ticket.ns表示在为所述事务分配唯一锁申请码时已处理共享锁的事务数、ticket.maxx表示在为所述事务分配唯一锁申请码时申请独占锁的最大事务序号、ticket.maxs表示在为所述事务分配唯一锁申请码时申请共享锁的最大事务序号。

可选地，所述根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件，并在满足锁授权条件时为所述事务授予锁的步骤包括：在所述事务的加锁请求为加独占锁请求的情况下，判断当前所述事务的访问数据所对应的锁计数器中的第一计数值是否等于ticket.maxx、且当前所述事务访问的数据所对应的锁计数器中的第二计数值是否等于ticket.maxs；在第一计数值等于ticket.maxx、且第二计数值等于ticket.maxs的情况下，为所述事务授予独占锁；其中，第一计数值为已处理独占锁的事务数；第二计数值为已处理共享锁的事务数。

可选地，所述根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件，并在满足锁授权条件时为所述事务授予锁的步骤包括：在所述事务的加锁请求为加共享锁请求的情况下，判断当前所述事务的访问数据所对应的锁计数器中的第一计数值是否等于ticket.maxx；在第一计数值等于ticket.maxx的情况下，为所述事务授予共享锁；其中，第一计数值为已处理独占锁的事务数。

可选地，所述方法还包括：在执行所述为所述事务分配唯一锁申请码的步骤之前，通过对所述事务的访问数据所对应的锁计数器执行获取-添加的原子操作，生成所述唯一锁申请码。

可选地，所述方法还包括：在所述事务执行完毕后，释放所述事务的锁、并更新所述事务的访问数据所对应的锁计数器中的第一计数值或第二计数值；和/或，在所述事务执行过程中，将所述事务执行时间与预设阈值进行比较，并且在根据比较结果确认出现死锁的情况下，释放该事务的访问对象上的所有锁。

为了解决上述技术问题，另一方面，本发明还提供了一种分布式锁管理装置。

本发明提供的分布式锁管理装置包括：判断模块，用于在接收到事务的加锁请求后，通过查询局部知识配置表判断所述事务的访问数据是否位于本计算机集中；其中，所述局部知识配置表记录有本计算机集中的数据的信息；分配模块，用于在所述事务的访问数据位于本计算机集的情况下，根据该事务的预估处理时间或者该事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中，并为所述事务分配唯一锁申请码；授权模块，用于在所述事务的加锁请求位于队列头部时，根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件，并在满足锁授权条件时为所述事务授予锁。

可选地，所述装置还包括：发送模块，用于在所述事务的访问数据不位于本计算机集的情况下，将所述事务的加锁请求发送至访问数据所在的计算机集，以由所述访问数据所在的计算机集对所述事务的加锁请求进行处理。

可选地，所述唯一锁申请码包括：ticket.nx、ticket.ns、ticket.maxx和ticket.maxs；其中，ticket.nx表示在为所述事务分配唯一锁申请码时已处理独占锁的事务数、ticket.ns表示在为所述事务分配唯一锁申请码时已处理共享锁的事务数、ticket.maxx表示在为所述事务分配唯一锁申请码时申请独占锁的最大事务序号、ticket.maxs表示在为所述事务分配唯一锁申请码时申请共享锁的最大事务序号。

(三)有益效果

本发明的上述技术方案具有如下优点：通过在接收到事务的加锁请求后，查询局部知识配置表以判断所述事务的访问数据是否位于本计算机集中，在所述事务的访问数据位于本计算机集的情况下，根据该事务的预估处理时间或者该事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中，并为所述事务分配唯一锁申请码，在所述事务的加锁请求位于队列头部时，根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件，并在满足锁授权条件时为所述事务授予锁这些步骤，能够有效提高加锁请求的处理效率，大大缩短处理时间，降低锁冲突的概率，有效缓解锁饥饿和访问延迟问题，尤其适用于多层异构带宽网络。

图1是本发明实施例一中的分布式锁管理方法的流程示意图；

图2是本发明实施例二中的分布式锁管理方法的流程示意图；

图3是一种示例性的访问数据所对应的锁计数器的组成示意图；

图4是本发明实施例三中的分布式锁管理装置的模块组成示意图；

图5是本发明实施例四中的分布式锁管理装置的模块组成示意图。

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要指出的是，在不冲突的情况下，本发明中的实施例以及实施例中的特征可以相互组合。

实施例一

图1是本发明实施例一中的分布式锁管理方法的流程示意图。如图1所示，本发明实施例提供的分布式锁管理方法包括：

步骤S101、在接收到事务的加锁请求后，通过查询局部知识配置表判断所述事务的访问数据是否位于本计算机集中。

其中，所述局部知识配置表记录有本计算机集中的数据的信息，例如本计算机集中的数据标识。在一个可选示例中，分布式锁管理装置在接收到事务的加锁请求后，可从所述加锁请求中解析出所述事务的访问数据标识，然后根据所述事务的访问数据标识查询局部知识配置表。若所述事务的访问数据标识位于所述局部知识配置表中，则判断出所述事务的访问数据位于本计算机集；若所述事务的访问数据标识不位于所述局部知识配置表中，则判断出所述事务的访问数据不位于本计算机集。

在本发明实施例中，通过在分布式锁管理装置中设置局部知识配置表，既能避免完全牺牲全局知识(比如所有计算机集中的数据的信息、所有计算机集中的锁计数器信息等)所导致的锁饥饿和访问延迟问题，又无需通过昂贵的网络通信来维持全局知识，提高了吞吐量。另外，在具体实施时，为了进一步提高处理效率，可通过RDMA网络协议接收事务的加锁请求。

步骤S102、在所述事务的访问数据位于本计算机集的情况下，根据该事务的预估处理时间或者该事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中，并为所述事务分配唯一锁申请码。

在一个可选示例中，可根据事务的预估处理时间将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先设定各类事务的预估处理时间(比如，可将“取值操作”这一事务的预估处理时间设为0.5ms、将“加操作”这一事务的预估处理时间设为1ms)，并按照各类事务的预估处理时间建立多个待处理请求队列(比如，建立与预估处理时间为0.5ms的事务相对应的待处理请求队列A，建立与预估处理时间为1ms的事务相对应的待处理请求队列B)，进而，在确定所述事务的访问数据位于本计算机集的情况下，可将该事务的加锁请求放入与之对应的待处理请求队列中(比如，假设该事务的预估处理时间为0.5ms，则将该事务的加锁请求放入待处理请求队列A)。

在另一个可选示例中，可根据事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先按照事务来源的网络带宽建立多个待处理请求队列中(比如，建立与第一网络带宽取值范围相对应的待处理请求队列C，建立与第二网络带宽取值范围相对应的待处理请求队列D)，进而，在确定所述事务的访问数据位于本计算机集的情况下，可将该事务的加锁请求放入与之对应的待处理请求队列中。

在本发明实施例中，通过按照事务的预估处理时间或者事务来源的网络带宽将事务的加锁请求进行分类，并将同一类的事务加锁请求放入同一个待处理请求队列中，将不同类的事务加锁请求放入不同的待处理请求队列中，能够并行处理多个队列中的事务加速请求,大大缩短了处理时间,也降低了锁冲突和死锁的概率,有效缓解锁饥饿和访问延迟问题,提高事务处理效率。

步骤S103、在所述事务的加锁请求位于队列头部时，根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件。

在一个可选示例中，所述唯一锁申请码包括ticket.nx、ticket.ns、ticket.maxx和ticket.maxs。其中，ticket.nx表示在为所述事务分配唯一锁申请码时已处理独占锁的事务数、ticket.ns表示在为所述事务分配唯一锁申请码时已处理共享锁的事务数、ticket.maxx表示在为所述事务分配唯一锁申请码时申请独占锁的最大事务序号、ticket.maxs表示在为所述事务分配唯一锁申请码时申请共享锁的最大事务序号。

进一步，在上述可选示例中，当所述事务的加锁请求为加独占锁请求时，所述根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件的步骤包括：判断当前时刻所述事务的访问数据所对应的锁计数器中的第一计数值是否等于ticket.maxx、且当前时刻所述事务访问的数据所对应的锁计数器中的第二计数值是否等于ticket.maxs。在第一计数值等于ticket.maxx、且第二计数值等于ticket.maxs的情况下，执行步骤S104。其中，第一计数值为已处理独占锁的事务数；第二计数值为已处理共享锁的事务数。

进一步，在上述可选示例中，当所述事务的加锁请求为加共享锁请求时，所述根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件的步骤包括：判断当前所述事务的访问数据所对应的锁计数器中的第一计数值是否等于ticket.maxx。在第一计数值等于ticket.maxx的情况下，执行步骤S104。其中，第一计数值为已处理独占锁的事务数。

步骤S104、在满足锁授权条件时为所述事务授予锁。

在本发明实施例中，通过以上步骤能够有效提高加锁请求的处理效率，大大缩短处理时间，降低锁冲突的概率，有效缓解锁饥饿和访问延迟问题，尤其适用于多层异构带宽网络。

实施例二

图2是本发明实施例二中的分布式锁管理方法的流程示意图。如图2所示，本发明实施例提供的分布式锁管理方法包括：

步骤S201、在接收到事务的加锁请求后，通过查询局部知识配置表判断所述事务的访问数据是否位于本计算机集。若所述事务的访问数据位于本计算机集，则可执行步骤S202；若所述事务的访问数据不位于本计算机集，则可执行步骤S206。

其中，所述局部知识配置表记录有本计算机集中的数据的信息，例如本计算机集中的数据标识。在一个可选示例中，分布式锁管理装置在接收到事务的加锁请求后，可从所述加锁请求中解析出所述事务的访问数据标识，然后根据所述事务的访问数据标识查询局部知识配置表。若所述事务的访问数据标识位于所述局部知识配置表中，则判断出所述事务的访问数据位于本计算机集；若所述事务的访问数据标识不位于所述局部知识配置表中，则判断出所述事务的访问数据不位于本计算机集。

在本发明实施例中，通过在分布式锁管理装置中设置局部知识配置表，既能避免完全牺牲全局知识(比如所有计算机集中的数据的信息、所有计算机集中的锁计数器信息等)所导致的锁饥饿和访问延迟问题，又无需通过昂贵的网络通信来维持全局知识，提高了吞吐量。另外，在具体实施时，为了进一步提高处理效率，可通过RDMA网络协议接收事务的加锁请求。

步骤S202、根据该事务的预估处理时间或者该事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中，并为所述事务分配唯一锁申请码。

在一个可选示例中，可根据事务的预估处理时间将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先设定各类事务的预估处理时间(比如，可将“取值操作”这一事务的预估处理时间设为0.5ms、将“加操作”这一事务的预估处理时间设为1ms)，并按照各类事务的预估处理时间建立多个待处理请求队列(比如，建立与预估处理时间为0.5ms的事务相对应的待处理请求队列A，建立与预估处理时间为1ms的事务相对应的待处理请求队列B)，进而，在确定所述事务的访问数据位于本计算机集的情况下，可将该事务的加锁请求放入与之对应的待处理请求队列中(比如，假设该事务的预估处理时间为0.5ms，则将该事务的加锁请求放入待处理请求队列A)。

在另一个可选示例中，可根据事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先按照事务来源的网络带宽建立多个待处理请求队列中(比如，建立与第一网络带宽取值范围相对应的待处理请求队列C，建立与第二网络带宽取值范围相对应的待处理请求队列D)，进而，在确定所述事务的访问数据位于本计算机集的情况下，可将该事务的加锁请求放入与之对应的待处理请求队列中。

在该步骤中，除了将该事务的加锁请求放入与之对应的待处理请求队列中，还为所述事务分配唯一锁申请码。进一步，所述唯一锁申请码包括四个参数：ticket.nx、ticket.ns、ticket.maxx和ticket.maxs。其中，ticket.nx表示在为所述事务分配唯一锁申请码时已处理独占锁的事务数、ticket.ns表示在为所述事务分配唯一锁申请码时已处理共享锁的事务数、ticket.maxx表示在为所述事务分配唯一锁申请码时申请独占锁的最大事务序号、ticket.maxs表示在为所述事务分配唯一锁申请码时申请共享锁的最大事务序号。

进一步，在执行所述为所述事务分配唯一锁申请码的步骤之前，本发明实施例的方法还包括：通过对所述事务的访问数据所对应的锁计数器执行获取-添加的原子操作，以生成所述唯一锁申请码。

图3是一种示例性的访问数据所对应的锁计数器的组成示意图。如图3所示，所述事务的访问数据所对应的锁计数器包括四个计数值：nx、ns、maxx、maxs。其中，nx为第一计数值，其表示已处理独占锁的事务数；ns为第二计数值，其表示已处理共享锁的事务数；maxx为第三计数值，其表示申请独占锁的最大事务序号，maxs为第四计数值，其表示申请共享锁的最大事务序号。

下面结合图3所示示例对生成所述唯一锁申请码的步骤作进一步说明。具体来说，所述通过对所述事务的访问数据所对应的锁计数器执行获取-添加的原子操作，以生成所述唯一锁申请码的步骤包括：当事务的加锁请求为加独占锁请求时，获取所述事务的访问数据所对应的锁计数器的值，并对第三计数值maxx进行加一操作，以得到所述唯一锁申请码；当事务的加锁请求为加共享锁请求时，获取所述事务的访问数据所对应的锁计数器的值，并对第四计数值maxs进行加一操作，以得到所述唯一锁申请码。

例如，当事务的加锁请求为加独占锁请求时，假设获取的所述事务的访问数据所对应的锁计数器的值满足：nx＝1、ns＝1、maxx＝1、maxs＝4，则生成的唯一锁申请码满足：ticket.nx＝1、ticket.ns＝1、ticket.maxx＝2、ticket.maxs＝4；当事务的加锁请求为加共享锁请求时，假设获取的所述事务的访问数据所对应的锁计数器的值满足：nx＝1、ns＝1、maxx＝1、maxs＝4，则生成的唯一锁申请码满足：ticket.nx＝1、ticket.ns＝1、ticket.maxx＝1、ticket.maxs＝5。

在本发明实施例中，通过对所述事务的访问数据所对应的锁计数器执行获取-添加(FA)的原子操作以生成所述唯一锁申请码，而不采用比较-交换(CAS)的原子操作，能够避免现有分布式锁管理器存在的死锁、锁饥饿等问题。

步骤S203、在所述事务的加锁请求位于队列头部时，根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件。若满足锁授权条件，则可执行步骤S204；若不满足锁授权条件，则可执行步骤S207。

具体来说，当所述事务的加锁请求为加独占锁请求时，所述根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件的步骤包括：判断当前时刻所述事务的访问数据所对应的锁计数器中的第一计数值nx是否等于ticket.maxx、且当前时刻所述事务访问的数据所对应的锁计数器中的第二计数值ns是否等于ticket.maxs。在第一计数值nx等于ticket.maxx、且第二计数值ns等于ticket.maxs的情况下，执行步骤S204。其中，第一计数值为已处理独占锁的事务数；第二计数值为已处理共享锁的事务数。

当所述事务的加锁请求为加共享锁请求时，所述根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件的步骤包括：判断当前所述事务的访问数据所对应的锁计数器中的第一计数值nx是否等于ticket.maxx。在第一计数值nx等于ticket.maxx的情况下，执行步骤S204。其中，第一计数值nx为已处理独占锁的事务数。

步骤S204、为所述事务授予锁。

进一步，本发明实施例的方法还可包括：在所述事务执行过程中，将所述事务执行时间与预设阈值进行比较，并且在根据比较结果确认出现死锁的情况下，释放该事务的访问对象上的所有锁。在一个示例中，在所述事务执行时间超过两倍的预设阈值时即认为出现死锁，此时可释放该事务的访问对象上的所有锁。通过以上步骤，能够为陷入死锁的事务提供容错机制。

步骤S205、在所述事务执行完毕后，释放所述事务的锁、并更新所述事务的访问数据所对应的锁计数器中的第一计数值或第二计数值。

具体来说，该步骤包括：当所述事务的加锁请求为加独占锁请求时，释放所述事务的独占锁，并对所述事务的访问数据所对应的锁计数器中的第一计数值nx进行加一操作；当所述事务的加锁请求为加共享锁请求时，释放所述事务的共享锁，并对所述事务的访问数据所对应的锁计数器中的第二计数值ns进行加一操作。

步骤S206、将所述事务的加锁请求发送至访问数据所在的计算机集。在步骤S206之后，可由所述访问数据所在的计算机集执行步骤S202。

具体实施时，为了进一步提高处理效率，可通过RDMA网络协议将事务的加锁请求发送至访问数据所在的计算机集。

步骤S207、等待之前的事务释放锁。在步骤S207之后，可再次执行步骤S203。

在本发明实施例中，通过以上步骤能够有效提高加锁请求的处理效率，大大缩短处理时间，降低锁冲突的概率，有效缓解锁饥饿和访问延迟问题，尤其适用于多层异构带宽网络。

实施例三

图4是本发明实施例三中的分布式锁管理装置的模块组成示意图。如图4所示，本发明实施例的分布式锁管理装置400包括：判断模块401、分配模块402、授权模块403。

判断模块401，用于在接收到事务的加锁请求后，通过查询局部知识配置表判断所述事务的访问数据是否位于本计算机集中。

其中，所述局部知识配置表记录有本计算机集中的数据的信息，例如本计算机集中的数据标识。在一个可选示例中，在接收到事务的加锁请求后，判断模块401可从所述加锁请求中解析出所述事务的访问数据标识，然后根据所述事务的访问数据标识查询局部知识配置表。若所述事务的访问数据标识位于所述局部知识配置表中，则判断模块401判断出所述事务的访问数据位于本计算机集；若所述事务的访问数据标识不位于所述局部知识配置表中，则判断模块401判断出所述事务的访问数据不位于本计算机集。

在本发明实施例中，通过在分布式锁管理装置中设置局部知识配置表，既能避免完全牺牲全局知识(比如所有计算机集中的数据的信息、所有计算机集中的锁计数器信息等)所导致的锁饥饿和访问延迟问题，又无需通过昂贵的网络通信来维持全局知识，提高了吞吐量。另外，在具体实施时，为了进一步提高处理效率，可通过RDMA网络协议接收事务的加锁请求。

分配模块402，用于在所述事务的访问数据位于本计算机集的情况下，根据该事务的预估处理时间或者该事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中，并为所述事务分配唯一锁申请码。

在一个可选示例中，分配模块402可根据事务的预估处理时间将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先设定各类事务的预估处理时间(比如，可将“取值操作”这一事务的预估处理时间设为0.5ms、将“加操作”这一事务的预估处理时间设为1ms)，并按照各类事务的预估处理时间建立多个待处理请求队列(比如，建立与预估处理时间为0.5ms的事务相对应的待处理请求队列A，建立与预估处理时间为1ms的事务相对应的待处理请求队列B)。进而，在确定所述事务的访问数据位于本计算机集的情况下，分配模块402可将该事务的加锁请求放入与之对应的待处理请求队列中。比如，假设该事务的预估处理时间为0.5ms，则将该事务的加锁请求放入待处理请求队列A。

在另一个可选示例中，分配模块402可根据事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先按照事务来源的网络带宽建立多个待处理请求队列中(比如，建立与第一网络带宽取值范围相对应的待处理请求队列C，建立与第二网络带宽取值范围相对应的待处理请求队列D)。进而，在确定所述事务的访问数据位于本计算机集的情况下，分配模块402可将该事务的加锁请求放入与之对应的待处理请求队列中。

在本发明实施例中，通过按照事务的预估处理时间或者事务来源的网络带宽将事务的加锁请求进行分类，并将同一类的事务加锁请求放入同一个待处理请求队列中，将不同类的事务加锁请求放入不同的待处理请求队列中，能够并行处理多个队列中的事务加速请求,大大缩短了处理时间,也降低了锁冲突和死锁的概率,有效缓解锁饥饿和访问延迟问题,提高事务处理效率。

授权模块403，用于在所述事务的加锁请求位于队列头部时，根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件，并在满足锁授权条件时为所述事务授予锁。

在一个可选示例中，所述唯一锁申请码包括ticket.nx、ticket.ns、ticket.maxx和ticket.maxs。其中，ticket.nx表示在为所述事务分配唯一锁申请码时已处理独占锁的事务数、ticket.ns表示在为所述事务分配唯一锁申请码时已处理共享锁的事务数、ticket.maxx表示在为所述事务分配唯一锁申请码时申请独占锁的最大事务序号、ticket.maxs表示在为所述事务分配唯一锁申请码时申请共享锁的最大事务序号。

在上述可选示例中，当所述事务的加锁请求为加独占锁请求时，授权模块403根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件包括：授权模块403判断当前时刻所述事务的访问数据所对应的锁计数器中的第一计数值是否等于ticket.maxx、且当前时刻所述事务访问的数据所对应的锁计数器中的第二计数值是否等于ticket.maxs。在第一计数值等于ticket.maxx、且第二计数值等于ticket.maxs的情况下，授权模块403为所述事务授予锁。其中，第一计数值为已处理独占锁的事务数；第二计数值为已处理共享锁的事务数。

在上述可选示例中，当所述事务的加锁请求为加共享锁请求时，授权模块403根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件包括：授权模块403判断当前所述事务的访问数据所对应的锁计数器中的第一计数值是否等于ticket.maxx。在第一计数值等于ticket.maxx的情况下，授权模块403为所述事务授予锁。其中，第一计数值为已处理独占锁的事务数。

本发明实施例的装置，能够有效提高加锁请求的处理效率，大大缩短处理时间，降低锁冲突的概率，有效缓解锁饥饿和访问延迟问题，尤其适用于多层异构带宽网络。

实施例四

图5是本发明实施例四中的分布式锁管理装置的模块组成示意图。如图5所示，本发明实施例的分布式锁管理装置500包括：判断模块501、发送模块502、分配模块503、授权模块504、释放模块505。

判断模块501，用于在接收到事务的加锁请求后，通过查询局部知识配置表判断所述事务的访问数据是否位于本计算机集中。

其中，所述局部知识配置表记录有本计算机集中的数据的信息，例如本计算机集中的数据标识。在一个可选示例中，在接收到事务的加锁请求后，判断模块501可从所述加锁请求中解析出所述事务的访问数据标识，然后根据所述事务的访问数据标识查询局部知识配置表。若所述事务的访问数据标识位于所述局部知识配置表中，则判断模块501判断出所述事务的访问数据位于本计算机集；若所述事务的访问数据标识不位于所述局部知识配置表中，则判断模块501判断出所述事务的访问数据不位于本计算机集。

在本发明实施例中，通过在分布式锁管理装置中设置局部知识配置表，既能避免完全牺牲全局知识(比如所有计算机集中的数据的信息、所有计算机集中的锁计数器信息等)所导致的锁饥饿和访问延迟问题，又无需通过昂贵的网络通信来维持全局知识，提高了吞吐量。另外，在具体实施时，为了进一步提高处理效率，可通过RDMA网络协议接收事务的加锁请求。

发送模块502，用于在所述事务的访问数据不位于本计算机集的情况下，将所述事务的加锁请求发送至访问数据所在的计算机集，以由所述访问数据所在的计算机集对所述事务的加锁请求进行处理。具体实施时，为了进一步提高处理效率，发送模块502可通过RDMA网络协议将事务的加锁请求发送至访问数据所在的计算机集。

分配模块503，用于在所述事务的访问数据位于本计算机集的情况下，根据该事务的预估处理时间或者该事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中，并为所述事务分配唯一锁申请码。

在一个可选示例中，分配模块503可根据事务的预估处理时间将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先设定各类事务的预估处理时间(比如，可将“取值操作”这一事务的预估处理时间设为0.5ms、将“加操作”这一事务的预估处理时间设为1ms)，并按照各类事务的预估处理时间建立多个待处理请求队列(比如，建立与预估处理时间为0.5ms的事务相对应的待处理请求队列A，建立与预估处理时间为1ms的事务相对应的待处理请求队列B)，进而，在确定所述事务的访问数据位于本计算机集的情况下，分配模块503可将该事务的加锁请求放入与之对应的待处理请求队列中(比如，假设该事务的预估处理时间为0.5ms，则将该事务的加锁请求放入待处理请求队列A)。

在另一个可选示例中，分配模块503可根据事务来源的网络带宽，将所述事务的加锁请求放入与之对应的待处理请求队列中。具体实施时，可预先按照事务来源的网络带宽建立多个待处理请求队列中(比如，建立与第一网络带宽取值范围相对应的待处理请求队列C，建立与第二网络带宽取值范围相对应的待处理请求队列D)，进而，在确定所述事务的访问数据位于本计算机集的情况下，分配模块503可将该事务的加锁请求放入与之对应的待处理请求队列中。

此外，除了将该事务的加锁请求放入与之对应的待处理请求队列中，分配模块503还为所述事务分配唯一锁申请码。其中，所述唯一锁申请码包括四个参数：ticket.nx、ticket.ns、ticket.maxx和ticket.maxs。其中，ticket.nx表示在为所述事务分配唯一锁申请码时已处理独占锁的事务数、ticket.ns表示在为所述事务分配唯一锁申请码时已处理共享锁的事务数、ticket.maxx表示在为所述事务分配唯一锁申请码时申请独占锁的最大事务序号、ticket.maxs表示在为所述事务分配唯一锁申请码时申请共享锁的最大事务序号。

进一步，在分配模块503执行所述为所述事务分配唯一锁申请码的步骤之前，其可通过对所述事务的访问数据所对应的锁计数器执行获取-添加的原子操作，以生成所述唯一锁申请码。关于生成所述唯一锁申请码的详细流程，可参考本发明实施例二中的相关说明。

在本发明实施例中，通过对所述事务的访问数据所对应的锁计数器执行获取-添加(FA)的原子操作以生成所述唯一锁申请码，而不采用比较-交换(CAS)的原子操作，能够避免现有分布式锁管理器存在的死锁、锁饥饿等问题。

授权模块504，用于在所述事务的加锁请求位于队列头部时，根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件，并在满足锁授权条件时为所述事务授予锁。

具体来说，当所述事务的加锁请求为加独占锁请求时，授权模块504根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件包括：授权模块504判断当前时刻所述事务的访问数据所对应的锁计数器中的第一计数值nx是否等于ticket.maxx、且当前时刻所述事务访问的数据所对应的锁计数器中的第二计数值ns是否等于ticket.maxs。在第一计数值nx等于ticket.maxx、且第二计数值ns等于ticket.maxs的情况下，授权模块504为所述事务授予锁。其中，第一计数值为已处理独占锁的事务数；第二计数值为已处理共享锁的事务数。

当所述事务的加锁请求为加共享锁请求时，授权模块504根据为所述事务分配的唯一锁申请码判断是否满足锁授权条件包括：授权模块504判断当前所述事务的访问数据所对应的锁计数器中的第一计数值nx是否等于ticket.maxx。在第一计数值nx等于ticket.maxx的情况下，授权模块504为所述事务授予锁。其中，第一计数值nx为已处理独占锁的事务数。

释放模块505，用于在所述事务执行完毕后，释放所述事务的锁、并更新所述事务的访问数据所对应的锁计数器中的第一计数值或第二计数值。

具体来说，当所述事务的加锁请求为加独占锁请求时，释放模块505释放所述事务的独占锁，并对所述事务的访问数据所对应的锁计数器中的第一计数值nx进行加一操作；当所述事务的加锁请求为加共享锁请求时，释放模块505释放所述事务的共享锁，并对所述事务的访问数据所对应的锁计数器中的第二计数值ns进行加一操作。

本发明实施例的装置，能够有效提高加锁请求的处理效率，大大缩短处理时间，降低锁冲突的概率，有效缓解锁饥饿和访问延迟问题，尤其适用于多层异构带宽网络。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。