分布式锁协调方法、装置、设备及存储介质与流程

本申请涉及数据处理技术领域，具体而言，涉及一种分布式锁协调方法、装置、设备及存储介质。

背景技术

为了防止分布式系统中的多个进程之间相互干扰，我们需要一种分布式协调技术来对这些进程进行调度（如：Master-Worker模式）。而这个分布式协调技术的核心就是来实现这个分布式锁。

基于ZooKeeper实现分布式锁的方式一般为创建一个目录，线程A想获取锁就在该目录下创建临时顺序节点；随后各节点获取目录下所有的子节点，然后确定目录下是否存在比自己小的兄弟节点，如果不存在，则说明当前节点线程顺序号最小，则当前获得锁。

但是这样的处理方式无法获取当前获取锁的主节点信息，不利于功能的扩展，并且上述被动抢锁的方式容错性较低。

技术实现要素：

本申请的目的在于，针对上述现有技术中的不足，提供一种分布式锁协调方法、装置、设备及存储介质，以解决现有技术中无法获取当前获取锁的主节点信息，不利于功能的扩展，并且上述被动抢锁的方式容错性较低的问题。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请一实施例提供了一种分布式锁协调方法，所述方法包括：

若检测到主节点与预设业务类型节点下的集群节点断连，则由集群节点下的多个从节点，在所述集群节点下竞争创建状态节点；

确定所述多个从节点中成功创建所述状态节点的目标从节点为新的主节点；

将所述新的主节点的节点信息回写到所述状态节点中，以指示所述新的主节点获取到分布式锁。

可选地，所述由集群节点下的多个从节点在所述集群节点下竞争创建状态节点之前，所述方法还包括：

所述多个从节点在监听到所述主节点断连的情况下，等待预设获取时延之后在所述集群节点下竞争创建所述状态节点。

可选地，所述方法还包括：

所述主节点在触发所述断连之后的所述预设获取时延内，在所述集群节点下重新创建所述状态节点。

可选地，所述方法还包括:

若所述主节点重新创建所述状态节点失败，则所述主节点将状态从主节点更新为从节点。

可选地，所述由集群节点下的多个从节点在所述集群节点下竞争创建状态节点之前，所述方法还包括：

所述主节点与预设业务类型节点下的集群节点断连后，触发主节点的状态节点删除事件，以指示所述多个从节点竞争创建状态节点。

可选地，所述方法还包括：

所述多个从节点中创建失败的从节点继续监听所述主节点的状态节点删除事件。

可选地，所述若检测到主节点与预设业务类型节点下的集群节点断连，则由集群节点下的多个从节点在所述集群下竞争创建状态节点之前，所述方法还包括：

所述集群节点下的多个节点竞争创建所述状态节点；

确定所述多个节点中成功创建所述状态节点的应用节点为所述主节点，并将所述主节点的节点信息回写到所述状态节点中，以指示所述主节点获取到分布式锁。

可选地，所述由所述集群节点下的多个节点竞争创建所述状态节点之前，所述方法还包括：

创建所述预设业务类型节点；

基于所述预设业务类型节点创建所述集群节点，其中，所述预设业务类型节点和所述集群节点均为永久节点；

将所述多个节点注册至所述集群节点下。

第二方面，本申请另一实施例提供了一种分布式锁协调装置，所述装置包括：创建模块，确定模块和回写模块，其中：

所述创建模块，用于若检测到主节点与预设业务类型节点下的集群节点断连，则由集群节点下的多个从节点，在所述集群节点下竞争创建状态节点；

所述确定模块，用于确定所述多个从节点中成功创建所述状态节点的目标从节点为新的主节点；

所述回写模块，用于将所述新的主节点的节点信息回写到所述状态节点中，以指示所述新的主节点获取到分布式锁。

可选地，所述创建模块，具体用于所述多个从节点在监听到所述主节点断连的情况下，等待预设获取时延之后在所述集群节点下竞争创建所述状态节点。

可选地，所述创建模块，具体用于所述主节点在触发所述断连之后的所述预设获取时延内，在所述预设业务类型节点下重新创建所述状态节点。

可选地，所述装置还包括：更新模块，用于若所述主节点重新创建所述状态节点失败，则所述主节点将状态从主节点更新为从节点。

可选地，所述装置还包括：触发模块，用于所述主节点与预设业务类型节点下的集群节点断连后，触发主节点的状态节点删除事件，以指示所述多个从节点竞争创建状态节点。

可选地，所述装置还包括：监听模块，用于所述多个从节点中创建失败的从节点继续监听所述状态节点删除事件。

可选地，所述主节点和各所述从节点的节点信息分别包括：节点IP地址和端口信息。

可选地，所述创建模块，具体用于所述集群节点下的多个节点竞争创建所述状态节点；

所述确定模块，具体用于确定所述多个节点中成功创建所述状态节点的应用节点为所述主节点，并将所述主节点的节点信息回写到所述状态节点中，以指示所述主节点获取到分布式锁。

可选地，所述装置还包括：注册模块，其中：

所述创建模块，具体用于创建所述预设业务类型节点；基于所述预设业务类型节点创建所述集群节点，其中，所述预设业务类型节点和所述集群节点均为永久节点；

所述注册模块，具体用于将所述多个节点注册至所述集群节点下。

第三方面，本申请另一实施例提供了一种分布式锁协调设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当分布式锁协调设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如上述第一方面任一所述方法的步骤。

第四方面，本申请另一实施例提供了一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如上述第一方面任一所述方法的步骤。

本申请的有益效果是：采用本申请提供的分布式锁协调方法，在检测到主节点与集群节点断连后，与主节点同一集群节点下的其他从节点随即在集群节点下竞争创建状态节点，并确定创建成功的目标从节点为新的主节点，并将新的主节点的节点信息写入状态节点中，以指示新的主节点获取到了分布式锁，这样的方法主节点的设置是各从节点在主节点与集群节点断连后，主动发起的获取，并且在新的主节点获取成功后会将新的主节点的信息回写至状态节点中，有利于后续功能的扩展，和提高容错，便于可以直接根据状态节点确定当前获取到分布式锁的主节点。

附图说明

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

图1为本申请一实施例提供的ZooKeeper中的节点结构示意图；

图2为本申请另一实施例提供的ZooKeeper中的节点结构示意图；

图3为本申请另一实施例提供的ZooKeeper中的节点结构示意图；

图4为本申请一实施例提供的分布式锁协调方法的流程示意图；

图5为本申请另一实施例提供的分布式锁协调方法的流程示意图；

图6为本申请另一实施例提供的分布式锁协调方法的流程示意图；

图7为本申请另一实施例提供的分布式锁协调方法的流程示意图；

图8为本申请一实施例提供的分布式锁协调装置的结构示意图；

图9为本申请另一实施例提供的分布式锁协调装置的结构示意图；

图10为本申请一实施例提供的分布式锁协调设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

另外，本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

在介绍本申请之前，先对本申请的应用场景、现有技术以及解决的技术问题进行简单地描述。

分布式系统（distributed system）是建立在网络之上的软件系统；分布式操作系统中包括多个处理器，其可以以全局方式对系统资源进行管理，并为用户任意调度网络资源，且调度过程是“透明”的。举例说明，当用户提交一个作业时，分布式操作系统能够根据需要在系统中选择最合适的处理器，将用户的作业提交到该处理器中进行处理，在处理器完成作业后，将处理结果传给用户。在这个过程中，用户并不会意识到有多个处理器的存在，整个系统就像是一个处理器一样。

由于分布式系统中同一时间可能存在多个线程，但是为了防止分布式系统中的多个进程之间相互干扰，保证一个方法或一个属性在高并发的情况下只能同一个线程执行，需要一种分布式协调技术来对这些进程进行调度（如：Master-Worker模式），而这个分布式协调技术的核心就是分布式锁。

分布式系统中，动物园管理员（ZooKeeper）是一种高性能协调系统，其可以为分布式应用提供一致性服务的软件，提供的功能可以但不限于包括：命名服务、配置管理、分布式锁及集群管理等，本申请中提出的分布式锁协调方法以ZooKeeper作为示例实现。

具体的，ZooKeeper中数据存储结构就像是一棵树，其由多个节点组成，这些节点可以分为四种类型，分别为：永久节点（PERSISTENT）、永久节点的顺序节点（PERSISTENT_SEQUENTIAL）、临时节点（EPHEMERAL）及临时节点的顺序节点（EPHEMERAL_SEQUENTIAL）；

其中，永久节点：默认的节点类型，永久节点被创建后，就会一直存在于Zookeeper服务器上，直到该永久节点被手动删除。

永久节点的顺序节点：它的基本特性与持久节点相同，不同之处在于增加了顺序性；在创建节点时，ZooKeeper根据创建的时间顺序给该节点名称进行编号，父节点会维护一个自增整性数字，用于子节点的创建的先后顺序；当创建永久节点被创建后，就会一直存在于Zookeeper服务器上，直到该永久节点的顺序节点被手动删除。

临时节点：临时节点的生命周期与客户端的会话绑定，一旦客户端会话失效，那么临时节点就会被自动清理掉；zookeeper规定临时节点只能作为叶子节点。

临时节点的顺序节点：在创建节点时，ZooKeeper根据创建的时间顺序给该节点名称进行编号；父节点会维护一个自增整性数字，用于子节点的创建的先后顺序；当客户端会话失效，那么临时节点就会被自动清理掉；zookeeper规定临时节点的顺序节点只能作为叶子节点。

为了介绍ZooKeeper中节点之间的结构，以及节点抢锁的抢锁方式和抢锁过程，下面提供一种可能的实现方式，具体的，图1为本申请一实施例提供的ZooKeeper中的节点结构示意图，如图1所示，在ZooKeeper中实现分布式锁的原理为：首先，在Zookeeper中创建一个持久节点ParentLock作为目录节点。当客户端节点1（Client1）想要获得锁时，需要在目录节点下创建一个临时顺序节点1（Lock1），随后Client1查询目录节点下所有的临时顺序节点并排序，判断自己所创建的Lock1节点是不是当前所有临时顺序节点中排序最靠前的一个，若是，则说明当前Lock1节点的顺序号最小，则获得锁，此时获得分布式锁的Client1即为当前目录节点下的主节点。

为了介绍ZooKeeper中存在多个节点时的系统结构，以及多个节点抢锁的抢锁方式和抢锁过程，下面提供一种可能的实现方式，具体的，图2为本申请另一实施例提供的ZooKeeper中的节点结构示意图，如图2所示，在图1的基础上，如果客户端节点2（Client2）和客户端节点3（Client3）前来获取锁，则需要分别在目录节点下分别创建一个Client2对应的临时顺序节点2（Lock2），一个Client3对应的临时顺序节点3（Lock）；Client2查找目录节点下面所有的临时顺序节点并排序，判断自己所创建的Lock2节点是不是顺序最靠前的一个，如果不是，则说明当前Lock2节点顺序号并不是最小的。于是，Client2向排序仅比它靠前的Lock1节点注册观察（Watcher），用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。

同时Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3节点是不是顺序最靠前的一个，结果同样发现Lock3节点的序列号并不是最小的。于是，Client3向排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态；此时获得分布式锁的Client1即为当前目录节点下的主节点，参与获取分布式锁的Client2和Client3均为当前目录下的从节点。

这样一来，在此次抢锁过程中，Client1得到了锁，Client2监听了Lock1节点，Client3监听了Lock2节点，这恰恰形成了一个等待队列，保证了同一时刻只有一个客户端节点可以获得锁，避免了客户端节点之间的互相干扰。

为了介绍ZooKeeper中已经存在抢锁成功的主节点和从节点，并且主节点删除事件被触发后，其他从节点进行抢锁的抢锁方式和抢锁过程，下面提供一种可能的实现方式，具体的，图3为本申请另一实施例提供的ZooKeeper中的节点结构示意图，如图3所示，在图2的基础上，若Client1的任务执行完成、或执行任务的过程中Client1发生异常，导致与ZooKeeper断开连接，则均会触发Lock1节点的删除事件。

由于Client2一直监听着Lock1节点的存在状态，当Lock1节点被删除，Client2会立刻收到Lock1节点不存在的通知。这时Client2会再次查询目录节点下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁，成为了当前目录节点下的主节点，此时Client3为当前目录节点下的从节点。

但是，发明人发现，现有技术中基于ZooKeeper实现的分布式锁功能都是通过判断当前最小节点编号来实现的，也即通过被动式获取实现的，这样的获取方式在从节点仅能监听主节点创建的临时节点的存在状态，并不能获取主节点的信息，这不利于后续功能的扩展和容错。

因此，本申请提供了一种分布式锁协调方法，在目录节点下引入了状态节点，在本申请中，状态节点为一个如上文所述的临时节点，目录节点下的各节点可以通过主动式获取的方式获取状态节点的写入权限，并由获取成功的节点创建该状态节点的，该成功创建状态节点的节点即为获得了分布式锁的节点，也即为当前目录节点下的主节点。

主节点在获取到分布式锁之后，还需要将主节点信息回写到状态节点中，从而在后续获取主节点信息，或者监控主节点时，可以直接读取状态节点中的信息就可以确定主节点信息，有利于功能的扩展和容错。

如下结合多个具体的应用示例，对本申请实施例所提供的一种分布式锁协调方法进行解释说明。图4为本申请一实施例提供的一种分布式锁协调方法的流程示意图，如图4所示，该方法包括：

S111：若检测到主节点与预设业务类型节点下的集群节点断连，则由集群节点下的多个从节点，在集群节点下竞争创建状态节点。

在本申请的实施例中，各节点例如可以为基于ZooKeeper的节点，每个预设业务类型节点下均有一个集群节点，此处的集群节点相当于图1-图3中的目录节点，即每个预设业务类型下均有一个该预设业务类型对应的目录节点，并且各集群节点下包括主节点和至少一个从节点，各节点均为该预设业务类型对应的客户端注册并写入的。

预先在集群节点下成功创建状态节点的节点即为主节点，也即主节点为当前获得分布式锁的节点，其他从节点即为当前未获得分布式锁的节点，应当理解在本申请的实施例中，在同一时刻下，一个集群节点下只有一个节点可以获取到分布式锁，也即同一时刻下一个集群节点中只存在一个主节点。

其中，在本申请的实施例中，预设业务类型节点和集群节点均为永久节点，集群节点下的各节点为临时节点。

下述实施例中的集群节点均为预设业务类型下的集群节点，在使用过程中，集群节点下的主节点可能由于异常情况导致与集群节点断连，与主节点位于同一集群节点下的多个从节点在接收到主节点断连事件的通知后，会纷纷参与获取竞争创建状态节点，通过获取在集群节点下创建状态节点，来获取分布式锁。

S112：确定多个从节点中成功创建状态节点的目标从节点为新的主节点。

其中，在多个从节点获取创建状态节点的情况下，优先成功在集群节点下创建状态节点的目标从节点为集群节点下的新的主节点，状态节点创建成功后，其余节点将不会再竞争创建状态节点，而是监听新的主节点与集群节点之间的连接状况，只有在新的主节点与集群节点断连时，该集群节点下的其他从节点才会竞争创建状态节点，并在状态节点创建成功后停止其他节点竞争创建状态节点，其他创建失败的从节点继续等待下一次主节点与集群节点断连，即由多个从节点中创建失败的从节点继续监听主节点的与集群节点的连接状况，并在接收到主节点与集群节点断连后，再次在集群节点下竞争创建状态节点。

S113：将新的主节点的节点信息回写到状态节点中。

以指示新的主节点获取到分布式锁；其中，将主节点信息回写到状态节点中，可以在后续需要获取主节点信息，或者需要对主节点进行监控时，可以通过直接读取状态节点中的信息的方式，直接确定当前主节点的信息。

采用本申请提供的分布式锁协调方法，在检测到主节点与集群节点断连后，与主节点同一预设集群节点下的其他从节点随即在集群节点下竞争创建状态节点，并确定创建成功的目标从节点为当前集群节点下的新的主节点，并将新的主节点的节点信息写入状态节点中，以指示新的主节点获取到了分布式锁，这样的方法由于主节点的设置是各从节点在主节点与集群节点断连后，主动发起的获取，并且在新的主节点获取成功后会将新的主节点的信息回写至状态节点中，有利于后续功能的扩展，和提高容错，便于可以直接根据状态节点确定当前获取到分布式锁的主节点。

在一些可能的实施例中，主节点和各从节点的节点信息分别包括：节点网络之间互连的协议（Internet Protocol，IP）地址和端口信息，端口信息例如可以为端口编号信息等，应当理解上述实施例仅为示例性说明，具体节点信息包括的内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

可选地，在上述实施例的基础上，本申请实施例还可提供一种分布式锁协调方法，如下结合附图对上述方法的实现过程进行示例说明。图5为本申请另一实施例提供的一种分布式锁协调方法的流程示意图，如图5所示，S101之前，该方法还可包括：

S104：集群节点下的多个节点竞争创建状态节点。

其中，在预设业务类型下的集群节点下的多个节点中还没有主节点的情况下，例如在集群节点的初始状态下，或在集群节点下的主节点断连的情况下，由该集群节点下的所有正常连接的节点共同竞争创建状态节点。

S105：确定多个应用节点中成功创建状态节点的应用节点为主节点，并将主节点的节点信息回写到状态节点中。

将主节点的节点信息回写到状态节点中以指示主节点获取到分布式锁，即竞争成功的节点为当前集群类型下的主节点，并且主节点可以将自己的节点信息回写到状态节点中。

集群类型下的竞争失败的其他节点将会作为从节点，获取状态节点中的节点信息，即获取主节点信息，并根据主节点信息监听主节点与集群节点的连接状态，若主节点与预设业务类型下的集群节点的连接状态为断连，则触发当前状态节点删除事件，集群节点下监听到状态节点删除事件的所有从节点将可以再次竞争在集群节点下创建状态节点。

在本申请的实施例中，状态节点的节点类型也为临时节点，是集群节点下的主节点在集群节点下创建的临时节点，同一时刻下同一集群节点下只包括一个状态节点，成功创建临时节点的节点即为当前集群中的主节点，即为获取了分布式锁的节点。

可选地，在上述实施例的基础上，本申请实施例还可提供一种分布式锁协调方法，如下结合附图对上述方法的实现过程进行示例说明。图6为本申请另一实施例提供的一种分布式锁协调方法的流程示意图，如图6所示，S104之前，该方法还包括：

S101：创建预设业务类型节点。

其中，预设业务类型的节点可以根据不同的业务场景设置不同的预设业务类型节点，例如银行场景下可以设置银行业务类型节点，或金融场景下可以设置金融业务类型节点，一个业务场景下可能包括一个或多个预设业务类型节点，应当理解上述实施例仅为示例性说明，具体预设业务类型节点包括的业务类型以及确定方式均可以根据用户需要灵活调整，并不以上述实施例给出的为限。

S102：基于业务类型节点创建集群节点。

其中，预设业务类型节点和集群节点均为永久节点，一个预设业务类型节点下只存在一个集群节点，集群节点相当于图1中的目录节点，用于各客户端在集群节点下创建各客户端对应的临时节点。

S103：将多个节点注册至集群节点下。

其中，多个节点的节点类型为临时节点，在各客户端注册节点至集群节点下时，例如可以基于集群节点通过zookeeper提供的API，注册各客户端对应的临时节点类型的节点，通过这种注册方式注册的各节点，各客户端对应节点的节点名均是按照自己的节点IP和端口信息确定的，所以可以直接根据各节点获取各节点对应的节点信息，方便后续对该业务类型节点下的各节点进行监控。

在本申请的一个实施例中，主节点与预设业务类型节点下的集群节点断连后，触发主节点的状态节点删除事件，以指示多个从节点竞争创建状态节点，由于其他多个从节点一直在对主节点的状态进行监控，因此在监控到主节点的状态节点删除事件后，从节点即确定当前主节点断连；此时各从节点可以竞争创建状态节点，优先创建成功的即成为信息的主节点，获取当前分布式锁。

可选地，在上述实施例的基础上，本申请实施例还可提供一种分布式锁协调方法，如下结合附图对上述方法的实现过程进行示例说明。图7为本申请另一实施例提供的一种分布式锁协调方法的流程示意图，如图7所示，S111之前，该方法还可包括：

S106：多个从节点在监听到主节点断连的情况下，等待预设获取时延之后在预设业务类型节点下竞争创建状态节点。

对应地，在预设获取时延内，即使主节点断连导致状态节点被删除，还是可以由主节点在触发断连之后的预设获取时延内，在集群节点下重新创建状态节点。

其中，预设获取时延的设置用于避免在一些网络闪断的情况下，减少非必要的获取操作，即防止在网络闪断等异常情况下，主从节点频繁切换的问题，减少非必要的获取操作。

主节点与预设业务类型节点下的集群节点断连后，会触发节点删除事件，断连后的主节点在集群节点中的临时节点会被删除，并且在集群节点下创建的临时状态节点也会被删除，但是在本申请的实施例中，在预设获取时延内，即使主节点已经断连，仍可以在重新连接后，在集群节点中创建自己对应的节点，并基于该节点在集群节点下重新创建状态节点，在预设获取时延时间内，即使主节点与预设业务类型节点下的集群节点断连，其他从节点也不可以竞争创建状态节点，只有在预设获取时延时间之后，当前集群节点下仍不存在状态节点时，该集群节点下的从节点才可以竞争创建状态节点。

在本申请的实施例中，在主节点因异常与预设业务类型节点下的集群节点断连时，本地会启动一个线程计时器，用于计时当前时间是否超过预设获取时延时间，从而避免在同一集群节点下出现双主节点的情况，若主节点在计时器未结束之前，重新连接上集群节点并重新创建状态节点，则停止计时；否则在计时结束后，其他从节点将会在集群节点下竞争创建状态节点。

若主节点重新创建状态节点失败，则主节点将节点状态从主节点更新为从节点，由主节点更新为从节点的节点，在后续抢锁过程中也可以跟其他从节点一起竞争创建状态节点。

采用本申请提供的分布式锁协调方法，通过主动抢锁的方式，确定抢先创建状态节点的节点为当前集群节点下的主节点，并且在主节点与集群节点断连之后，通过预设获取时延时间的设置，防止了因为网络抖动造成频繁主从节点之间频繁切换，导致反复初始化、或数据冗余或出现双主节点的问题，此外由于本申请在创建各应用节点时，是根据各节点的IP信息和端口信息创建的，并且状态节点中也写入了主节点信息，因此可以直接查看当前集群节点下包括的各个节点，并且可以通过查看状态节点查看当前集群节点下的主节点信息，从而使得后续对各节点的监控更加简单直观，本申请提供的方法具备一定的容错机制，不但可以很好地解决上述问题，并且还可以提升系统的稳定性与性能。

下述结合附图对本申请所提供的分布式锁协调装置进行解释说明，该分布式锁协调装置可执行上述图1-图7任一分布式锁协调方法，其具体实现以及有益效果参照上述，如下不再赘述。

图8为本申请一实施例提供的分布式锁协调装置的结构示意图，如图8所示，该装置可以包括：创建模块201，确定模块202和回写模块203，其中：

创建模块201，用于若检测到主节点与预设业务类型节点下的集群节点断连，则由集群节点下的多个从节点，在集群节点下竞争创建状态节点。

确定模块202，用于确定多个从节点中成功创建状态节点的目标从节点为新的主节点。

回写模块203，用于将新的主节点的节点信息回写到状态节点中，以指示新的主节点获取到分布式锁。

可选地，创建模块201，具体用于由多个从节点在监听到主节点断连的情况下，等待预设获取时延之后在集群节点下竞争创建状态节点。

可选地，创建模块201，具体用于由主节点在触发断连之后的预设获取时延内，在集群节点下重新创建状态节点。

在上述实施例的基础上，本申请实施例还可提供一种分布式锁协调装置，如下结合附图对上述图8给出的装置的实现过程进行示例说明。图9为本申请另一实施例提供的分布式锁协调装置的结构示意图，如图9所示，该装置还包括：更新模块204，用于若主节点重新创建状态节点失败，则主节点将状态从主节点更新为从节点。

如图9所示，该装置还包括：触发模块205，用于主节点与预设业务类型节点下的集群节点断连后，触发主节点的状态节点删除事件，以指示所述多个从节点竞争创建状态节点。

如图9所示，该装置还包括：监听模块206，用于由多个从节点中创建失败的从节点继续监听主节点的状态节点删除事件。

可选地，主节点和各从节点的节点信息分别包括：节点IP地址和端口信息。

可选地，创建模块201，具体用于由集群节点下的多个节点竞争创建状态节点。

确定模块202，具体用于确定多个节点中成功创建状态节点的应用节点为主节点，并将主节点的节点信息回写到状态节点中，以指示主节点获取到分布式锁。

如图9所示，该装置还包括：注册模块207，其中：

创建模块201，具体用于创建预设业务类型节点；基于预设业务类型节点创建集群节点，其中，预设业务类型节点和集群节点均为永久节点。

注册模块207，具体用于将多个节点注册至集群节点下。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路（Application Specific Integrated Circuit，简称ASIC），或，一个或多个微处理器，或，一个或者多个现场可编程门阵列（Field Programmable Gate Array，简称FPGA）等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器（Central Processing Unit，简称CPU）或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统（system-on-a-chip，简称SOC）的形式实现。

图10为本申请一实施例提供的分布式锁协调设备的结构示意图，该分布式锁协调设备可以集成于终端设备或者终端设备的芯片。

如图10所示，该分布式锁协调设备包括：处理器501、存储介质502和总线503。

处理器501用于存储程序，处理器501调用存储介质502存储的程序，以执行上述图1-图7对应的方法实施例。具体实现方式和技术效果类似，这里不再赘述。

可选地，本申请还提供一种程序产品，例如存储介质，该存储介质上存储有计算机程序，包括程序，该程序在被处理器运行时执行上述方法对应的实施例。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（英文：processor）执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（英文：Read-Only Memory，简称：ROM）、随机存取存储器（英文：Random Access Memory，简称：RAM）、磁碟或者光盘等各种可以存储程序代码的介质。