CN103488526A - 在分布式系统中锁定业务资源的系统和方法 - Google Patents

Abstract

本发明提供了一种在分布式系统中锁定业务资源的系统，包括：请求解析单元，用于解析接收到的业务资源锁定请求，获取锁定信息，所述锁定信息包括所述分布式系统中需要执行锁定的业务资源和锁定模式；锁定执行单元，用于将创建的数据节点作为锁定所述业务资源的承载节点，并按照所述锁定模式，对所述业务资源执行锁定操作。本发明还提出了一种在分布式系统中锁定业务资源的方法。通过本发明的技术方案，可以不依赖于单点服务器，使得在分布式系统中，有助于避免单点服务器的宕机导致业务锁无法释放或请求，从而提高了系统的效率和健壮性。

Description

在分布式系统中锁定业务资源的系统和方法

技术领域

本发明涉及数据处理技术领域，具体而言，涉及在分布式系统中锁定业务资源的系统和相应的方法。

背景技术

在大并发环境下，必可避免存在并发操作同一资源的情况。如同时修改同一条档案、同时申请新的单据号等等。如果仅靠数据库的锁机制，效率很低，并且会出现逻辑错误和误覆盖的情况。常用的做法是使用业务锁，对资源按照业务需要进行锁定，在一定程度上解决了这个问题。

然而在分布式环境中，必须使用单点的方式实现。随着并发访问量增加，对锁的请求越来越大，单点服务器会成为瓶颈。更严重的问题是，单点服务器会因为压力过大，不再响应甚至宕机，导致出现已存在的业务锁不能释放或者无法请求新的业务锁的情况，严重影响业务。

因此，如何在分布式系统中实现更为高效的业务锁功能，成为目前亟待解决的技术问题。

发明内容

本发明正是基于上述问题，提出了一种新的应用于分布式系统中的业务锁技术，可以不依赖于单点服务器，使得在分布式系统中，有助于避免单点服务器的宕机导致业务锁无法释放或请求，从而提高了系统的效率和健壮性。

有鉴于此，本发明提出了一种在分布式系统中锁定业务资源的系统，包括：请求解析单元，用于解析接收到的业务资源锁定请求，获取锁定信息，所述锁定信息包括所述分布式系统中需要执行锁定的业务资源和锁定模式；锁定执行单元，用于将创建的数据节点作为锁定所述业务资源的承载节点，并按照所述锁定模式，对所述业务资源执行锁定操作。

在该技术方案中，通过创建数据节点来作为业务锁的承载节点，使得在分布式系统中，无需采用单点的方式，避免了由于单点服务器的宕机或不响应而导致的业务锁无法释放或无法申请，提升了系统的可靠性。

在上述技术方案中，优选地，还包括：第一判断单元，用于判断是否存在已建立的对应于所述业务资源的数据节点；其中，所述锁定执行单元用于：在所述第一判断单元的判断结果为不存在时，新建所述数据节点，并执行对所述业务资源的锁定操作；在所述第一判断单元的判断结果为存在时，若所述锁定模式为排他锁定、或所述锁定模式为共享锁定且已存在的数据节点的锁定模式为排他锁定，则停止执行所述锁定操作并返回，若所述锁定模式为共享锁定且已存在的数据节点的锁定模式为共享锁定，则修改所述数据节点，以完成所述锁定操作。

在该技术方案中，对业务锁的类型分为了排他锁定和共享锁定，其中，排他锁定使得同一时间内仅能够由一个对象实现对相应业务资源的锁定，共享锁定则允许多个对象实现对相应业务资源的锁定，从而有助于满足不同对象对于业务的操作需求，避免在操作过程中发生逻辑错误、误覆盖等。而通过在申请业务资源的锁定过程中，对是否已存在数据节点、业务锁的类型等进行确认，也使得对业务资源的锁定处理更准确，避免产生误操作。

在上述任一技术方案中，优选地，还包括：分类处理单元，用于按照预设的隔离条件对建立的数据节点进行分类；隔离管理单元，用于对每种类型的数据节点进行隔离管理，且同一数据节点对应于一个或多个所述隔离条件。

在该技术方案中，可以基于预设的隔离条件，对不同类型的数据节点进行隔离管理，有助于系统的稳定性和效率的提升。其中，隔离条件可以为系统默认预设的，也可以为用户根据需求预设的，还可以由用户实时设置或编辑，以满足不同情况下的需求。

在上述任一技术方案中，优选地，所述请求解析单元还用于：解析接收到的解锁请求，确定需要解除锁定的业务资源；所述系统还包括：第二判断单元，用于判断是否存在对应于所述需要解除锁定的业务资源的数据节点；解锁执行单元，用于在所述第二判断单元的判断结果为存在时，若已存在的数据节点的锁定模式为排他锁，则直接删除，若已存在的数据节点的锁定模式为共享锁，则在共享数目为零时，删除所述已存在的数据节点。

在该技术方案中，通过在释放业务锁对应的业务资源时，对业务锁的类型进行查看，避免了对于业务锁对应的数据节点的任意删除，有助于提升系统的稳定性和可靠性。

在上述任一技术方案中，优选地，还包括：节点管理单元，用于监控被锁定的业务资源对应的业务节点的状态，以实现对相应的数据节点的管理。

在该技术方案中，通过对业务节点进行状态监控，并据此管理对应的数据节点（业务锁的承载），从而可以根据业务资源的实时状态的变化，实现对数据节点的生命周期的管理。比如业务节点所处的服务器发生宕机或不响应时，可以直接删除相应的数据节点，从而避免相应的业务资源无法释放或其他对象无法申请对该业务资源进行锁定。

根据本发明的另一方面，还提出了一种在分布式系统中锁定业务资源的方法，包括：步骤202，解析接收到的业务资源锁定请求，获取锁定信息，所述锁定信息包括所述分布式系统中需要执行锁定的业务资源和锁定模式；步骤204，将创建的数据节点作为锁定所述业务资源的承载节点，并按照所述锁定模式，对所述业务资源执行锁定操作。

在该技术方案中，通过创建数据节点来作为业务锁的承载节点，使得在分布式系统中，无需采用单点的方式，避免了由于单点服务器的宕机或不响应而导致的业务锁无法释放或无法申请，提升了系统的可靠性。

在上述技术方案中，优选地，所述步骤204还包括：判断是否存在已建立的对应于所述业务资源的数据节点，当不存在时，新建所述数据节点，并执行对所述业务资源的锁定操作；当存在时，若所述锁定模式为排他锁定、或所述锁定模式为共享锁定且已存在的数据节点的锁定模式为排他锁定，则停止执行所述锁定操作并返回，若所述锁定模式为共享锁定且已存在的数据节点的锁定模式为共享锁定，则修改所述数据节点，以完成所述锁定操作。

在该技术方案中，对业务锁的类型分为了排他锁定和共享锁定，其中，排他锁定使得同一时间内仅能够由一个对象实现对相应业务资源的锁定，共享锁定则允许多个对象实现对相应业务资源的锁定，从而有助于满足不同对象对于业务的操作需求，避免在操作过程中发生逻辑错误、误覆盖等。而通过在申请业务资源的锁定过程中，对是否已存在数据节点、业务锁的类型等进行确认，也使得对业务资源的锁定处理更准确，避免产生误操作。

在上述任一技术方案中，优选地，还包括：按照预设的隔离条件对建立的数据节点进行分类；对每种类型的数据节点进行隔离管理，且同一数据节点对应于一个或多个所述隔离条件。

在该技术方案中，可以基于预设的隔离条件，对不同类型的数据节点进行隔离管理，有助于系统的稳定性和效率的提升。其中，隔离条件可以为系统默认预设的，也可以为用户根据需求预设的，还可以由用户实时设置或编辑，以满足不同情况下的需求。

在上述任一技术方案中，优选地，还包括：解析接收到的解锁请求，确定需要解除锁定的业务资源；判断是否存在对应于所述需要解除锁定的业务资源的数据节点，当存在时，若已存在的数据节点的锁定模式为排他锁，则直接删除，若已存在的数据节点的锁定模式为共享锁，则在共享数目为零时，删除所述已存在的数据节点。

在该技术方案中，通过在释放业务锁对应的业务资源时，对业务锁的类型进行查看，避免了对于业务锁对应的数据节点的任意删除，有助于提升系统的稳定性和可靠性。

在上述任一技术方案中，优选地，还包括：监控被锁定的业务资源对应的业务节点的状态，以实现对相应的数据节点的管理。

在该技术方案中，通过对业务节点进行状态监控，并据此管理对应的数据节点（业务锁的承载），从而可以根据业务资源的实时状态的变化，实现对数据节点的生命周期的管理。比如业务节点所处的服务器发生宕机或不响应时，可以直接删除相应的数据节点，从而避免相应的业务资源无法释放或其他对象无法申请对该业务资源进行锁定。

通过以上技术方案，可以不依赖于单点服务器，使得在分布式系统中，有助于避免单点服务器的宕机导致业务锁无法释放或请求，从而提高了系统的效率和健壮性。

附图说明

图1示出了根据本发明的实施例的在分布式系统中锁定业务资源的系统的示意框图；

图2示出了根据本发明的实施例的在分布式系统中锁定业务资源的方法的流程示意图；

图3示出了根据本发明的实施例的数据节点的树形结构示意图；

图4示出了根据本发明的实施例的添加业务锁的流程示意图；

图5示出了根据本发明的实施例的解除业务锁的流程示意图；

图6示出了根据本发明的实施例的管理业务锁的系统的示意框图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的实施例的在分布式系统中锁定业务资源的系统的示意框图。

如图1所示，根据本发明的实施例的在分布式系统中锁定业务资源的系统100，包括：请求解析单元102，用于解析接收到的业务资源锁定请求，获取锁定信息，所述锁定信息包括所述分布式系统中需要执行锁定的业务资源和锁定模式；锁定执行单元104，用于将创建的数据节点作为锁定所述业务资源的承载节点，并按照所述锁定模式，对所述业务资源执行锁定操作。

在该技术方案中，通过创建数据节点来作为业务锁的承载节点，使得在分布式系统中，无需采用单点的方式，避免了由于单点服务器的宕机或不响应而导致的业务锁无法释放或无法申请，提升了系统的可靠性。

在上述技术方案中，优选地，还包括：第一判断单元106，用于判断是否存在已建立的对应于所述业务资源的数据节点；其中，所述锁定执行单元104用于：在所述第一判断单元106的判断结果为不存在时，新建所述数据节点，并执行对所述业务资源的锁定操作；在所述第一判断单元106的判断结果为存在时，若所述锁定模式为排他锁定、或所述锁定模式为共享锁定且已存在的数据节点的锁定模式为排他锁定，则停止执行所述锁定操作并返回，若所述锁定模式为共享锁定且已存在的数据节点的锁定模式为共享锁定，则修改所述数据节点，以完成所述锁定操作。

在该技术方案中，对业务锁的类型分为了排他锁定和共享锁定，其中，排他锁定使得同一时间内仅能够由一个对象实现对相应业务资源的锁定，共享锁定则允许多个对象实现对相应业务资源的锁定，从而有助于满足不同对象对于业务的操作需求，避免在操作过程中发生逻辑错误、误覆盖等。而通过在申请业务资源的锁定过程中，对是否已存在数据节点、业务锁的类型等进行确认，也使得对业务资源的锁定处理更准确，避免产生误操作。

在上述任一技术方案中，优选地，还包括：分类处理单元108，用于按照预设的隔离条件对建立的数据节点进行分类；隔离管理单元110，用于对每种类型的数据节点进行隔离管理，且同一数据节点对应于一个或多个所述隔离条件。

在该技术方案中，可以基于预设的隔离条件，对不同类型的数据节点进行隔离管理，有助于系统的稳定性和效率的提升。其中，隔离条件可以为系统默认预设的，也可以为用户根据需求预设的，还可以由用户实时设置或编辑，以满足不同情况下的需求。

在上述任一技术方案中，优选地，所述请求解析单元102还用于：解析接收到的解锁请求，确定需要解除锁定的业务资源；所述系统100还包括：第二判断单元112，用于判断是否存在对应于所述需要解除锁定的业务资源的数据节点；解锁执行单元114，用于在所述第二判断单元112的判断结果为存在时，若已存在的数据节点的锁定模式为排他锁，则直接删除，若已存在的数据节点的锁定模式为共享锁，则在共享数目为零时，删除所述已存在的数据节点。

在该技术方案中，通过在释放业务锁对应的业务资源时，对业务锁的类型进行查看，避免了对于业务锁对应的数据节点的任意删除，有助于提升系统的稳定性和可靠性。

在上述任一技术方案中，优选地，还包括：节点管理单元116，用于监控被锁定的业务资源对应的业务节点的状态，以实现对相应的数据节点的管理。

在该技术方案中，通过对业务节点进行状态监控，并据此管理对应的数据节点（业务锁的承载），从而可以根据业务资源的实时状态的变化，实现对数据节点的生命周期的管理。比如业务节点所处的服务器发生宕机或不响应时，可以直接删除相应的数据节点，从而避免相应的业务资源无法释放或其他对象无法申请对该业务资源进行锁定。

图2示出了根据本发明的实施例的在分布式系统中锁定业务资源的方法的流程示意图。

如图2所示，根据本发明的实施例的在分布式系统中锁定业务资源的方法，包括：步骤202，解析接收到的业务资源锁定请求，获取锁定信息，所述锁定信息包括所述分布式系统中需要执行锁定的业务资源和锁定模式；步骤204，将创建的数据节点作为锁定所述业务资源的承载节点，并按照所述锁定模式，对所述业务资源执行锁定操作。

在该技术方案中，通过创建数据节点来作为业务锁的承载节点，使得在分布式系统中，无需采用单点的方式，避免了由于单点服务器的宕机或不响应而导致的业务锁无法释放或无法申请，提升了系统的可靠性。

图3示出了根据本发明的实施例的数据节点的树形结构示意图。

如图3所示，业务锁（业务资源的锁）对应的数据节点具体可以组织为树形结构。根节点为LOCK节点，所有的锁节点都在此节点下，按照不同的隔离条件进行隔离存放，比如隔离条件1、隔离条件2。而每个隔离条件下，对应连接有一个或多个具体的业务锁的承载节点，比如隔离条件1对应于lock1节点、lock2节点……，隔离条件2对应于lock2节点等。

在上述任一技术方案中，优选地，还包括：按照预设的隔离条件对建立的数据节点进行分类；对每种类型的数据节点进行隔离管理，且同一数据节点对应于一个或多个所述隔离条件。

在该技术方案中，可以基于预设的隔离条件，对不同类型的数据节点进行隔离管理，有助于系统的稳定性和效率的提升。其中，隔离条件可以为系统默认预设的，也可以为用户根据需求预设的，还可以由用户实时设置或编辑，以满足不同情况下的需求。

其中，隔离条件可以根据业务需要而指定，因而在不同的隔离条件下，可以允许有相同的锁（比如隔离条件1下的lock2节点和隔离条件2下的lock2节点）。锁的遍历从根节点LOCK开始，逐项遍历子节点。

在每个锁对应的数据节点（承载节点）中，每个锁的结构内容如下表1所示：

ID	1	锁标识
			MODE	1	模式
SERVER	N	业务节点
			SOURCE	N	加锁源
USER	N	用户

表1

其中，ID：每个锁有唯一ID作为标识。MODE：共享锁还是排他锁，当存在排他锁时，其他请求方不能再请求对同一业务资源添加锁；当存在共享锁时，其他请求方可以继续请求对同一业务资源添加更多的共享锁，但不能请求排他锁。SERVER：加锁的业务节点，业务节点状态变化时，可以依据该信息调整锁对应的数据节点，比如当业务节点对应的服务器宕机时，直接删除对应的锁的数据节点，以释放资源。SOURCE：要求添加锁的请求方或来源，可以为客户端或服务器。USER：加锁用户，在解锁时，若希望按用户解锁，则需要依据该信息。

在上述技术方案中，优选地，所述步骤204还包括：判断是否存在已建立的对应于所述业务资源的数据节点，当不存在时，新建所述数据节点，并执行对所述业务资源的锁定操作；当存在时，若所述锁定模式为排他锁定、或所述锁定模式为共享锁定且已存在的数据节点的锁定模式为排他锁定，则停止执行所述锁定操作并返回，若所述锁定模式为共享锁定且已存在的数据节点的锁定模式为共享锁定，则修改所述数据节点，以完成所述锁定操作。

在该技术方案中，对业务锁的类型分为了排他锁定和共享锁定，其中，排他锁定使得同一时间内仅能够由一个对象实现对相应业务资源的锁定，共享锁定则允许多个对象实现对相应业务资源的锁定，从而有助于满足不同对象对于业务的操作需求，避免在操作过程中发生逻辑错误、误覆盖等。而通过在申请业务资源的锁定过程中，对是否已存在数据节点、业务锁的类型等进行确认，也使得对业务资源的锁定处理更准确，避免产生误操作。

图4示出了根据本发明的实施例的添加业务锁的流程示意图。

如图4所示，根据本发明的实施例的添加业务锁的流程包括：

初始化过程（图中未示出）：

1）启动协同服务器实例；

2）创建协同连接实例；

3）如果LOCK根节点不存在，首先创建LOCK节点。LOCK节点的生命周期设置为永久类型。

加锁过程：

步骤402，接收到的请求方请求对其指定的业务资源进行锁定。

步骤404，判断是否存在隔离节点，若存在，则进入步骤408，否则进入步骤406。

步骤406，创建隔离节点。隔离节点即如图3所示的隔离条件节点，用于据此对具体的锁节点（数据节点）进行分类隔离处理。

步骤408，构造路径。具体地，比如说“LOCK/隔离条件1/lockable”。

步骤410，判断是否已经存在对同一业务资源添加的锁，具体查看是否存在对应的数据节点，若存在，则进入步骤414，否则进入步骤412。

步骤412，创建数据节点，实现锁的添加。

步骤414，判断已存在的锁的类型。

步骤416，若已存在的为排他锁，则无法继续添加锁，本次加锁失败。

步骤418，若已存在的为共享锁，则修改该数据节点的数据，添加新的共享锁，则本次加锁成功。

在上述任一技术方案中，优选地，还包括：解析接收到的解锁请求，确定需要解除锁定的业务资源；判断是否存在对应于所述需要解除锁定的业务资源的数据节点，当存在时，若已存在的数据节点的锁定模式为排他锁，则直接删除，若已存在的数据节点的锁定模式为共享锁，则在共享数目为零时，删除所述已存在的数据节点。

在该技术方案中，通过在释放业务锁对应的业务资源时，对业务锁的类型进行查看，避免了对于业务锁对应的数据节点的任意删除，有助于提升系统的稳定性和可靠性。

图5示出了根据本发明的实施例的解除业务锁的流程示意图。

如图5所示，根据本发明的实施例的解除业务锁的流程包括：

步骤502，接收请求方发出的对其指定的业务资源进行解除锁定的请求。

步骤504，判断是否存在隔离节点，若不存在，则一定不存在该隔离节点的子节点，即不存在相应的锁，因而直接结束。

步骤506，若存在，则构成路径，即已存在的锁的具体路径，比如“LOCK/隔离条件1/lockable”。

步骤508，判断是否存在具体的锁对应的数据节点，若存在，则进入步骤510，否则直接结束。

步骤510，判断已存在的锁的类型，若为排他锁，则直接进入步骤512。

步骤512，删除相应的数据节点。

步骤514，若为共享锁，则修改该数据节点的数据，并进入步骤516。

步骤516，判断修改数据后，剩余的共享锁的个数，若为零，则进入步骤512，删除该数据节点，否则结束。

上述技术方案中，还包括遍历锁的过程：

遍历锁：

1）遍历LOCK下的所有节点；

2）读取节点数据；

3）转化成锁的结构。

在上述任一技术方案中，优选地，还包括：监控被锁定的业务资源对应的业务节点的状态，以实现对相应的数据节点的管理。

在该技术方案中，通过对业务节点进行状态监控，并据此管理对应的数据节点（业务锁的承载），从而可以根据业务资源的实时状态的变化，实现对数据节点的生命周期的管理。比如业务节点所处的服务器发生宕机或不响应时，可以直接删除相应的数据节点，从而避免相应的业务资源无法释放或其他对象无法申请对该业务资源进行锁定。

虽然图1示出了基于本发明的一种实施例的系统结构，但显然本发明还可以采用其他的结构，同样能够实现本申请的技术方案。具体地，图6示出了根据本发明的实施例的管理业务锁的系统的示意框图。

如图6所示，根据本发明的实施例的管理业务锁的系统包括：

锁接入模块602，响应业务操作对业务资源进行锁定的请求，并按照请求的锁定类型，确定锁定的请求信息，比如锁定对象、锁定方式等。

协同连接模块604，接收锁接入模块602传入的请求信息，并转化成锁的相应信息，返回给请求方。同时，协同连接模块604还负责与协同服务模块608交互，完成对锁对应的数据节点的访问。

协同服务模块608，提供对数据节点的各种服务,具有管理数据节点的能力。

监控模块606，用于对被锁定的业务资源对应的业务节点服务器的状态进行监控，并基于其状态的变化，实现对相关的数据节点进行调整。监控模块606还负责对极端情况进行校验，如业务节点服务器重启、且时间在协同连接心跳检查时间间隔之内监控不到状态变化，或者服务器FullGC时没有响应时，需要协同服务模块604进行调整，比如直接删除相应的数据节点，以释放业务资源。

模块工作原理

锁接入模块602是对外提供服务的模块，并调用协同连接模块604完成对数据节点的访问操作。协同服务模块608负责接收协同锁接入模块602的请求，执行节点的操作行为。监控模块606负责保证锁数据节点与业务节点的一致性。

（1）锁接入模块602是业务接入门户。对业务锁请求，根据请求发生时的上下文，请求锁的模式等信息，转化成锁的内存结构。

（2）对于添加排他锁的请求，判断是否已经存在该资源的锁（排他锁或共享锁），如果存在，则返回加锁失败；如果不存在，构造排他锁的结构并加锁。

（3）对于添加共享锁的请求，判断是否已经存在该资源的锁，如果存在排他锁，则返回加锁失败；如果存在共享锁，则在当前锁信息列表中增加当前加锁的请求环境信息；如果不存在，构造共享锁结构，并加锁。

（4）锁接入模块602采用缓存机制，对本节点增加的锁，在内存中保存备份。

（5）协同服务模块608能够根据锁接入模块602接收到的客户端请求，创建不同类型的数据节点，如临时类型和永久类型。临时类型的节点，当客户端退出时或异常终止时，该节点自动删除；永久类型的节点，客户端退出后，节点不会删除，只有显式调用删除命令时，才会删除。

（6）协同连接模块604实现跨进程的锁功能，实现方式是：在协同服务模块608对应的协同服务器创建一个目录节点，然后通过调用子节点方法获取当前的目录节点列表中最小的目录节点，并确定其是否为自己创建的目录节点，如果是，则确定获得了这个锁，如果不是，则监控协同服务器上的目录节点列表的变化，一直到自己创建的节点是列表中最小编号的目录节点，从而确定获得锁。需要释放锁对应的业务资源时，只要删除前述的其自身创建的目录节点即可。

（7）协同连接模块604初始化之后会一直对协同服务集群的连接进行监听，一旦发现连接状态发生变化，重建协同连接实例，保证与协同服务集群的可靠连接。

（8）在极端情况下,如业务节点服务器内存空闲区太小时，FullGC时间过长，甚至超过心跳检查的时间间隔时，出现会话过期，监听模块606监听该状态并重新创建协同连接实例，并与协同服务器同步本地缓存中的锁信息。

业务使用场景

业务操作如果涉及到共享资源，其过程为：

1）首先请求该资源的锁。

2）如果请求成功，进行业务操作；如果请求失败，进行重试机制或者提示。

3）操作结束，释放该资源的锁。

例如，在分布式环境某次操作中需要申请生成单据号，因为同一类型的单据号不能重复，所以需要有业务加锁的过程：

（1）首先请求该单据类型的锁。

（2）如果请求成功，说明此时刻没有并发请求生成该类型单据号的操作，生成单据号；如果请求失败，说明此时刻存在并发请求生成该类型单据号的操作，提示用户等待或者过段时间自动重试请求锁。

（3）单据号生成后，释放该单据类型的锁。

其中，对于前台发起的请求，其加锁和解锁都发生在前台，如果前台程序正常或异常退出，监控模块606会将当前用户的所有锁释放掉；对于后台服务发起的请求，其加锁和解锁的过程都发生在业务节点上，如果业务节点服务器在操作过程中异常宕机或异常终止，监控模块606会将该服务器加的所有锁释放掉。当业务节点服务器重新启动时，监控模块606检查该服务器的锁，如果存在，则删除所有的锁，避免对应的业务资源无法释放，导致其他请求方无法申请添加新的锁。

以上结合附图详细说明了本发明的技术方案，本发明的特点是：

1.通用性高，该方法可以应用于大部分的分布式系统中。

2.非单点服务，提高了系统的健壮性。

3.适用于对等集群系统，易于系统动态扩展。

4.基于协同技术，协议简单，高效可靠。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种在分布式系统中锁定业务资源的系统，其特征在于，包括：

请求解析单元，用于解析接收到的业务资源锁定请求，获取锁定信息，所述锁定信息包括所述分布式系统中需要执行锁定的业务资源和锁定模式；

锁定执行单元，用于将创建的数据节点作为锁定所述业务资源的承载节点，并按照所述锁定模式，对所述业务资源执行锁定操作。

2.根据权利要求1所述的在分布式系统中锁定业务资源的系统，其特征在于，还包括：

第一判断单元，用于判断是否存在已建立的对应于所述业务资源的数据节点；

其中，所述锁定执行单元用于：

在所述第一判断单元的判断结果为不存在时，新建所述数据节点，并执行对所述业务资源的锁定操作；

在所述第一判断单元的判断结果为存在时，若所述锁定模式为排他锁定、或所述锁定模式为共享锁定且已存在的数据节点的锁定模式为排他锁定，则停止执行所述锁定操作并返回，若所述锁定模式为共享锁定且已存在的数据节点的锁定模式为共享锁定，则修改所述数据节点，以完成所述锁定操作。

3.根据权利要求1所述的在分布式系统中锁定业务资源的系统，其特征在于，还包括：

分类处理单元，用于按照预设的隔离条件对建立的数据节点进行分类；

隔离管理单元，用于对每种类型的数据节点进行隔离管理，且同一数据节点对应于一个或多个所述隔离条件。

4.根据权利要求1所述的在分布式系统中锁定业务资源的系统，其特征在于，所述请求解析单元还用于：解析接收到的解锁请求，确定需要解除锁定的业务资源；

所述系统还包括：

第二判断单元，用于判断是否存在对应于所述需要解除锁定的业务资源的数据节点；

解锁执行单元，用于在所述第二判断单元的判断结果为存在时，若已存在的数据节点的锁定模式为排他锁，则直接删除，若已存在的数据节点的锁定模式为共享锁，则在共享数目为零时，删除所述已存在的数据节点。

5.根据权利要求1至4中任一项所述的在分布式系统中锁定业务资源的系统，其特征在于，还包括：

节点管理单元，用于监控被锁定的业务资源对应的业务节点的状态，以实现对相应的数据节点的管理。

6.一种在分布式系统中锁定业务资源的方法，其特征在于，包括：

步骤202，解析接收到的业务资源锁定请求，获取锁定信息，所述锁定信息包括所述分布式系统中需要执行锁定的业务资源和锁定模式；

步骤204，将创建的数据节点作为锁定所述业务资源的承载节点，并按照所述锁定模式，对所述业务资源执行锁定操作。

7.根据权利要求6所述的在分布式系统中锁定业务资源的方法，其特征在于，所述步骤204还包括：

判断是否存在已建立的对应于所述业务资源的数据节点，当不存在时，新建所述数据节点，并执行对所述业务资源的锁定操作；

当存在时，若所述锁定模式为排他锁定、或所述锁定模式为共享锁定且已存在的数据节点的锁定模式为排他锁定，则停止执行所述锁定操作并返回，若所述锁定模式为共享锁定且已存在的数据节点的锁定模式为共享锁定，则修改所述数据节点，以完成所述锁定操作。

8.根据权利要求6所述的在分布式系统中锁定业务资源的方法，其特征在于，还包括：

按照预设的隔离条件对建立的数据节点进行分类；

对每种类型的数据节点进行隔离管理，且同一数据节点对应于一个或多个所述隔离条件。

9.根据权利要求6所述的在分布式系统中锁定业务资源的方法，其特征在于，还包括：

解析接收到的解锁请求，确定需要解除锁定的业务资源；

判断是否存在对应于所述需要解除锁定的业务资源的数据节点，当存在时，若已存在的数据节点的锁定模式为排他锁，则直接删除，若已存在的数据节点的锁定模式为共享锁，则在共享数目为零时，删除所述已存在的数据节点。

10.根据权利要求6至9中任一项所述的在分布式系统中锁定业务资源的方法，其特征在于，还包括：

监控被锁定的业务资源对应的业务节点的状态，以实现对相应的数据节点的管理。

Images