一种对共享资源的访问操作加锁的方法和装置与流程

本申请涉及计算机
技术领域：
，尤其涉及一种对共享资源的访问操作加锁的方法和装置。
背景技术：
：在分布式系统中，节点通常通过分布式锁对共享资源进行访问。目前，分布式锁管理(distributedlocksmanagement，dlm)系统的部署方式如图1所示。参考图1，该系统中包括多个节点(图1中以4个节点即节点1～4为例)，其中一个节点(例如节点1)上部署一个dlm仲裁(dlm_master)模块，每一节点上均部署一个dlm本地代理(dlm_proxy)模块。部署有dlm_master模块的节点可以称为管理节点，没有部署dlm_master模块的节点可以称为非管理节点。dlm_master模块负责管理各节点的dlm_proxy发送的加锁请求，加锁请求用于请求锁权限，得到访问某一共享资源的锁权限的节点对该共享资源执行该锁权限锁指示的操作。dlm_proxy模块负责本地加锁请求的处理，以及与dlm_master模块进行信息交互。目前，得到访问某一共享资源的锁权限的节点访问该共享资源结束后，将该锁权限存储在本地。若下一次加锁请求由本节点触发，则直接在本地执行加锁流程。若下一次加锁请求由其他节点触发，则当该节点是管理节点时，该节点直接将该锁权限授予该其他节点；当该节点是非管理节点时，管理节点先通过与该节点进行信息交互，回收与该锁权限所指示的操作互斥的锁权限所指示的操作，然后通过与该其他节点进行信息交互，将该锁权限授予该其他节点。其中，锁权限包括读权限和写权限，与读权限互斥的锁权限是写权限，与写权限互斥的锁权限是读权限和写权限。换句话说，一个节点在对一共享资源进行读操作时，其他节点不能对该共享资源进行写操作；一个节点在对一共享资源进行写操作时，其他节点不能对该共享资源进行读操作和写操作。由于大部分场景下，例如，在企业分布式存储系统中，对某一共享资源的加锁请求大部分来源于分布式系统中的其中一个节点。其余节点只是偶发性或者周期性的触发对该共享资源的加锁请求。因此，当某一次加锁请求由该其余节点中的一个节点触发，下一次加锁请求通常又由该节点触发，若按照上述提供的技术方案，则在对该下一次加锁请求进行处理的过程中，需要进行节点间信息交互，这会降低加锁响应速率。技术实现要素：本申请提供一种对共享资源的访问操作加锁的方法和装置，有助于在加锁请求大部分来源于分布式系统中的一个节点，某一加锁请求由其余节点触发，且下一次加锁请求通常又由该节点触发的场景下，减少节点间信息交互次数，从而提升加锁响应速率。为达到上述目的，本申请实施例采用如下技术方案：第一方面，提供一种对共享资源的访问操作加锁的方法，应用于分布式系统中的管理节点，管理节点用于管理分布式系统中的至少两个节点访问共享资源的锁权限，得到锁权限的节点对共享资源执行锁权限所指示的操作；方法包括：接收至少两个节点中的第一节点发送的锁权限请求，锁权限请求用于请求访问共享资源的第一锁权限，第一锁权限是锁权限中的一种锁权限；向第一节点授予访问共享资源的第一锁权限；确定热点节点，其中，热点节点是至少两个节点中连续访问共享资源的次数大于或等于预设阈值，且连续访问的时间距离当前时刻最近的节点；向第一节点回收访问共享资源的第一锁权限，并向热点节点授予访问共享资源的第一锁权限。该技术方案中，执行加锁处理流程结束之后，热点节点存储有共享资源的第一锁权限。如此一来，在加锁请求大部分来源于分布式系统中的一个节点(如本申请中定义的热点节点)，某一加锁请求由其余节点(如上述第一节点)触发，且下一次加锁请求通常又由该节点(即热点节点)触发的场景下，可以直接在该热点节点本地执行加锁流程，从而可以减少节点间信息交互次数，提升了加锁响应速率。另外，对于本次加锁流程来说，即本技术方案中，第一节点触发的加锁流程来说，在上述第二个步骤中，即可获得共享资源的第一锁权限，因此并不影响该加锁流程的响应速率。在一种可能的设计中，管理节点中存储共享资源被访问的历史记录，被访问历史记录按访问时间顺序记录了访问共享资源的节点，确定热点节点，可以包括：在共享资源被访问的历史记录中选择连续访问共享资源的次数大于或等于预设阈值，且访问时间距离当前时刻最近的节点，作为热点节点。该可能的设计给出了一种确定热点节点的实现方式。在一种可能的设计中，在向第一节点授予访问共享资源的第一锁权限之前，该方法还可以包括：接收第二节点上报的第二节点访问共享资源的历史记录；其中，第二节点是至少两个节点中存储访问共享资源的第二锁权限的节点，第二锁权限所指示的操作与第一锁权限所指示的操作互斥。例如，若第一锁权限是读权限，则第二锁权限是写权限；若第一锁权限是写权限，则第二锁权限是读权限和写权限。将第二节点访问共享资源的历史记录，添加到共享资源被访问的历史记录中。在一种可能的设计中，在接收第二节点上报的第二节点访问共享资源的历史记录之前，该方法还可以包括：向第二节点发送锁权限回收命令，其中，锁权限回收命令用于指示第二节点释放共享资源的第二锁权限；第二节点访问共享资源的历史记录是第二节点在释放访问共享资源的第二锁权限后发送给管理节点的。该可能的设计给出了一种第二节点上报其访问共享资源的历史记录的实现方式，当然本申请不限于此，具体可参考下文具体实施方式。在一种可能的设计中，在确定热点节点之后，该方法还可以包括：接收第一节点发送的第一节点访问共享资源的历史记录；然后，将第一节点访问共享资源的历史记录，添加到共享资源被访问的历史记录中。更新后的共享资源被访问的历史记录可以用于后续加锁流程中确定热点节点。在一种可能的设计中，该方法还可以包括：删除共享资源被访问的历史记录中的无效历史记录，无效历史记录是共享资源被访问的历史记录中当前确定的热点节点之前访问共享资源的节点。如此一来，可以节省存储空间。第二方面，提供一种管理节点，该管理节点可以用于执行上述第一方面所述的对共享资源的访问操作加锁的方法。该管理节点具体可以包括：执行上述第一方面所述的方法对应的各功能模块，也可以将其中的两个或两个以上的功能集成在一起。第三方面，提供一种管理节点，该管理节点可以用于执行上述第一方面所述的对共享资源的访问操作加锁的方法。该管理节点具体可以包括：存储器和处理器，其中，存储器用于存储计算机程序，该计算机程序被处理器执行时，使得第一方面提供的任一方法被执行。其中，存储器可以是内存和/或存储芯片等。处理器可以是cpu和/或控制存储器等。第四方面，提供一种分布式系统，包括：上述第二方面或第三方面提供的任一种管理节点，该管理节点用于管理分布式系统中的至少两个节点访问共享资源的锁权限，得到锁权限的节点共享资源执行锁权限所指示的操作。本申请还提供了一种计算机可读存储介质，其上储存有计算机程序，当该程序在计算机上运行时，使得计算机执行上述第一方面所述的方法。本申请还提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面所述的方法。本申请还提供了一种通信芯片，其中存储有指令，当其在管理节点上运行时，使得管理节点执行上述第一方面所述的方法。可以理解地，上述提供的任一种装置或计算机存储介质或计算机程序产品等均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考对应的方法中的有益效果，此处不再赘述。附图说明图1为现有技术提供的对共享资源的访问操作加锁的方法所适用的一种系统架构的示意图；图2为本申请实施例提供的一种对共享资源的访问操作加锁的方法的交互示意图；图3为本申请实施例提供的另一种对共享资源的访问操作加锁的方法的交互示意图；图4为本申请实施例提供的对共享资源的访问操作加锁的方法所适用的一种系统架构的示意图；图5为本申请实施例提供的另一种对共享资源的访问操作加锁的方法的交互示意图；图6为本申请实施例提供的另一种对共享资源的访问操作加锁的方法的交互示意图；图7为本申请实施例提供的一种管理节点的结构示意图；图8为本申请实施例提供的另一种管理节点的结构示意图。具体实施方式下面首先对本申请实施例中涉及到的相关术语及技术进行解释说明。共享资源，是指分布式系统中多个节点均可以访问的资源。该资源具体可以是存储硬盘、虚拟化的硬盘域对应的存储空间、存储池等。共享资源可以部署在分布式系统中的一个或多个节点上，也可以部署在分布式系统之外的一个设备上。业务模块，是指分布式系统的节点中对共享资源进行访问的模块。换句话说，节点对共享资源进行访问，具体是节点中的业务模块对共享资源进行访问。分布式系统的每个节点均可以包括一个或多个业务模块。不同的共享资源可以供不同的节点/业务模块进行访问。例如共享资源1可以供节点1和节点2进行访问，即共享资源1是节点1和节点2的共享资源；共享资源2可以供节点2和节点3进行访问，即共享资源2是节点2和节点3的共享资源。对共享资源进行访问，包括对共享资源进行读操作，以及对共享资源进行写操作。其中，对共享资源进行读操作，是指读取共享资源中的数据的操作。对共享资源进行写操作，是指向共享资源中写数据的操作。一个业务模块在对一个共享资源进行读操作时，其他业务模块可以但不一定对该共享资源进行读操作，不可以对该共享模块进行写操作。一个业务模块在对一个共享资源进行写操作时，其他业务模块不可以对该共享资源进行读操作，也不可以对该共享资源进行写操作。其中，该其他业务模块与该业务模块可以是同一节点中的不同业务模块，也可以是不同节点中的业务模块。锁权限，是指锁定共享资源被访问的权限，即锁定访问共享资源的操作的权限。锁权限可以包括读权限和写权限。得到锁权限的节点对共享资源执行该锁权限所指示的操作；其中，读权限所指示的操作是读操作，写权限所指示的操作是写操作。只有具有对一个共享资源进行访问的锁权限(下文中称为访问该共享资源的锁权限)的节点，才可以访问该共享资源。具体的，具有一个共享资源的读权限的节点，才可以对该共享资源进行读操作；具有一个共享资源的写权限的节点，才可以对该共享资源进行写操作。通常，具有一个共享资源的读权限的节点，不一定具有对该共享资源的写权限；具有一个共享资源的写权限的节点，同时具有对该共享资源的读权限。一个节点也可以同时不具有对一个共享资源的读权限和写权限。通常，若一个节点具有一个共享资源的读权限，则其他节点可以但不一定会同时具有该共享资源的读权限，不可以同时具有该共享资源的写权限。若一个节点具有一个共享资源的写权限，则其他节点不可以同时具有该共享资源的读权限和写权限。锁权限的状态，用于对节点具有的锁权限进行标记。如上文所述，由于具有一个共享资源的读权限的节点，不一定具有对该共享资源的写权限；具有一个共享资源的写权限的节点，同时具有对该共享资源的读权限。一个节点也可以同时不具有对一个共享资源的读权限和写权限。因此，通常锁权限的状态可以包括：none状态、读状态和写状态。其中，若访问某一共享资源的锁权限的状态是none状态，则表明不具有该共享资源的读权限和写权限。若访问某一共享资源的锁权限的状态是读状态，则表明只具有该共享资源的读权限，不具有该共享资源的写权限。若访问某一共享资源的锁权限的状态是写状态，则表明具有该共享资源的读权限和写权限。通常，认为写状态的级别高于读状态的级别，读状态的级别高于none状态的级别。全局记录表，是指管理节点的dlm_master模块维护的，用于记录分布式系统中的访问各共享资源的锁权限的授予情况的表格。当然，用于记录分布式系统中的访问各共享资源的锁权限的授予情况的方式可以不限于是表格。全局记录表中记录的信息随着分布式系统中各节点对共享资源的访问情况的变化而更新。例如，假设分布式系统包括节点1、2、3，以及共享资源a、b、c，那么，某一时刻，假设节点1、节点3不具有访问共享资源a的读权限和写权限，节点2具有访问共享资源a的读权限和写权限。节点3不具有访问共享资源b的读权限和写权限，节点1、节点2具有访问共享资源b的读权限且不具有访问共享资源b的写权限。节点1、节点2、节点3不具有访问共享资源c的读权限和写权限。那么，dlm_master模块维护的全局记录表中记录的信息可以如表1所示。表1局部记录表，是指每个节点的dlm_proxy模块维护的，用于记录该dlm_proxy模块所属的节点当前具有的锁权限及这些锁权限的当前使用情况的表格。例如，一个dlm_proxy模块记录的局部记录表中记录的信息可以包括：该dlm_proxy模块所属的节点当前具有的访问各共享资源的锁权限，以及哪个业务模块当前正在使用哪个锁权限的信息等。当然，用于记录该dlm_proxy模块所属的节点当前具有的锁权限及这些锁权限的当前使用情况的方式可以不限于是表格。例如，假设分布式系统包括共享资源a、b、c，一个节点包括业务模块1、2、3，且该节点当前具有访问共享资源a的读权限和写权限，具有访问共享资源b的读权限且不具有访问共享资源b的写权限，不具有访问共享资源c的读权限和写权限。并且，当前该节点的业务模块1正在使用访问共享资源1的锁权限，当前没有业务模块正在使用访问共享资源2的锁权限，那么，该节点的dlm_proxy模块维护的局部记录表可以如表2所示：表2一个dlm_proxy模块维护的局部记录表随着该dlm_proxy模块所属的节点得到或失去锁权限而更新。更新局部记录表具体可以包括：缓存锁权限和释放锁权限。缓存锁权限，是指节点(具体是节点中的dlm_proxy模块)对得到锁权限这一事件进行标记。具体是锁权限的状态升级的过程。例如，dlm_proxy模块缓存访问一个共享资源的读权限，是指dlm_proxy模块将其维护的局部记录表中访问该共享资源的锁权限的状态由none状态更新为读状态。缓存访问一个共享资源的写权限，是指将访问该共享资源的锁权限的状态由none状态或读状态更新为写状态。释放锁权限，是指节点(具体是节点中的dlm_proxy模块)对失去锁权限这一事件进行标记。具体是锁权限的状态降级的过程。例如，dlm_proxy模块释放访问一个共享资源的读权限，是指dlm_proxy模块将其维护的局部记录表中访问该共享资源的锁权限的状态由读状态更新为none状态。释放访问一个共享资源的写权限，是指将访问该共享资源的锁权限的状态由写状态更新为读状态或none状态。另外，本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。本文中符号“/”表示关联对象是或者的关系，例如a/b表示a或者b。本申请中的术语“第一”、“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一节点和第二节点是用于区别不同的节点，而不是用于描述节点的特定顺序。除非另有说明，“多个”的含义是指两个或两个以上。例如，多个节点是指两个或两个以上的节点。参见图2，为一种对共享资源的访问操作加锁的方法的示意图。其中，图2是基于图1所示的系统架构为例进行说明的。具体可以包括如下步骤：s101：节点3的某个业务模块向该节点的dlm_proxy模块发送一次加锁请求。节点3的dlm_proxy模块先解析该加锁请求携带的锁权限信息，然后根据该锁权限信息确定共享资源以及对共享资源进行访问的锁权限(即访问共享资源的第一锁权限)。对于任意一个业务模块来说，当其具有对某个共享资源(即共享资源)的访问需求时，生成并向该业务模块所在的节点的dlm_proxy模块发送一次加锁请求。其中，该加锁请求中可以携带锁权限信息，锁权限信息可以是多个信息封装在一起构成的一个封装体，该多个信息可以例如但不限于包括：共享资源的标识，第一锁权限的标识，业务模块的标识等。其中，该共享资源可以是分布式系统中的任意一个共享资源。第一锁权限可以是读权限，也可以是写权限。具体的，若该业务模块对共享资源具有读需求，则第一锁权限是读权限；若该业务模块对共享资源具有写需求，则第一锁权限是写权限。s102：节点3的dlm_proxy模块通过查询该dlm_proxy模块维护的局部记录表，获取局部记录表中记录的访问共享资源的锁权限的状态。判断第一锁权限与局部记录表中记录的访问共享资源的锁权限的状态是否匹配。若否，则执行s103；若是，则执行s106。具体的，若第一锁权限是读权限，局部记录表中记录的访问共享资源的锁权限的状态是读状态，则判定为匹配；或者，若第一锁权限是写权限，局部记录表中记录的访问共享资源的锁权限的状态是写状态，则判定为匹配。否则，判定为不匹配。例如，假设第一锁权限是读权限，那么，参考表2，若共享资源是共享资源b，则由于访问共享资源b的锁权限的状态是读状态，因此判定为匹配；若共享资源是共享资源a，则由于访问共享资源a的锁权限的状态是写状态，因此判定为不匹配。s103：节点3的dlm_proxy模块向节点1的dlm_master模块发送锁权限请求，其中，锁权限请求用于请求访问共享资源的第一锁权限。s104：节点1的dlm_master模块根据第一锁权限的类型(即读权限还是写权限)，确定访问共享资源的第二锁权限。第二锁权限所指示的操作与第一锁权限所指示的操作互斥，为了便于描述，下文中的部分实施例中，描述为第二锁权限与第一锁权限互斥。其中，若第一锁权限是读权限，则第二锁权限是写权限；若第一锁权限是写权限，则第二锁权限是读权限和写权限。然后，通过查询dlm_master模块维护的全局记录表，确定存储了访问共享资源的第二锁权限的节点。并根据存储了访问共享资源的第二锁权限的节点，判断当前是否满足直接向节点3授予访问共享资源的第一锁权限的条件。若否，则执行s105。若是，则执行s106。具体的，若第一锁权限是读权限，即第二锁权限是写权限，则dlm_master模块通过查询全局记录表，获取共享资源的写权限被授予的节点(即共享资源的写状态对应的锁权限被授予的节点)。若共享资源的写权限被授予的节点为空，即当前分布式系统中的各节点均不具有共享资源的写权限，则判定当前满足直接向节点3授予访问共享资源的第一锁权限的条件；否则，判定当前不满足直接向节点3授予访问共享资源的第一锁权限的条件。例如，参考表1，若共享资源是共享资源b，则由于共享资源b的写状态对应的锁权限被授予的节点为空，因此判定当前满足直接向节点3授予访问共享资源的第一锁权限的条件；若共享资源是共享资源a，则由于共享资源a的写状态对应的锁权限被授予的节点不为空，因此判定当前不满足直接向节点3授予访问共享资源的第一锁权限的条件。若第一锁权限是写权限，即第二锁权限是读权限和写权限，则dlm_master模块通过查询全局记录表，获取共享资源的读权限被授予的节点和写权限被授予的节点(即共享资源的读状态对应的锁权限被授予的节点，和写状态对应的锁权限被授予的节点)。若共享资源的读权限被授予的节点和写权限被授予的节点均为空，即当前分布式系统中的各节点均不具有共享资源的读权限，也不具有共享资源的写权限，则判定当前满足直接向节点3授予访问共享资源的第一锁权限的条件；否则，判定当前不满足直接向节点3授予共享资源的第一锁权限的条件。例如，参考表1，若共享资源是共享资源c，则由于共享资源c的读状态对应的锁权限被授予的节点，和写状态对应的锁权限被授予的节点均为空，因此判定当前满足直接向节点3授予访问共享资源的第一锁权限的条件；若共享资源是共享资源a，则由于共享资源a的写状态对应的锁权限被授予的节点不为空，因此判定当前不满足直接向节点3授予访问共享资源的第一锁权限的条件。s105：节点1的dlm_master模块向存储了访问共享资源的第二锁权限的节点的dlm_proxy模块回收访问共享资源的第二锁权限。例如，假设第二锁权限包括写权限，且当前存储了共享资源的写权限的节点是节点2，则节点1的dlm_master模块向节点2的dlm_proxy模块发送锁权限回收命令，其中，锁权限回收命令用于向节点2的dlm_proxy模块回收共享资源的写权限。节点2的dlm_proxy模块接收到锁权限回收命令后，通过查询其维护的局部记录表，若确定当前节点2中有业务模块正在使用访问共享资源的锁权限(包括写权限和读权限)，则等待该业务模块使用完后，释放共享资源的写权限，并向dlm_master模块回复锁权限回收响应；若确定当前节点2中没有业务模块正在使用访问共享资源的锁权限(包括写权限和读权限)，则释放共享资源的写权限，并向dlm_master模块回复锁权限回收响应。假设第二锁权限包括读权限，则节点1的dlm_master模块向存储了访问共享资源的第二锁权限的节点回收第二锁权限的过程与上述过程的区别在于：业务模块正在使用的访问共享资源的锁权限是读权限，其他过程可参考上述过程，此处不再赘述。s106：节点1的dlm_master模块向节点3的dlm_proxy模块授予访问共享资源的第一锁权限。具体的，节点1的dlm_master模块向节点3的dlm_proxy模块发送锁权限授予命令。其中，锁权限授予命令用于指示向节点3授予访问共享资源的第一锁权限。节点3的dlm_proxy模块接收到锁权限授予命令后，缓存访问共享资源的第一锁权限，并向节点1的dlm_master模块回复锁权限授予响应。s107：节点3的dlm_proxy模块向该业务模块授予访问共享资源的第一锁权限。具体的，节点3的dlm_proxy模块向该业务模块发送锁权限授予命令。其中，锁权限授予命令用于指示向该业务模块授予访问共享资源的第一锁权限。该业务模块接收到锁权限授予命令后，向该dlm_proxy模块回复锁权限授予响应。s108：该业务模块根据访问共享资源的第一锁权限，对共享资源进行访问，并在访问操作执行完成后，向节点3的dlm_proxy模块发送释放信息。节点3的dlm_proxy模块接收到释放信息后，更新局部记录表。其中，更新局部记录表具体是：删除当前正在使用访问共享资源的第一锁权限的该业务模块的标识。至此，加锁流程结束。该情况下，锁权限存储在节点3的dlm_proxy模块。由于大部分场景下，例如，在企业分布式存储系统中，对某一共享资源的加锁请求大部分来源于分布式系统中的其中一个节点。其余节点只是偶发性或者周期性的触发对该共享资源的加锁请求。因此，当某一次加锁请求由该其余节点中的一个节点触发，下一次加锁请求通常又由该节点触发，若按照上述提供的技术方案，则在对该下一次加锁请求进行处理的过程中，需要进行多次节点间信息交互，这导致通信耗时较长。下面通过一个示例进行说明：例如，假设连续5次触发加锁请求(分别标记为加锁请求1～5)的节点依次为：节点3、节点3、节点3、节点2、节点3，那么，按照如图2所示的技术方案执行的5次加锁流程如图3所示。图3是基于图1所示的系统架构为例进行说明的。图3所示的实施例中相关内容的解释可参考上文，此处不再赘述。本示例中，以第一锁权限是写权限为例进行说明。参见图3，具体如下：1)、对于加锁请求1，加锁流程如下：a.节点3的dlm_proxy模块接收一业务模块发送的加锁请求1，由于此时分布式系统处于初始状态，共享资源的写权限和读权限均没有存储在任一节点的dlm_proxy模块维护的局部记录表中，因此，节点3的dlm_proxy模块确定本地没有存储加锁请求1所请求的访问共享资源的写权限，然后，向管理节点(即节点1)的dlm_master模块发送锁权限请求，以请求访问共享资源的写权限。b.节点1的dlm_master模块接收到该锁权限请求后，判定当前满足直接向节点3的dlm_proxy模块授予访问共享资源的写权限的条件。然后，向节点3的dlm_proxy模块授予访问共享资源的写权限。c.节点3的dlm_proxy模块向该业务模块授予访问共享资源的写权限。该业务模块执行完对共享资源的访问后，将访问共享资源的写权限释放给节点3的dlm_proxy模块。该过程中，加锁流程在节点间执行。节点3直接向节点1授予访问共享资源的写权限，本流程结束后访问共享资源的写权限存储在节点3。2)、对于加锁请求2，加锁流程如下：节点3的dlm_proxy模块接收到一业务模块发送的加锁请求2，确定本地存储有加锁请求2所请求的访问共享资源的写权限，则向该业务模块授予访问共享资源的写权限，该业务模块执行完对共享资源的访问后，将访问共享资源的写权限释放给节点3的dlm_proxy模块。该过程中，加锁流程在本地执行。本流程结束后访问共享资源的写权限存储在节点3。3)、对于加锁请求3，加锁流程如下：节点3的dlm_proxy模块接收到一业务模块发送的加锁请求3，确定本地存储有加锁请求3所请求的访问共享资源的写权限，则向该业务模块授予访问共享资源的写权限，该业务模块执行完对共享资源的访问后，将访问共享资源的写权限释放给节点3的dlm_proxy模块。该过程中，加锁流程在本地执行。本流程结束后访问共享资源的写权限存储在节点3。4)、对于加锁请求4，加锁流程如下：a.节点2的dlm_proxy模块接收到一业务模块发送的加锁请求4，确定本地没有存储加锁请求4所请求的访问共享资源的写权限，则向节点1的dlm_master模块发送锁权限请求，以请求访问共享资源的写权限。b.节点1的dlm_master模块接收到该锁权限请求后，向存储了与访问共享资源的写权限互斥的锁权限的节点回收该互斥的锁权限，具体的，向节点3的dlm_proxy模块回收访问共享资源的写权限。该过程包括2次节点间信息交互，具体可以参考上文。需要说明的是，本实施例中，以第一锁权限是写权限为例进行说明的，因此，与第一锁权限互斥的第二锁权限是写权限和读权限，而本实施例中，由于此时共享资源的读权限没有存储在任一节点上，共享资源的写权限存储在节点3上，因此，该步骤具体体现为：节点1向节点3回收共享资源的写权限。c.节点1的dlm_proxy模块向节点2的dlm_proxy模块授予访问共享资源的写权限。该过程包括2次节点间信息交互，具体可以参考上文。需要说明的是，对于加锁请求4的处理流程来说，经步骤b和c共4次节点间信息交互，可以使得节点2得到访问共享资源的写权限。d.节点2的dlm_proxy模块向该业务模块授予访问共享资源的写权限，该业务模块执行完对共享资源的访问后，将访问共享资源的写权限释放给节点2的dlm_proxy模块。该过程中，加锁流程在节点间执行。节点1先向节点3回收访问共享资源的写权限，再向节点2授予访问共享资源的写权限，参考步骤b、c可知，共执行4次节点间信息交互。本流程结束后访问共享资源的写权限存储在节点2。5)、对于加锁请求5，加锁流程如下：a.节点3的dlm_proxy模块接收到一业务模块发送的加锁请求5，确定本地没有缓存加锁请求5所请求的访问共享资源的写权限，则向节点1的dlm_master模块发送锁权限请求，以请求访问共享资源的写权限。b.节点1的dlm_master模块接收到该锁权限请求后，向节点2的dlm_proxy模块回收访问共享资源的写权限。该过程包括2次信息交互，具体可以参考上文。该步骤中相关内容的解释可参考上述4)中的步骤b中的解释，此处不再赘述。c.节点1的dlm_proxy模块向节点3的dlm_proxy模块授予访问共享资源的写权限。该过程包括2次信息交互，具体可以参考上文。d.节点3的dlm_proxy模块向该业务模块授予访问共享资源的写权限，该业务模块执行完对共享资源的访问后，将访问共享资源的写权限释放给节点3的dlm_proxy模块该过程中，加锁流程在节点间执行。节点1先向节点2回收访问共享资源的写权限，再向节点3授予访问共享资源的写权限，且参考步骤b、c可知，共执行4次节点间信息交互。本流程结束后访问共享资源的写权限存储在节点3。根据图3所示的示例，可以认为对共享资源的加锁请求大部分来源于节点3，并且，在偶发性地由节点2触发一次加锁请求，且下一次加锁请求再由节点3触发的情况下，在对该下一次加锁请求进行处理的过程中，需要执行4次节点间的信息交互(参见图3所示的示例中对加锁请求5的处理流程)，这会导致通信耗时较长。基于此，本申请提供了一种对共享资源的访问操作加锁的方法和装置。其基本原理为：在每次加锁流程执行完之后，本次加锁流程所请求的锁权限均存储在共享资源的热点节点，其中，该热点节点是连续访问共享资源的次数大于或等于预设阈值的节点，且连续访问的时间距离当前时刻最近的节点。如此一来，即使某一次加锁请求偶发性地或周期性地由热点节点之外的其他节点触发，由于下一次加锁流程通常又由该热点节点触发，因此，可以直接在本地执行该下一次加锁流程，从而可以减少通信耗时。下面通过一个示例，说明热点节点的确定方法。假设按照时间先后顺序访问共享资源的节点依次为：节点1、节点1、节点1、节点2、节点3、节点3、节点4，由此可知，当前访问共享资源的节点是节点4。那么，若预设阈值是2，则热点节点是节点3。若预设阈值是3，则热点节点是节点1。如图4所示，是本申请实施例提供的技术方案所适用的一种分布式系统的架构示意图。该分布式系统包括多个节点(图4中以4个节点即节点1～4为例)。每一节点中均部署一个dlm_proxy模块100。其中一个节点(例如节点1)上部署一个dlm_master模块200。其中一个节点(例如节点1)上部署一个分布式锁管理统计(dlm_statistic)模块300。dlm_proxy模块100负责本地加锁请求的处理，以及与dlm_master模块200和dlm_statistic模块300进行信息交互等。dlm_master模块200负责管理各节点的dlm_proxy发送的加锁请求等。dlm_statistic模块300负责统计分布式系统中每一共享资源被访问的历史记录，并根据某一共享资源被访问的历史记录，确定该共享资源的热点节点等。其中，共享资源被访问的历史记录记录按访问时间顺序记录了访问共享资源的节点。下文中，将记录dlm_statistic模块300统计的分布式系统中每一共享资源被访问的历史记录的表格，称为全局历史记录表。实际实现时，用于记录分布式系统中每一共享资源被访问的历史记录的方式可以不限于是表格。例如，假设分布式系统中包括节点1、2、3，以及共享资源a、b、c，那么，某一时刻，dlm_statistic模块300维护的全局历史记录表中记录的信息可以如表3所示。表3共享资源共享资源被访问的历史记录共享资源a节点3、节点3、节点2、节点3共享资源b节点2、节点1、节点2、节点2、节点2共享资源c节点1、节点1、节点1应注意，每一节点的dlm_proxy模块100还可以负责维护局部历史记录表。一个dlm_proxy模块100维护的局部历史记录表，用于记录该dlm_proxy模块100所属的节点访问每一共享资源的历史记录。节点每访问一次共享资源，该节点的dlm_proxy模块100可以在该dlm_proxy模块100维护的局部历史记录表中记录一次该共享资源的历史记录，具体可以是记录一次该节点的标识。每个节点的dlm_proxy模块100可以在一定的触发条件下向dlm_statistic模块300上报自身维护的局部历史记录表中的部分或全部信息，从而使得dlm_statistic模块300对分布式系统中每一共享资源被访问的历史记录进行统计。关于该触发条件的描述，可参考下文。应注意，部署dlm_master模块200的节点即为管理节点。部署有dlm_master模块200的节点与部署有dlm_statistic模块300的节点可以是同一节点，也可以是不同节点。为了减少信息交互次数，通常将dlm_master模块200和dlm_statistic模块300部署在同一节点上，下文以及附图中均以此为例进行说明。dlm_master模块200与dlm_statistic模块300可以是独立的两个模块，也可以集成在一起。为了更清楚地描述，下文以及附图中，均以dlm_master模块200与dlm_statistic模块300是独立的两个模块为例进行说明。应注意，图4所示的示例，仅为本申请实施例提供的技术方案所适用的系统架构的一个示例，其并不构成对本申请实施例提供的技术方案所适用的系统架构的限定。例如，每一节点上部署多个dlm_proxy模块100，或至少两个节点上部署有dlm_master模块200，或至少两个节点上部署有dlm_statistic模块300等。下面结合附图，对本申请提供的技术方案进行示例性说明。如图5所示，为本申请提供的一种对共享资源的访问操作加锁的方法的交互示意图，具体基于图4所示的系统架构提供的。具体可以包括如下步骤：s201～s203：可参考s101～s103，当然本申请不限于此。s204：节点1的dlm_master模块根据第一锁权限的类型，确定访问共享资源的第二锁权限。然后，通过查询全局记录表，确定存储了访问共享资源的第二锁权限的节点。并根据存储了访问共享资源的第二锁权限的节点，判断当前是否满足直接向节点3授予访问共享资源的第一锁权限的条件。若否，则执行s205；若是，则执行s207。该步骤的具体实现过程及相关说明可参考上文，此处不再赘述。s205：节点1向存储了访问共享资源的第二锁权限的节点(如节点2)回收访问共享资源的第二锁权限。s205的具体实现过程可参考上文，此处不再赘述。s206：节点2的dlm_proxy模块向节点1的dlm_statistic模块上报自身维护的局部历史记录表中记录的共享资源被访问的历史记录。具体上报的可以是按照时间先后顺序访问待共享资源的节点的标识。示例的，s206可以例如但不限于通过如下步骤实现：节点1的dlm_master模块向节点2的dlm_proxy模块发送一个指示信息，其中，该指示信息可以包括共享资源的标识，用于指示节点2的dlm_proxy模块向节点1的dlm_statistic模块上报共享资源被访问的历史记录。节点2的dlm_proxy模块在接收到该指示信息之后，通过查询自身维护的局部历史记录表，获取共享资源被访问的历史记录，然后向节点1的dlm_statistic模块上报共享资源被访问的历史记录。该情况下，本申请对执行s205和s206的先后顺序不进行限定。示例的，s206可以例如但不限于通过如下步骤实现：节点2的dlm_proxy模块在释放访问共享资源的第二锁权限的触发条件下，向节点1的dlm_statistic模块上报该dlm_proxy模块维护的共享资源被访问的历史记录。具体的，共享资源被访问的历史记录可以携带在锁权限回收响应中，或者，共享资源被访问的历史记录可以与锁权限回收响应携带在同一消息中，或者，共享资源被访问的历史记录与锁权限回收响应可以是独立的两条消息，然后，由节点2的dlm_proxy模块发送给节点1的dlm_statistic模块。相比上述示例，在本示例中，由于节点1不需要向节点2发送指示信息，来指示节点2上报共享资源被访问的历史记录，因此能够降低信令开销。需要说明的是，在一些实现方式中，每一节点的dlm_proxy模块向管理节点的dlm_statistic模块上报某一共享资源被访问的历史记录后，可以删除该dlm_proxy模块维护的局部历史记录表中的该历史记录，以节省存储资源。s207～s209：可参考上述s106～s108，当然本申请不限于此。s210：节点1的dlm_statistic模块根据接收到的节点2发送的共享资源被访问的历史记录，更新dlm_statistic模块维护的全局历史记录表，具体是将接收到的节点2发送的共享资源被访问的历史记录，添加到全局历史记录表中；并根据更新后的共享资源被访问的历史记录确定共享资源的热点节点。例如，参考表3，假设共享资源是共享资源a，即当前共享资源a被访问的历史记录是：[节点3、节点3、节点2、节点3]；并且，节点2的dlm_proxy模块发送的共享资源被访问的历史记录是：[节点3、节点3]，则更新后的全局历史记录表中记录的共享资源a被访问的历史记录是：[节点3、节点3、节点2、节点3、节点3、节点3]。需要说明的是，随着节点被访问的次数的增多，全局历史记录表中记录的内容会随之增多，这会占用很大的存储空间。为了节省存储空间，并且，考虑到具体实现时，可能因分布式系统中某些节点或者部署共享资源的设备发生故障等原因，导致在分布式系统中的节点访问共享资源的分布情况改变，从而导致共享资源的热点节点更新。在本申请的一些实施例中，dlm_statistic模块300可以删除全局历史记录表中的无效历史记录，其中，无效历史记录是用于共享资源被访问的历史记录中当前确定的热点节点之前访问共享资源的节点。例如，基于上述示例，即共享资源a被访问的历史记录是：[节点3、节点3、节点2、节点3、节点3、节点3]，若热点节点被定义为连续被访问次数大于或等于2，且连续访问的时间距离当前时刻最近的节点，也就是说共享资源被访问的历史信息是[节点3，节点3]即可表示当前确定的热点节点是节点3，则可以将共享资源a被访问的历史记录[节点3、节点3、节点2、节点3、节点3、节点3]更新为[节点3，节点3]，以节省存储空间。s211：节点1的dlm_master模块判断所确定的共享资源的热点节点是否是本次加锁过程中请求访问共享资源的第一锁权限的节点(即节点3)。若是，则本次加锁流程结束。此时，访问共享资源的第一锁权限存储在共享资源的热点节点。若否，则执行s212。需要说明的是，本申请不限定s207～s209与s210～s211的执行顺序。s212：节点1的dlm_master模块向节点3的dlm_proxy模块回收访问共享资源的第一锁权限，并将访问共享资源的第一锁权限授予热点节点的dlm_proxy模块。其中，该热点节点可以是节点2，也可以不是节点2，图5中是以热点节点不是节点2为例进行说明的。可选的，在执行节点1的dlm_master模块向节点3的dlm_proxy模块回收访问共享资源的第一锁权限的过程中和/或之后，还可以执行以下s213～s214：s213：节点3的dlm_proxy模块向节点1的dlm_statistic模块上报自身维护的局部历史记录表中记录的共享资源被访问的历史记录。具体上报的可以是按照时间先后顺序访问待共享资源的节点的标识。s214：节点1的dlm_statistic模块根据接收到的节点3发送的共享资源被访问的历史记录后，更新dlm_statistic模块维护的全局历史记录表，具体是将接收到的节点3发送的共享资源被访问的历史记录，添加到全局历史记录表中；以为下次加锁流程中确定热点节点作准备。其中，s213的具体实现过程可参考上述s206，s214的具体实现过程可参考上述s209。此处不再赘述。至此，本次加锁操作结束。此时，访问共享资源的第一锁权限缓存在共享资源的热点节点。需要说明的是，图5所示的实施例中的步骤之间的先后顺序仅为一种示例。实际上，在不影响本技术方案的主要思想及基本逻辑的前提下，步骤之间的先后顺序可以进行调整。例如，在一些实现方式中，s205和s206的执行顺序可以不分先后。以下，通过一个具体示例，说明本申请提供的技术方案相比现有技术，能够减少节点间信息交互次数。例如，假设连续5次触发加锁请求(分别标记为加锁请求1～5)的节点依次为：节点3、节点3、节点3、节点2、节点3，并且，热点节点是连续被访问2次，且连续访问的时间距离当前时刻最近的节点，那么，按照如图5所示的技术方案执行的5次加锁流程如图6所示。图6是基于图4所示的系统架构为例进行说明的。图6所示的实施例中相关内容的解释可参考上文，此处不再赘述。本示例中，以第一锁权限是写权限为例进行说明。参见图6，具体如下：1)～3)、对于加锁请求1～3，可参考图3所示的技术方案中对加锁请求1～3的处理流程。本实施例中，执行1)～3)之后，节点3的dlm_proxy模块维护的局部历史记录表中记录的共享资源被访问的历史记录可以标记为：[节点3，节点3，节点3]。4)、对于加锁请求4，加锁流程如下：a.节点2的dlm_proxy模块接收到一业务模块发送的加锁请求4，确定本地没有存储加锁请求4所请求的访问共享资源的写权限，则向节点1的dlm_master模块发送锁权限请求，以请求访问共享资源的写权限。b.节点1的dlm_master模块接收到该锁权限请求后，向节点3的dlm_proxy模块回收访问共享资源的写权限。该过程包括2次节点间信息交互，具体可以参考上文。c.节点3的dlm_proxy模块向节点1的dlm_statistic模块上报自身维护的局部历史记录表中记录的访问共享资源被访问的历史记录(即[节点3，节点3，节点3])。其中，参考上述s206的具体实现方式可知，该步骤中节点间交互的消息可以复用步骤b中的节点间交互的消息。d.节点1的dlm_proxy模块向节点2的dlm_proxy模块授予访问共享资源的写权限。该过程包括2次节点间信息交互，具体可以参考上文。需要说明的是，对于加锁请求4的处理流程来说，经步骤b和d共4次节点间信息交互，可以使得节点2得到访问共享资源的写权限。e.节点2的dlm_proxy模块向该业务模块授予访问共享资源的写权限，该业务模块执行完对访问共享资源的访问后，将共访问享资源的写权限释放给节点2的dlm_proxy模块。f.节点1的dlm_statistic模块根据步骤c中接收到[节点3，节点3，节点3]，以及热点节点是连续被访问2次，且连续访问的时间距离当前时刻最近的节点这一概念，更新全局历史记录表。其中，更新后的共享资源被访问的历史记录可以是[节点3，节点3]。然后，根据更新后的共享资源被访问的历史记录确定共享资源的热点节点是节点3。g.节点1的dlm_master模块判定共享资源的热点节点(即节点3)不是本次加锁流程中触发加锁请求的节点(即节点2)，然后执行下述步骤h。h.节点1的dlm_master模块向节点2的dlm_proxy模块回收访问共享资源的写权限，并将访问共享资源的写权限授予热点节点(即节点3)的dlm_proxy模块。i.节点2的dlm_proxy模块向节点1的dlm_statistic模块上报共享资源被访问的历史记录(即[节点2])。其中，参考上述s206的具体实现方式可知，该步骤中节点间交互的消息可以复用步骤h中的节点间交互的消息。j.节点1的dlm_statistic模块根据接收到的[节点2]，将全局历史记录表中记录的[节点3，节点3]更新为[节点3，节点3，节点2]，以为下次加锁流程中确定热点节点作准备。该过程中，加锁流程在节点间执行。节点1先向节点3回收并向节点2授予访问共享资源的写权限，再向节点2回收并向节点3授予访问共享资源的写权限。本流程结束后，访问共享资源的写权限存储在节点3。5)、对于加锁请求5，加锁流程如下：节点3的dlm_proxy模块接收到一业务模块发送的加锁请求5，确定本地存储有加锁请求5所请求的访问共享资源的写权限，则向该业务模块授予访问共享资源的写权限，该业务模块执行完对共享资源的访问后，将访问共享资源的写权限释放给节点5的dlm_proxy模块。该过程中，加锁流程在本地执行。本流程结束后访问共享资源的写权限存储在节点3。对比图3所示的示例和图6所示的示例可知，在节点3是热点节点，且偶发性地由节点2触发一次加锁请求(即加锁请求4)，下一次加锁请求(即加锁请求5)又由该热点节点触发的情况下，图3所示的示例中，在对该下一次加锁请求进行处理的过程中，需要执行4次节点间的信息交互(具体可参见图3所示的示例中对加锁请求5的处理流程)。然而，图6所示的示例中，不需要执行节点间的信息交互，具体可参见图6所示的示例中对加锁请求5的处理流程，因此，图6所示的示例，可以减少节点间的信息交互次数，从而解决通信耗时较长的问题，提升了加锁响应速率。另外，从对加锁请求4进行处理的流程来看，图3所示的方法和图6所示的方法均通过4次节点间信息交互，使得触发加锁请求4的节点2得到加锁请求所请求的锁权限，因此，图6所示的示例，并不会影响针对加锁请求4的加锁响应速率。综上，相比图3所示的示例，本申请提供的技术方案中，将节点间的即时通信通过预授来提前完成(如加锁请求5的处理流程中的部分节点间通信预先在加锁请求4的处理流程中完成)，以减少即时通信，从而提升加锁响应速率。上述主要从各个节点之间交互的角度对本申请实施例提供的方案进行了介绍。可以理解的是，各个节点，例如管理节点或者非管理节点。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。本申请实施例可以根据上述方法示例对管理节点进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。下面以采用对应各个功能划分各个功能模块为例进行说明：图7给出了一种管理节点70的结构示意图。该管理节点70可以是上文中涉及的管理节点(例如图4中的节点1)。管理节点70用于管理分布式系统中的至少两个节点的访问共享资源的锁权限，得到锁权限的节点对共享资源执行锁权限所指示的操作；管理节点70可以包括：接收单元701、授予单元702、确定单元703以及回收单元704。接收单元701，用于接收至少两个节点中的第一节点发送的锁权限请求，锁权限请求用于请求访问共享资源的第一锁权限，第一锁权限是锁权限中的一种锁权限。授予单元702，用于向第一节点授予访问共享资源的第一锁权限。确定单元703，用于确定热点节点，其中，热点节点是至少两个节点中连续访问共享资源的次数大于或等于预设阈值，且连续访问的时间距离当前时刻最近的节点。回收单元704，用于向第一节点回收访问共享资源的第一锁权限。授予单元702还用于，向热点节点授予访问共享资源的第一锁权限。例如，结合图5，第一节点可以是图5中的节点3，管理节点70可以是图5中的节点1。接收单元701可以用于执行s203中的接收动作。授予单元702可以用于执行s207。确定单元703可以用于执行s210。回收单元704可以用于执行s212中的回收步骤。授予单元702还可以用于执行s212中的授予步骤。在一种可能的设计中，管理节点70还包括：存储单元705，用于存储共享资源被访问的历史记录，被访问历史记录按访问时间顺序记录了访问共享资源的节点。确定单元703具体可以用于：在共享资源被访问的历史记录中选择连续访问共享资源的次数大于或等于预设阈值，且访问时间距离当前时刻最近的节点，作为热点节点。例如，结合图5，确定单元703可以用于执行s210。在一种可能的设计中，接收单元701还用于，接收第二节点上报的第二节点访问共享资源的历史记录；其中，第二节点是至少两个节点中存储访问共享资源的第二锁权限的节点，第二锁权限所指示的操作与第一锁权限所指示的操作互斥；管理节点70还可以包括：添加单元706，用于将第二节点访问共享资源的历史记录，添加到共享资源被访问的历史记录中。例如，结合图5，第二节点可以是节点2。接收单元701可以用于执行s206中的接收步骤。添加单元706可以用于执行s210中的更新步骤。在一种可能的设计中，管理节点70还可以包括：发送单元707，用于在接收单元701接收第二节点上报的第二节点访问共享资源的历史记录之前，向第二节点发送锁权限回收命令，其中，锁权限回收命令用于指示第二节点释放共享资源的第二锁权限；第二节点访问共享资源的历史记录是第二节点在释放访问共享资源的第二锁权限后发送给管理节点的。例如，结合图5，发送单元707，用于执行s205中的发送锁权限回收命令的步骤。在一种可能的设计中，接收单元701还用于，在确定单元703确定热点节点之后，接收第一节点发送的第一节点访问共享资源的历史记录；管理节点70还包括：添加单元706，用于将第一节点访问共享资源的历史记录，添加到共享资源被访问的历史记录中。例如，结合图5，接收单元701用于执行s213中的接收步骤。添加单元706用于执行s214。在一种可能的设计中，管理节点7还可以包括：删除单元708，用于删除共享资源被访问的历史记录中的无效历史记录，无效历史记录是共享资源被访问的历史记录中当前确定的热点节点之前访问共享资源的节点。需要说明的是，上述均以举例的方式说明了管理节点70中的各单元与上文所示的方法实施例中的一些步骤之间的联系，实际上，管理节点70的各单元还可以执行上文所示的方法实施例中的其他相关步骤，此处不再一一列举。另外，管理节点70的另一种结构示意图，可以参考图4中的节点1的结构示意图。管理节点的一种硬件实现方式可以参考图8。如图8所示，管理节点80可以包括：处理器801、内存控制器802、内存803、收发器804以及总线805；其中，处理器801、内存控制器802、内存803、收发器805通过总线805相互连接。其中，上述处理单元701可以通过处理器801和/或内存控制器802实现。收发单元702可以通过收发器804实现。处理器801可以是cpu，通用处理器，数字信号处理器(digitalsignalprocessor，dsp)，专用集成电路(application-specificintegratedcircuit，asic)，现场可编程门阵列(fieldprogrammablegatearray，fpga)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。总线805可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。由于本申请实施例提供的管理节点可以用于执行上述提供的对共享资源的访问操作的加锁方法，因此其所能获得的技术效果可参考上述方法实施例，本申请实施例在此不再赘述。结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理模块执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(randomaccessmemory，ram)、闪存、只读存储器(readonlymemory，rom)、可擦除可编程只读存储器(erasableprogrammablerom，eprom)、电可擦可编程只读存储器(electricallyeprom，eeprom)、寄存器、硬盘、移动硬盘、只读光盘(cd-rom)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于asic中。本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。以上具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围。当前第1页12