CN109101341A - 分布式锁的分配方法及设备 - Google Patents

Abstract

本申请的目的是提供一种分布式锁的分配方法及设备，在确保分布式锁正确性的前提下，每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，通过由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，从而支持在服务进程在故障切换场景下服务替换进程零等待地、主动地快速地继承原分布式锁所有权，避免现有技术中存在的不可服务的时间窗口问题，显著提升Failover场景下业务服务的连续性。

Description

分布式锁的分配方法及设备

技术领域

本申请涉及计算机领域，尤其涉及一种分布式锁的分配方法及设备。

背景技术

大规模云计算场景中，为了保障数据的分布式一致性，数量众多的计算节点往往依赖分布式锁服务来同步各自对某共享资源的访问，或者是协调各计算节点之间的行为动作。目前业界知名的支持分布式锁服务的产品有Google的Chubby，Yahoo的Zookeeper，以及CoreOS的Etcd等等。

分布式锁服务在大规模云计算场景中被广泛使用，分布在不同计算节点上的客户端进程通常依赖分布式锁来访问服务端的共享资源，保证数据分布式一致性。典型的分布式锁服务是基于分布式一致性系统提供的Ephemeral文件(锁文件)操作接口实现的。具体来看，分布式锁的抢锁是基于创建Ephemeral文件操作接口设计的，而分布式锁释放锁则是基于删除Ephemeral文件操作接口实现的。

Quorum是分布式一致性系统服务端Servers集合。每个Quorum Server均维护着分布式一致性系统的内存数据库，以及持久化存储的事务日志与快照数据。分布式一致性系统中的Ephemeral文件有所有权(Owner)概念，这确保了分布式锁的互斥性。Quorum Server端会记录创建Ephemeral文件的Client进程对应的Session信息，其它Client进程尝试创建已存在Ephemeral文件，Quorum Server通过检查该Ephemeral文件归属的Session与尝试创建的Client进程对应的Session不匹配，则告知Client创建文件失败，即争抢分布式锁失败。

Session是分布式一致性系统中Client(客户端)在Server(服务端)注册的全局唯一的会话，依赖Client与Server定期心跳来分别更新在Client以及Server两端生命期。分布式一致性系统中的Ephemeral File(锁文件)还有生命期概念，这确保了分布式锁的最终可用性。Ephemeral File(锁文件)是分布式一致性系统中的临时文件。该类型文件有明确归属Session，仅可被归属Session操作。一旦对应归属Session在Server端过期，该类型文件在Server端会被自动删除。Ephemeral文件生命期，即其归属Session的生命期，依赖Client进程与Quorum Server定期心跳来更新：Client进程在Client端认定的Session超时时间内没有收到任何来自Quorum Server的心跳包回复，则判定Session超时，确认丢锁；然后，Quorum Server在Quorum Server端认定的Session超时时间内没有接收到任何来自Client进程心跳包，则判定Session超时，主动删除锁文件，释放该分布式锁所有权。

当前基于Session实现的分布式锁所有权管理机制，因为Session本身与Client进程与Quorum Server之间建立的连接是耦合的，因此当占据分布式锁所有权的业务服务进程发生Failover时，重新被拉起的Client进程会与Quorum Server建立新的连接，并在该连接上创建新的Session，Client进程即基于该新的Session重新争抢分布式锁所有权。事实上，基于Session实现的分布式锁生命期管理机制，为了确保分布式锁正确性，当Client进程挂掉之后，其占据的分布式锁在Quorum Server端还会继续保留一段时间，这个也就导致了重新拉起的服务进程会在这段时间内无法争抢到分布式锁所有权。从业务角度来看，在Failover场景下，会因此产生一个由于分布式锁一段时间不可用而导致的业务不可服务时间窗口。

分布式锁的生命期，即占有分布式锁所有权的Client与Quorum Server之间建立连接上耦合的Session的生命期，依赖着Client与Quorum Server之间定期心跳来更新。Client与Quorum Server，如果在各自端的Session超时时间内没有收到心跳，则判定各自端Session超时。这里必须遵循“Quorum Server比Client后判定Session过期”这一原则，否则会出现Client依旧认为自己占据Session对应分布式锁所有权，Quorum Server却判定Session超时，释放分布式锁所有权，导致其余Client同时抢锁成功，从而出现多个Client均认为自己占有同一分布式锁的数据不一致后果。因此，Client与Quorum Server需要合理协商两端的Session过期时间。

图1展示的是在最坏情况下，Quorum Server立即收到来自Client心跳，开启新一轮Quorum Server端Session生命期。Client刚好在本端Session超时前收到来自QuorumServer的心跳回复。Client也开始下一轮Session生命期，然后继续发送心跳，如果该心跳包异常丢失，那么Client会在其第二个Session生命期结束时判定Client端Session过期，而此时一直在等待心跳的Quorum Server也必须在这之后判断Session在Quorum Server端过期。因此，Quorum Server端Session生命期至少为2倍Client端Session生命期，这样可确保Client、Quorum Server双方对同一分布式锁的Session有效期判断可以维持分布式一致性。

在分布式应用服务中，应用服务进程发生Failover(故障切换)是比较常见事件。图2展示的现有的占据分布式锁所有权的应用进程在发生Failover场景下继续服务的方案。原服务进程Client A通过建立连接，创建Session，然后争抢到分布式锁所有权。然后，Client A通过与Quorum Server定期心跳来维护Session有效期，亦即分布式锁所有权。当发生Failover时，新的服务进程Client A’被拉起，同样需要建立至Quorum Server的连接，并在连接上创建新的Session。Client A’基于新的Session重新争抢原分布式锁所有权，最终会争抢成功，然后恢复提供业务服务。

现有的解决方案中，发生Failover的Client进程，断开了与Quorum Server的连接，而与该连接耦合的Session，亦即分布式锁实际占有者，在Quorum Server端尚未过期，因此依旧在Server端存活着。重新被拉起来的Client进程会与Quorum Server建立新的连接，并且在新的连接上创建新的Session。因为新创建Session并非分布式锁的实际占有者，此时新的Client进程争抢分布式锁会失败。

如下图3所示，业务服务Client进程发生Failover时，Quorum Server对应Session生命期已经完成的部分为上次Quorum Server接收心跳时刻，至Client进程发生Failover时刻。具体Quorum Server端Session剩余生命期时间，从图3中分析，事实上最大值是接近Session在Quorum Server端整个Session生命期的，即图3中虚线部分的争抢分布式锁等待时间。

因此，新拉起的业务服务Client进程需要等待原Session在Quorum Server端过期后，分布式锁所有权被Quorum Server释放，方可重新争抢到分布式锁，继续提供业务服务。换言之，目前技术方案在Failover场景下，业务服务进程是存在一个明确的不可服务时间窗口的。

发明内容

本申请的一个目的是提供一种分布式锁的分配方法及设备，能够解决现有技术中存在的不可服务的时间窗口的问题。

根据本申请的一个方面，提供了一种在客户端的分布式锁的分配方法，该方法包括：为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

进一步的，上述方法中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，包括：由所述服务替换进程，向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端反馈尝试创建失败，由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

进一步的，上述方法中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，包括：由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,所述删除请求包含所述服务替换进程的进程标识；由所述服务替换进程向所述服务端发送同一分布式锁的新的锁文件的创建请求。

进一步的，上述方法中，由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,向所述服务端发送同一分布式锁的新的锁文件的创建请求，包括：向服务端发送事务序号获取请求，以从服务端的锁文件中获取锁文件在创建时的事务序号；由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求，所述删除请求中还包含所述锁文件在创建时的事务序号；从服务端接收所述锁文件是否删除成功的反馈，其中，所述服务端基于删除请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致反馈所述锁文件是否删除成功，若删除成功，则基于从服务端接收的删除成功的反馈，向所述服务端发送同一分布式锁的新的锁文件的创建请求。

进一步的，上述方法中，从服务端接收所述锁文件是否删除成功的反馈之后，还包括：若删除不成功，则从所述服务接收所述服务替换进程抢占的所述锁文件失败的反馈。

进一步的，上述方法中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送尝试重新创建同一布式锁的新的具有生命周期的锁文件的请求之后，还包括：若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

根据本申请的另一方面，还提供了一种服务端的分布式锁的分配方法，该方法包括：根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

进一步的，上述方法中，获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件，包括：根据从所述服务替换进程接收的尝试重新创建请求，尝试创建所述服务替换进程的同一分布式锁的新的锁文件，若尝试失败，向所述服务替换进程反馈尝试创建失败；获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件。

进一步的，上述方法中，获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件，包括：从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，根据所述删除锁文件的请求判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，删除所述服务进程所创建的锁文件；根据从服务替换进程接收的创建请求，为所述替换进程创建同一分布式锁的新的锁文件。

进一步的，上述方法中，创建对应的分布式锁的具有生命周期的锁文件的之后，还包括：在所述锁文件中写入其创建时的事务序号；从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，包括：根据从客户端接收的事务序号获取请求，向所述客户端发送锁文件在创建时的事务序号；从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识和所述锁文件在创建时的事务序号；删除所述服务进程所创建的锁文件，包括：判断所述删除锁文件请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致，若一致，删除所述服务进程所创建的锁文件，向所述服务替换进程反馈删除成功，获取所述服务替换进程发送的创建同一分布式锁的新的锁文件的请求。

进一步的，上述方法中，向所述服务替换进程反馈所述锁文件是否删除成功之后，还包括：若删除不成功，则向服务替换进程反馈抢占所述锁文件失败。

进一步的，上述方法中，尝试创建所述服务替换进程的同一分布式锁的新的锁文件之后，还包括：若尝试创建成功，则向所述服务替换进程反馈抢占所述分布式锁成功。

根据本申请的另一面，还提供一种客户端，该客户端包括：创建请求装置，用于为服务进程分配唯一的进程标识，供所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；故障切换装置，用于当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；继承请求装置，用于供所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

进一步的，上述客户端中，所述继承请求装置，用于供所述服务替换进程，向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端反馈尝试创建失败，供所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

进一步的，上述客户端中，所述继承请求装置，用于供所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,所述删除请求包含所述服务替换进程的进程标识；由所述服务替换进程向所述服务端发送同一分布式锁的新的锁文件的创建请求。

进一步的，上述客户端中，所述继承请求装置，用于向服务端发送事务序号获取请求，以从服务端的锁文件中获取锁文件在创建时的事务序号；供所述服务替换进程在所述生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求，所述删除请求中还包含所述锁文件在创建时的事务序号；从服务端接收所述锁文件是否删除成功的反馈，其中，所述服务端基于删除请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致反馈所述锁文件是否删除成功，若删除成功，则基于从服务端接收的删除成功的反馈，向所述服务端发送同一分布式锁的新的锁文件的创建请求。

进一步的，上述客户端中，所述继承请求装置，还用于从服务端接收所述锁文件是否删除成功的反馈之后，若删除不成功，则从所述服务接收所述服务替换进程抢占的所述锁文件失败的反馈。

进一步的，上述客户端中，所述继承请求装置，用于供所述服务替换进程在所述生命周期结束前，向所述服务端发送尝试重新创建同一布式锁的新的具有生命周期的锁文件的请求之后，若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

根据本申请的另一面，还提供一种服务端，该服务端包括：创建装置，用于根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；写入装置，用于根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；分配装置，用于获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

进一步的，上述服务端中，所述分配装置，用于根据从所述服务替换进程接收的尝试重新创建请求，尝试创建所述服务替换进程的同一分布式锁的新的锁文件，若尝试失败，向所述服务替换进程反馈尝试创建失败；获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件。

进一步的，上述服务端中，分配装置，用于从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，根据所述删除锁文件的请求判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，删除所述服务进程所创建的锁文件；根据从服务替换进程接收的创建请求，为所述替换进程创建同一分布式锁的新的锁文件。

进一步的，上述服务端中，所述写入装置，还用于在创建对应的分布式锁的具有生命周期的锁文件的之后，在所述锁文件中写入其创建时的事务序号；所述分配装置，用于根据从客户端接收的事务序号获取请求，向所述客户端发送锁文件在创建时的事务序号；从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识和所述锁文件在创建时的事务序号，判断所述删除锁文件请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致，若一致，删除所述服务进程所创建的锁文件，向所述服务替换进程反馈删除成功，获取所述服务替换进程发送的创建同一分布式锁的新的锁文件的请求。

进一步的，上述服务端中，分配装置，用于向所述服务替换进程反馈所述锁文件是否删除成功之后，若删除不成功，则向服务替换进程反馈抢占所述锁文件失败。

进一步的，上述服务端中，分配装置，用于尝试创建所述服务替换进程的同一分布式锁的新的锁文件之后，若尝试创建成功，则向所述服务替换进程反馈抢占所述分布式锁成功。

根据本申请的另一面，还提供一种基于计算的设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

根据本申请的另一面，还提供一种基于计算的设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

根据本申请的另一面，还提供一种存储可执行指令的非暂态计算机可读存储介质，在所述可执行指令由电子设备执行时，使得所述电子设备：

为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

根据本申请的另一面，还提供一种存储可执行指令的非暂态计算机可读存储介质，在所述可执行指令由电子设备执行时，使得所述电子设备：

根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

根据本申请的另一面，还提供一种锁文件的获取方法，包括：

第一服务进程被创建，其中，所述第一服务进程的进程标识与发生故障的第二服务进程的进程标识相同，所述第二服务进程对应于锁文件；

所述第一服务进程发送所述锁文件的继承请求，其中，所述继承请求包括所述第一服务进程的进程标识。

上述方法中，所述第一服务进程发送所述锁文件的继承请求，包括：

由所述第一服务进程发送尝试重新创建所述锁文件的请求，若尝试重新创建失败，

由所述第一服务进程发送所述分布式锁的所有权的继承请求。

根据本申请的另一面，还提供一种锁文件的获取方法，包括：

服务进程被创建，其中，所述服务进程包括进程标识；

所述服务进程发送锁文件的创建请求，其中，所述创建请求包括所述服务进程的进程标识。

上述方法中，所述服务进程发送锁文件的创建请求之后，还包括：

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程。

与现有技术相比，本申请在确保分布式锁正确性的前提下，每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，通过由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，从而支持在服务进程在故障切换(Failover)场景下服务替换进程零等待地、主动地快速地继承原分布式锁所有权，避免现有技术中存在的不可服务的时间窗口问题，Failover场景下新拉起的服务替换进程在重新争抢分布式锁时，服务端会对比分布式锁文件内记录的占有者的进程标识，以确认发起请求的服务替换进程的被替换服务进程是否原先占有过同一分布式锁，若是，则认为服务替换进程是原先占有该分布式锁，则通过删除分布式锁文件，确保能够主动、正确地释放分布式锁所有权，从而支持零等待地直接争抢分布式锁，显著提升Failover场景下业务服务的连续性。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出现有的客户端与服务端的生命期示意图；

图2示出现有的现有的占据分布式锁所有权的应用进程在发生Failover场景下继续服务的方案原理图；

图3示出现有的争抢分布式锁等待时间示意图；

图4示出本申请一实施例的服务进程标识的继承示意图；

图5示出本申请一实施例的服务进程标识示意图；

图6示出本申请一实施例的流程图；

图7示出本申请一实施例的条件更新方式原理图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请提供一种客户端的分布式锁的分配方法，该方法包括：

客户端为服务进程分配全局唯一的进程标识(Service Process Id，SPI)，客户端(client)的服务进程与服务端(server)建立连接后，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁(Lock)文件后，所述锁文件用于在其中写入所述进程标识，具体可以是由所述客户端向服务端发送在所述锁文件中写入所述进程标识的请求；在此，这里的进程标识可以为全局唯一的，进程标识可以是指同一个客户端里不同的正在运行的服务进程所具有的不同的编号，通过不同的编号，可以清楚地区分不同的服务进程；

在此，客户端(client)的服务进程与服务端(server)建立连接，所述连接可以是tcp(Transmission Control Protocol，传输控制协议)连接，并且此连接上创建Session，基于所述Session向服务端请求创建分布式锁的锁文件，该锁文件的生命周期与所述Session在服务端的生命周期一致，即当所述Session在服务端的生命周期结束，即需要遵循前述的“Quorum Server比Client后判定Session过期”这一原则，该Session对应的锁文件也会被删除，另外，SPI可以是分布式应用服务进程对应的全局唯一的服务进程标识，SPI可以维护在客户端上的守护进程(Daemon Process)里，在守护进程拉起服务进程时，会将分配的全局唯一的SPI作为启动参数传给服务进程，在此，因为Daemon守护进程管理客户端机器上各类服务的所有业务进程，因此，其有机会来为每个服务进程分配一个全局唯一的标识SPI(Service Process Id)，且作为启动参数传递给业务服务进程，通过在Daemon守护进程为每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，作为进程启动参数，每个业务服务进程在被守护进程拉起时，会获取到自身的进程标识，并在抢锁成功时写入分布式锁文件中；

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；在此，当服务进程发生故障切换(Failover)的时候，所述守护进程也会将记录的该服务进程的SPI值作为启动参数传给其新的继承的服务进程即所述服务替换进程，本实施例中，可基于Daemon守护进程管理全局唯一的服务进程标识作为启动参数来启动业务服务进程，并且在Failover场景下继续使用原服务进程标识，在业务服务进程异常退出时，Daemon守护进程会发现并重新拉起服务进程，如图4所展示的，Daemon服务进程管理着A、B两个业务服务进程。Daemon进程为之分别分配了全局唯一的服务进程标识SPI A、SPI B，并作为进程启动参数使得业务服务进程A、B知晓，当业务服务进程B异常退出时，Daemon守护进程会感知到，然后尝试重新拉起B的服务进程，不妨将新拉起的服务进程称为B’，作为继承者，B’服务进程的启动参数同样为原来的SPI B，根据该全局唯一的服务进程标识SPI，B’服务进程应该继承原B服务进程的所有权限，包括后者占有的分布式锁的所有权，另外，服务进程x与服务替换进程x’是相对的概念，服务替换进程x’用来表示一场景下原服务进程x的替换者，服务进程x是被替换者，在另一场景下，服务进程x可能就变成服务替换进程x’，相应的，服务替换进程x’可能就变成服务进程x；

由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。具体的，如图1所示，所述锁文件的生命周期结束是指Quorum Server端Session生命期周期结束，且Quorum Server端Session生命期至少为2倍Client端Session生命期，现有技术中在所述锁文件的生命周期结束后才释放所述分布式锁的所有权，而本实施例通过所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，由所述服务端提前释放所述分布式锁的所有权，实现所述服务替换进程不需要等待至少为2倍Client端Session生命期，即不需要等到所述锁文件的生命周期结束，就能快速继承所述分布式锁的所有权，快速恢复服务；

向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。对于上述所述服务替换进程的进程标识与所述锁文件中的当前进程标识不一致的情况，可以是如下的某一种场景：

例如，一类应用同时起了3个服务进程，肯定只有一个服务进程能够抢到分布式锁，另外两个服务进程看到的就是自身SPI与锁文件内容中的SPI不一致现象；

又如，针对新拉起服务进程这个场景，如果这个服务进程拉起的很慢，慢到后端锁文件已经被server主动释放了，别的服务进程抢锁成功了，锁文件内容中也写上别的服务进程的SPI值了，那么新拉起的服务进程就会抢锁失败。

上述实施例中，在确保分布式锁正确性的前提下，每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，通过由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，从而支持在服务进程在故障切换(Failover)场景下服务替换进程零等待地、主动地快速地继承原分布式锁所有权，避免现有技术中存在的不可服务的时间窗口问题，Failover场景下新拉起的服务替换进程在重新争抢分布式锁时，服务端会对比分布式锁文件内记录的占有者的进程标识，以确认发起请求的服务替换进程的被替换服务进程是否原先占有过同一分布式锁，若是，则认为服务替换进程是原先占有该分布式锁，则通过删除分布式锁文件，确保能够主动、正确地释放分布式锁所有权，从而支持零等待地直接争抢分布式锁，显著提升Failover场景下业务服务的连续性。

具体到业务服务进程全局唯一的SPI标识生成机制，如图5所示，SPI由两部分组成：一个是客户端主机名(Hostname)，为了区分不同机器上业务服务进程；另一个是服务进程在本机唯一的标志(ID)，可以是当前时间戳，或者是UUID数值等,该标志是为了确保业务服务进程标识在每个客户端内不重复，具体实现依赖实际业务场景下Daemon进程的管理机制。例如，主流的Docker容器技术中的容器ID就是一个合适的SPI值，可以唯一标识Docker容器内各服务进程。如上所述，进程SPI标识一旦在Daemon进程中被分配，必然对应一服务进程，即使当前服务进程挂掉，Daemon也会很快拉起新服务进程，并继承原SPI标识。

本申请的客户端的分布式锁的分配方法一实施例中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，包括：

由所述服务替换进程，向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端反馈尝试创建失败，

由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，但是这种概率很低，若所述服务端反馈尝试创建失败，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。

本申请的客户端的分布式锁的分配方法一实施例中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，包括：

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,所述删除请求包含所述服务替换进程的进程标识；

由所述服务替换进程向所述服务端发送同一分布式锁的新的锁文件的创建请求。具体的，本实施中，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求若不一致，则不同意删除所述服务进程所创建的锁文件。

本申请的客户端的分布式锁的分配方法一实施例中，由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,向所述服务端发送同一分布式锁的新的锁文件的创建请求，其中，所述删除请求包含所述服务替换进程的进程标识，包括：

向服务端发送事务序号获取请求，以从服务端的锁文件中获取锁文件在创建时的事务序号；在此，服务端每次创建锁文件时，都会在锁文件中记录其创建时的事务序号；

由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求，所述删除请求中还包含所述锁文件在创建时的事务序号(Transaction Id)；具体的，分布式一致性系统中对应每条数据更新请求均分配一全局唯一事务序号(Transaction Id)，且该事务序号有顺序性，数值越大，事务请求发生时间越在后；

从服务端接收所述锁文件是否删除成功的反馈，其中，所述服务端基于删除请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致反馈所述锁文件是否删除成功，

若删除成功，则基于从服务端接收的删除成功的反馈，向所述服务端发送同一分布式锁的新的锁文件的创建请求。在此，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，且所述服务端判断请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致，若都一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求向所述服务端发送同一分布式锁的新的锁文件的创建请求；若有其中一个条件不一致，则不同意删除所述服务进程所创建的锁文件。

本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。例如，一服务进程8原先占有分布式锁文件A的所有权，该所有权并非只有等待进程8主动释放，即由服务进程8删除所述分布式锁文件A，只要等到server端判断分布式锁文件A过期，那么分布式锁文件A也是被会server端自动删除的，这样进程9就有机会获取锁所有权。比如说，新拉起的服务进程8创建锁文件A时的事务序号为1000，删除请求带事务序号为1000，但当删除请求到过Server的时候，新拉起的进程8又故障了，锁文件A已经由新拉起的服务进程9重新创建此时事务序号为2000，由于删除请求带的事务1000号与当前锁文件的最新的创建的事务序号2000不一致，所以服务进程8不是目前锁文件A的所有权拥有者，其没有删除锁文件A权利，所以要把这个服务进程8删除请求忽略掉。这里的一个概念就是，分布式锁文件A虽然可以被server端自动删除，但需要耗时等待，在所述生命周期结束前，才引入了本申请的机制，可以让服务进程8安全、及时主动删除锁文件，如果根据事务序号判断服务进程8已经对分布式锁文件A没有所有权了，其的删除请求就不会被服务端接受。

本申请的客户端的分布式锁的分配方法一实施例中，从服务端接收所述锁文件是否删除成功的反馈之后，还包括：

若删除不成功，则从所述服务接收所述服务替换进程抢占的所述锁文件失败的反馈。在此，若所述服务端将删除请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号进行比较，比较结果为不一致，则服务端所述服务替换进程不是原来的服务进程的继承者，则向所述客户端所述服务替换进程抢占的所述锁文件失败。本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。

本申请的客户端的分布式锁的分配方法一实施例中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送尝试重新创建同一布式锁的新的具有生命周期的锁文件的请求之后，还包括：

若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

本申请还提供一种服务端的分布式锁的分配方法，该方法包括：

根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；在此，客户端(client)的服务进程与服务端(server)建立连接，并且此连接上创建Session，基于所述Session向服务端请求创建分布式锁的锁文件，该锁文件的生命周期与所述Session在服务端的生命周期一致，即当所述Session在服务端的生命周期结束，该Session对应的锁文件也会被删除，另外，SPI可以是分布式应用服务进程对应的全局唯一的服务进程标识，SPI可以维护在客户端上的守护进程里，在守护进程拉起服务进程时，会将分配的全局唯一的SPI作为启动参数传给服务进程，在此，因为Daemon守护进程管理客户端机器上各类服务的所有业务进程，因此，其有机会来为每个服务进程分配一个全局唯一的标识SPI(Service Process Id)，且作为启动参数传递给业务服务进程，通过在Daemon守护进程为每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，作为进程启动参数，每个业务服务进程在被守护进程拉起时，会获取到自身的进程标识，并在抢锁成功时写入分布式锁文件中；当服务进程发生故障切换(Failover)的时候，所述守护进程也会将记录的该服务进程的SPI值作为启动参数传给其新的继承的服务进程即所述服务替换进程，本实施例中，可基于Daemon守护进程管理全局唯一的服务进程标识作为启动参数来启动业务服务进程，并且在Failover场景下继续使用原服务进程标识，在业务服务进程异常退出时，Daemon守护进程会发现并重新拉起服务进程，如图4所展示的，Daemon服务进程管理着A、B两个业务服务进程。Daemon进程为之分别分配了全局唯一的服务进程标识SPI A、SPI B，并作为进程启动参数使得业务服务进程A、B知晓，当业务服务进程B异常退出时，Daemon守护进程会感知到，然后尝试重新拉起B的服务进程，不妨将新拉起的服务进程称为B’，作为继承者，B’服务进程的启动参数同样为原来的SPI B，根据该全局唯一的服务进程标识SPI，B’服务进程应该继承原B服务进程的所有权限，包括后者占有的分布式锁的所有权；

获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。具体的，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(ConditionalUpdate)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。对于上述所述服务替换进程的进程标识与所述锁文件中的当前进程标识不一致的情况，可以是如下的某一种场景：

例如，一类应用同时起了3个服务进程，肯定只有一个服务进程能够抢到分布式锁，另外两个服务进程看到的就是自身SPI与锁文件内容中的SPI不一致现象；

又如，针对新拉起服务进程这个场景，如果这个服务进程拉起的很慢，慢到后端锁文件已经被server主动释放了，别的服务进程抢锁成功了，锁文件内容中也写上别的服务进程的SPI值了，那么新拉起的服务进程就会抢锁失败。

上述实施例中，在确保分布式锁正确性的前提下，每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，通过由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，从而支持在服务进程在故障切换(Failover)场景下服务替换进程零等待地、主动地快速地继承原分布式锁所有权，避免现有技术中存在的不可服务的时间窗口问题，Failover场景下新拉起的服务替换进程在重新争抢分布式锁时，服务端会对比分布式锁文件内记录的占有者的进程标识，以确认发起请求的服务替换进程的被替换服务进程是否原先占有过同一分布式锁，若是，则认为服务替换进程是原先占有该分布式锁，则通过删除分布式锁文件，确保能够主动、正确地释放分布式锁所有权，从而支持零等待地直接争抢分布式锁，显著提升Failover场景下业务服务的连续性。

具体到业务服务进程全局唯一的SPI标识生成机制，如图5所示，SPI由两部分组成：一个是客户端主机名(Hostname)，为了区分不同机器上业务服务进程；另一个是服务进程在本机唯一的标志(ID)，可以是当前时间戳，或者是UUID数值等,该标志是为了确保业务服务进程标识在每个客户端内不重复，具体实现依赖实际业务场景下Daemon进程的管理机制。例如，主流的Docker容器技术中的容器ID就是一个合适的SPI值，可以唯一标识Docker容器内各服务进程。如上所述，进程SPI标识一旦在Daemon进程中被分配，对应一服务进程，即使当前服务进程挂掉，Daemon也会很快拉起新服务进程，并继承原SPI标识。

本申请的服务端的分布式锁的分配方法一实施例中，获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件，包括：

根据从所述服务替换进程接收的尝试重新创建请求，尝试创建所述服务替换进程的同一分布式锁的新的锁文件，若尝试失败，向所述服务替换进程反馈尝试创建失败；

获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，但是这种概率很低，若所述服务端反馈尝试创建失败，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。

本申请的服务端的分布式锁的分配方法一实施例中，获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件，包括：

从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，根据所述删除锁文件的请求判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，删除所述服务进程所创建的锁文件；

根据从服务替换进程接收的创建请求，为所述替换进程创建同一分布式锁的新的锁文件。在此，本实施中，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求若不一致，则不同意删除所述服务进程所创建的锁文件。

本申请的服务端的分布式锁的分配方法一实施例中，

创建对应的分布式锁的具有生命周期的锁文件的之后，还包括：

在所述锁文件中写入其创建时的事务序号；

从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，包括：

根据从客户端接收的事务序号获取请求，向所述客户端发送锁文件在创建时的事务序号；

从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识和所述锁文件在创建时的事务序号(Transaction Id)；

删除所述服务进程所创建的锁文件，包括：

判断所述删除锁文件请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致，在此，当前锁文件创建时的事务序号可以写在服务端的对应的当前锁文件中；

若一致，删除所述服务进程所创建的锁文件，向所述服务替换进程反馈删除成功，获取所述服务替换进程发送的创建同一分布式锁的新的锁文件的请求。具体的，分布式一致性系统中对应每条数据更新请求均分配一全局唯一事务序号(Transaction Id)，且该事务序号有顺序性，数值越大，事务请求发生时间越在后；在此，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，且所述服务端判断请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致，若都一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求向所述服务端发送同一分布式锁的新的锁文件的创建请求；若有其中一个条件不一致，则不同意删除所述服务进程所创建的锁文件。本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。

例如，一服务进程8原先占有分布式锁文件A的所有权，该所有权并非只有等待进程8主动释放，即由服务进程8删除所述分布式锁文件A，只要等到server端判断分布式锁文件A过期，那么分布式锁文件A也是被会server端自动删除的，这样进程9就有机会获取锁所有权。比如说，新拉起的服务进程8创建锁文件A时的事务序号为1000，删除请求带事务序号为1000，但当删除请求到过Server的时候，新拉起的进程8又故障了，锁文件A已经由新拉起的服务进程9重新创建此时事务序号为2000，由于删除请求带的事务1000号与当前锁文件的最新的创建的事务序号2000不一致，所以服务进程8不是目前锁文件A的所有权拥有者，其没有删除锁文件A权利，所以要把这个服务进程8删除请求忽略掉。这里的一个概念就是，分布式锁文件A虽然可以被server端自动删除，但需要耗费等待时间，在所述生命周期结束前，才引入了本申请的机制，可以让服务进程8安全，及时主动删除锁文件，如果根据事务序号判断服务进程8已经对分布式锁文件A没有所有权了，其的删除请求就不会被服务端接受。

本申请的服务端的分布式锁的分配方法一实施例中，向所述服务替换进程反馈所述锁文件是否删除成功之后，还包括：

若删除不成功，则向服务替换进程反馈抢占所述锁文件失败。在此，若所述服务端将删除请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号进行比较，比较结果为不一致，则服务端所述服务替换进程不是原来的服务进程的继承者，则向所述客户端所述服务替换进程抢占的所述锁文件失败。本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。

本申请的服务端的分布式锁的分配方法一实施例中，尝试创建所述服务替换进程的同一分布式锁的新的锁文件之后，还包括：

若尝试创建成功，则向所述服务替换进程反馈抢占所述分布式锁成功。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

本申请还提供一种客户端，该客户端包括：

创建请求装置，用于为服务进程分配唯一的进程标识(Service Process Id，SPI)，供所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

在此，这里的全局唯一的进程标识可以是指客户端里不同的正在运行的服务进程所具有的不同的编号，通过不同的编号，可以清楚地区分不同的服务进程；

客户端(client)的服务进程与服务端(server)建立连接，所述连接可以是tcp连接，并且此连接上创建Session，基于所述Session向服务端请求创建分布式锁的锁文件，该锁文件的生命周期与所述Session在服务端的生命周期一致，即当所述Session在服务端的生命周期结束，即需要遵循前述的“Quorum Server比Client后判定Session过期”这一原则，该Session对应的锁文件也会被删除，另外，SPI可以是分布式应用服务进程对应的全局唯一的服务进程标识，SPI可以维护在客户端上的守护进程(Daemon Process)里，在守护进程拉起服务进程时，会将分配的全局唯一的SPI作为启动参数传给服务进程，在此，因为Daemon守护进程管理客户端机器上各类服务的所有业务进程，因此，其有机会来为每个服务进程分配一个全局唯一的标识SPI(Service Process Id)，且作为启动参数传递给业务服务进程，通过在Daemon守护进程为每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，作为进程启动参数，每个业务服务进程在被守护进程拉起时，会获取到自身的进程标识，并在抢锁成功时写入分布式锁文件中；

故障切换装置，用于当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；在此，当服务进程发生故障切换(Failover)的时候，所述守护进程也会将记录的该服务进程的SPI值作为启动参数传给其新的继承的服务进程即所述服务替换进程，本实施例中，可基于Daemon守护进程管理全局唯一的服务进程标识作为启动参数来启动业务服务进程，并且在Failover场景下继续使用原服务进程标识，在业务服务进程异常退出时，Daemon守护进程会发现并重新拉起服务进程，如图4所展示的，Daemon服务进程管理着A、B两个业务服务进程。Daemon进程为之分别分配了全局唯一的服务进程标识SPI A、SPI B，并作为进程启动参数使得业务服务进程A、B知晓，当业务服务进程B异常退出时，Daemon守护进程会感知到，然后尝试重新拉起B的服务进程，不妨将新拉起的服务进程称为B’，作为继承者，B’服务进程的启动参数同样为原来的SPI B，根据该全局唯一的服务进程标识SPI，B’服务进程应该继承原B服务进程的所有权限，包括后者占有的分布式锁的所有权；

继承请求装置，用于供所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。具体的，如图1所示，所述锁文件的生命周期结束是指Quorum Server端Session生命期周期结束，且Quorum Server端Session生命期至少为2倍Client端Session生命期，现有技术中在所述锁文件的生命周期结束后才释放所述分布式锁的所有权，而本实施例通过所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，由所述服务端提前释放所述分布式锁的所有权，实现所述服务替换进程不需要等待至少为2倍Client端Session生命期，即不需要等到所述锁文件的生命周期结束，就能快速继承所述分布式锁的所有权，快速恢复服务；

向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。对于上述所述服务替换进程的进程标识与所述锁文件中的当前进程标识不一致的情况，可以是如下的某一种场景：

例如，一类应用同时起了3个服务进程，肯定只有一个服务进程能够抢到分布式锁，另外两个服务进程看到的就是自身SPI与锁文件内容中的SPI不一致现象；

又如，针对新拉起服务进程这个场景，如果这个服务进程拉起的很慢，慢到后端锁文件已经被server主动释放了，别的服务进程抢锁成功了，锁文件内容中也写上别的服务进程的SPI值了，那么新拉起的服务进程就会抢锁失败。

上述实施例中，在确保分布式锁正确性的前提下，每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，通过由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，从而支持在服务进程在故障切换(Failover)场景下服务替换进程零等待地、主动地快速地继承原分布式锁所有权，避免现有技术中存在的不可服务的时间窗口问题，Failover场景下新拉起的服务替换进程在重新争抢分布式锁时，服务端会对比分布式锁文件内记录的占有者的进程标识，以确认发起请求的服务替换进程的被替换服务进程是否原先占有过同一分布式锁，若是，则认为服务替换进程是原先占有该分布式锁，则通过删除分布式锁文件，确保能够主动、正确地释放分布式锁所有权，从而支持零等待地直接争抢分布式锁，显著提升Failover场景下业务服务的连续性。

具体到业务服务进程全局唯一的SPI标识生成机制，如图5所示，SPI由两部分组成：一个是客户端主机名(Hostname)，为了区分不同机器上业务服务进程；另一个是服务进程在本机唯一的标志(ID)，可以是当前时间戳，或者是UUID数值等,该标志是为了确保业务服务进程标识在每个客户端内不重复，具体实现依赖实际业务场景下Daemon进程的管理机制。例如，主流的Docker容器技术中的容器ID就是一个合适的SPI值，可以唯一标识Docker容器内各服务进程。如上所述，进程SPI标识一旦在Daemon进程中被分配，必然对应一服务进程，即使当前服务进程挂掉，Daemon也会很快拉起新服务进程，并继承原SPI标识。

本申请客户端的一实施例中，所述继承请求装置，用于供所述服务替换进程，向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端反馈尝试创建失败，

由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，但是这种概率很低，若所述服务端反馈尝试创建失败，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。

本申请的客户端的一实施例中，所述继承请求装置，用于供所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,所述删除请求包含所述服务替换进程的进程标识；

由所述服务替换进程向所述服务端发送同一分布式锁的新的锁文件的创建请求。具体的，本实施中，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求若不一致，则不同意删除所述服务进程所创建的锁文件。

本申请的客户端的一实施例中，所述继承请求装置，用于向服务端发送事务序号获取请求，以从服务端的锁文件中获取锁文件在创建时的事务序号；供所述服务替换进程在所述生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求，所述删除请求中还包含所述锁文件在创建时的事务序号(Transaction Id)；具体的，分布式一致性系统中对应每条数据更新请求均分配一全局唯一事务序号(Transaction Id)，且该事务序号有顺序性，数值越大，事务请求发生时间越在后；

从服务端接收所述锁文件是否删除成功的反馈，其中，所述服务端基于删除请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致反馈所述锁文件是否删除成功，

若删除成功，则基于从服务端接收的删除成功的反馈，向所述服务端发送同一分布式锁的新的锁文件的创建请求。在此，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，且所述服务端判断请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致，若都一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求向所述服务端发送同一分布式锁的新的锁文件的创建请求；若有其中一个条件不一致，则不同意删除所述服务进程所创建的锁文件。本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。例如，一服务进程8原先占有分布式锁文件A的所有权，该所有权并非只有等待进程8主动释放，即由服务进程8删除所述分布式锁文件A，只要等到server端判断分布式锁文件A过期，那么分布式锁文件A也是被会server端自动删除的，这样进程9就有机会获取锁所有权。比如说，新拉起的服务进程8创建锁文件A时的事务序号为1000，删除请求带事务序号为1000，但当删除请求到过Server的时候，新拉起的进程8又故障了，锁文件A已经由新拉起的服务进程9重新创建此时事务序号为2000，由于删除请求带的事务1000号与当前锁文件的最新的创建的事务序号2000不一致，所以服务进程8不是目前锁文件A的所有权拥有者，其没有删除锁文件A权利，所以要把这个服务进程8删除请求忽略掉。这里的一个概念就是，分布式锁文件A虽然可以被server端自动删除，但需要耗费等待时间，在所述生命周期结束前，才引入了本申请的机制，可以让服务进程8安全，及时主动删除锁文件，如果根据事务序号判断服务进程8已经对分布式锁文件A没有所有权了，其的删除请求就不会被服务端接受。

本申请的客户端的一实施例中，所述继承请求装置，还用于从服务端接收所述锁文件是否删除成功的反馈之后，

若删除不成功，则从所述服务接收所述服务替换进程抢占的所述锁文件失败的反馈。在此，若所述服务端将删除请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号进行比较，比较结果为不一致，则服务端所述服务替换进程不是原来的服务进程的继承者，则向所述客户端所述服务替换进程抢占的所述锁文件失败。本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。

本申请的客户端的一实施例中，所述继承请求装置，用于供所述服务替换进程在所述生命周期结束前，向所述服务端发送尝试重新创建同一布式锁的新的具有生命周期的锁文件的请求之后，

若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

本申请还提供一种服务端，该服务端包括：

创建装置，用于根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；在此，客户端(client)的服务进程与服务端(server)建立连接，并且此连接上创建Session，基于所述Session向服务端请求创建分布式锁的锁文件，该锁文件的生命周期与所述Session在服务端的生命周期一致，即当所述Session在服务端的生命周期结束，该Session对应的锁文件也会被删除，另外，SPI可以是分布式应用服务进程对应的全局唯一的服务进程标识，SPI可以维护在客户端上的守护进程里，在守护进程拉起服务进程时，会将分配的全局唯一的SPI作为启动参数传给服务进程，在此，因为Daemon守护进程管理客户端机器上各类服务的所有业务进程，因此，其有机会来为每个服务进程分配一个全局唯一的标识SPI(Service Process Id)，且作为启动参数传递给业务服务进程，通过在Daemon守护进程为每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，作为进程启动参数，每个业务服务进程在被守护进程拉起时，会获取到自身的进程标识，并在抢锁成功时写入分布式锁文件中；当服务进程发生故障切换(Failover)的时候，所述守护进程也会将记录的该服务进程的SPI值作为启动参数传给其新的继承的服务进程即所述服务替换进程，本实施例中，可基于Daemon守护进程管理全局唯一的服务进程标识作为启动参数来启动业务服务进程，并且在Failover场景下继续使用原服务进程标识，在业务服务进程异常退出时，Daemon守护进程会发现并重新拉起服务进程，如图4所展示的，Daemon服务进程管理着A、B两个业务服务进程。Daemon进程为之分别分配了全局唯一的服务进程标识SPI A、SPI B，并作为进程启动参数使得业务服务进程A、B知晓，当业务服务进程B异常退出时，Daemon守护进程会感知到，然后尝试重新拉起B的服务进程，不妨将新拉起的服务进程称为B’，作为继承者，B’服务进程的启动参数同样为原来的SPI B，根据该全局唯一的服务进程标识SPI，B’服务进程应该继承原B服务进程的所有权限，包括后者占有的分布式锁的所有权；

写入装置，用于根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

分配装置，用于获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。具体的，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。对于上述所述服务替换进程的进程标识与所述锁文件中的当前进程标识不一致的情况，可以是如下的某一种场景：

例如，一类应用同时起了3个服务进程，肯定只有一个服务进程能够抢到分布式锁，另外两个服务进程看到的就是自身SPI与锁文件内容中的SPI不一致现象；

又如，针对新拉起服务进程这个场景，如果这个服务进程拉起的很慢，慢到后端锁文件已经被server主动释放了，别的服务进程抢锁成功了，锁文件内容中也写上别的服务进程的SPI值了，那么新拉起的服务进程就会抢锁失败。

上述实施例中，在确保分布式锁正确性的前提下，每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，通过由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，从而支持在服务进程在故障切换(Failover)场景下服务替换进程零等待地、主动地快速地继承原分布式锁所有权，避免现有技术中存在的不可服务的时间窗口问题，Failover场景下新拉起的服务替换进程在重新争抢分布式锁时，服务端会对比分布式锁文件内记录的占有者的进程标识，以确认发起请求的服务替换进程的被替换服务进程是否原先占有过同一分布式锁，若是，则认为服务替换进程是原先占有该分布式锁，则通过删除分布式锁文件，确保能够主动、正确地释放分布式锁所有权，从而支持零等待地直接争抢分布式锁，显著提升Failover场景下业务服务的连续性。

具体到业务服务进程全局唯一的SPI标识生成机制，如图5所示，SPI由两部分组成：一个是客户端主机名(Hostname)，为了区分不同机器上业务服务进程；另一个是服务进程在本机唯一的标志(ID)，可以是当前时间戳，或者是UUID数值等,该标志是为了确保业务服务进程标识在每个客户端内不重复，具体实现依赖实际业务场景下Daemon进程的管理机制。例如，主流的Docker容器技术中的容器ID就是一个合适的SPI值，可以唯一标识Docker容器内各服务进程。如上所述，进程SPI标识一旦在Daemon进程中被分配，必然对应一服务进程，即使当前服务进程挂掉，Daemon也会很快拉起新服务进程，并继承原SPI标识。

本申请的服务端的一实施例中，所述分配装置，用于根据从所述服务替换进程接收的尝试重新创建请求，尝试创建所述服务替换进程的同一分布式锁的新的锁文件，若尝试失败，向所述服务替换进程反馈尝试创建失败；

获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，但是这种概率很低，若所述服务端反馈尝试创建失败，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送分布式锁的所有权的继承请求时，可以带上判断条件；Server端收到分布式锁的所有权的继承请求时，会逐个判断条件是否满足：满足则更新数据即同意所述服务替换进程继承所述分布式锁的所有权；否则拒绝更新即不同意所述服务替换进程继承所述分布式锁的所有权，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意所述服务替换进程继承所述分布式锁的所有权，若不一致，则不同意所述服务替换进程继承所述分布式锁的所有权。

本申请的服务端的一实施例中，所述分配装置，用于从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，根据所述删除锁文件的请求判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，删除所述服务进程所创建的锁文件；

根据从服务替换进程接收的创建请求，为所述替换进程创建同一分布式锁的新的锁文件。在此，本实施中，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求若不一致，则不同意删除所述服务进程所创建的锁文件。

本申请的服务端的一实施例中，所述写入装置，还用于在创建对应的分布式锁的具有生命周期的锁文件的之后，在所述锁文件中写入其创建时的事务序号；

所述分配装置，用于根据从客户端接收的事务序号获取请求，向所述客户端发送锁文件在创建时的事务序号；从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识和所述锁文件在创建时的事务序号，判断所述删除锁文件请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致，

若一致，删除所述服务进程所创建的锁文件，向所述服务替换进程反馈删除成功，获取所述服务替换进程发送的创建同一分布式锁的新的锁文件的请求。具体的，分布式一致性系统中对应每条数据更新请求均分配一全局唯一事务序号(Transaction Id)，且该事务序号有顺序性，数值越大，事务请求发生时间越在后；在此，所述继承请求可以包括删除请求和之后的创建请求，可以在所述删除请求中包含所述服务替换进程的进程标识，所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求可以是一条件更新请求(Conditional Update)，以解决数据并发操作引发的一致性问题，Client端发送所述服务进程所创建的锁文件的删除请求时，可以带上判断条件；Server端收到所述服务进程所创建的锁文件的删除请求时，会逐个判断条件是否满足：满足则更新数据即同意删除所述服务进程所创建的锁文件；否则拒绝更新即不同意删除所述服务进程所创建的锁文件，可以向客户端返回错误，本实施例中，判断条件可以是由服务端判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，且所述服务端判断请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致，若都一致，则同意删除所述服务进程所创建的锁文件，随后，客户端可以基于从服务端接收的删除成功的反馈，继续发送同一分布式锁的创建请求向所述服务端发送同一分布式锁的新的锁文件的创建请求；若有其中一个条件不一致，则不同意删除所述服务进程所创建的锁文件。本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。例如，一服务进程8原先占有分布式锁文件A的所有权，该所有权并非只有等待进程8主动释放，即由服务进程8删除所述分布式锁文件A，只要等到server端判断分布式锁文件A过期，那么分布式锁文件A也是被会server端自动删除的，这样进程9就有机会获取锁所有权。比如说，新拉起的服务进程8创建锁文件A时的事务序号为1000，删除请求带事务序号为1000，但当删除请求到过Server的时候，新拉起的进程8又故障了，锁文件A已经由新拉起的服务进程9重新创建此时事务序号为2000，由于删除请求带的事务1000号与当前锁文件的最新的创建的事务序号2000不一致，所以服务进程8不是目前锁文件A的所有权拥有者，其没有删除锁文件A权利，所以要把这个服务进程8删除请求忽略掉。这里的一个概念就是，分布式锁文件A虽然可以被server端自动删除，但需要耗费等待时间，在所述生命周期结束前，才引入了本申请的机制，可以让服务进程8安全，及时主动删除锁文件，如果根据事务序号判断服务进程8已经对分布式锁文件A没有所有权了，其的删除请求就不会被服务端接受。

本申请的服务端的一实施例中，所述分配装置，用于向所述服务替换进程反馈所述锁文件是否删除成功之后，若删除不成功，则向服务替换进程反馈抢占所述锁文件失败。在此，若所述服务端将删除请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号进行比较，比较结果为不一致，则服务端所述服务替换进程不是原来的服务进程的继承者，则向所述客户端所述服务替换进程抢占的所述锁文件失败。本实施例基于事务序号的比较删除分布式锁文件，主动、正确地地释放分布式锁所有权，避免出现删除锁文件的请求包在网络上飘动，最后误删非自身占有的有效分布式锁。

本申请的服务端的一实施例中，所述分配装置，用于尝试创建所述服务替换进程的同一分布式锁的新的锁文件之后，若尝试创建成功，则向所述服务替换进程反馈抢占所述分布式锁成功。在此，为了确保分布式锁的正确性，client/server对同一分布式锁过期时间理解是不一致的，如前面背景介绍，server端认为的锁过期时间必须至少是client端认为的2倍以上，这个就意味着，client进程忽然故障(crash)时，server端还没有认为分布式锁过期，立即重启的client进程最长需要等待完整server端过期时间后，才能抢锁成功，当然，如果client进程挂了之后，花了很久才被守护进程重新拉起，在这个很久的时间里面，server端早就认为分布式锁过期了，删除了这个锁文件，即释放了分布式锁，那么新起的client进程可以立即抢锁成功，所以本实施例中，可以先由客户端向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

根据本申请的另一面，还提供一种基于计算的设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

根据本申请的另一面，还提供一种基于计算的设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

根据本申请的另一面，还提供一种存储可执行指令的非暂态计算机可读存储介质，在所述可执行指令由电子设备执行时，使得所述电子设备：

为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

根据本申请的另一面，还提供一种存储可执行指令的非暂态计算机可读存储介质，在所述可执行指令由电子设备执行时，使得所述电子设备：

根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

根据本申请的另一面，还提供一种锁文件的获取方法，包括：

第一服务进程被创建，其中，所述第一服务进程的进程标识与发生故障的第二服务进程的进程标识相同，所述第二服务进程对应于锁文件；

所述第一服务进程发送所述锁文件的继承请求，其中，所述继承请求包括所述第一服务进程的进程标识。

上述方法中，所述第一服务进程发送所述锁文件的继承请求，包括：

由所述第一服务进程发送尝试重新创建所述锁文件的请求，若尝试重新创建失败，

由所述第一服务进程发送所述分布式锁的所有权的继承请求。

根据本申请的另一面，还提供一种锁文件的获取方法，包括：

服务进程被创建，其中，所述服务进程包括进程标识；

所述服务进程发送锁文件的创建请求，其中，所述创建请求包括所述服务进程的进程标识。

上述方法中，所述服务进程发送锁文件的创建请求之后，还包括：

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程。

本申请一具体的应用实施例中，如图6所示，给出了基于全局唯一的服务进程SPI标识，业务服务进程如何在Failover场景下零等待或较少等待地争抢分布式锁流程，从而确保业务服务的连续性：

机器上Daemon守护进程在新拉起业务服务进程时，服务进程会获取分配的SPI标识，然后尝试争抢分布式锁，即创建对应的分布式锁文件，分布式锁文件的内容即为自身的SPI标识，

如果分布式锁对应的锁文件已经不存在，则会创建成功，那么直接抢锁成功，业务服务可以继续提供；

如果抢锁失败，那么分布式锁对应的锁文件存在，新起业务服务进程会读取当前分布式锁文件的内容，即该分布式锁占有者服务进程的SPI，然后比对新起服务进程SPI标识与当前分布式锁文件中SPI标识是否相等，

如果新起服务进程SPI标识与当前分布式锁文件中SPI标识相等，那么，即可确认该分布式锁占有者是Failover前原服务进程，因此新起服务进程可继承该分布式锁所有权，因此其可以基于Conditional Update方式删除当前分布式锁文件，主动释放分布式锁所有权后，重新创建所述分布式锁的锁文件；

如果新起服务进程SPI标识与当前分布式锁文件中SPI标识不相等，则抢锁失败。

图7给出了基于条件更新(Conditional Update)方式，主动、正确地删除分布式锁文件。Client进程在访问后端Quorum Server中锁文件时候，获取以下两个信息：1)当前分布式锁文件内容，即分布式锁实际占有者的服务进程SPI；2)当前分布式锁文件创建时对应的全局唯一事务序号。在判断Client进程SPI与分布式锁占有者的SPI数值一致，亦即自身是继承了该分布式锁所有权时，客户端进程即基于Conditional Update方式向服务端发送删除分布式锁文件请求。具体的Quorum Server端判断的两个条件为：1)Client端请求带的SPI值为当前分布式锁文件内容；2)Client端请求带的事务序号，即为当前分布式锁文件创建时候对应的Transaction Id。以上条件均满足，Quorum Server删除分布式锁文件，释放分布式锁所有权。

综上所述，在确保分布式锁正确性的前提下，每个分布式应用服务进程引入一个全局唯一的服务进程标识，并利用该进程标识直接管理分布式锁所有权，通过由所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识，从而支持在服务进程在故障切换(Failover)场景下服务替换进程零等待地、主动地快速地继承原分布式锁所有权，避免现有技术中存在的不可服务的时间窗口问题，Failover场景下新拉起的服务替换进程在重新争抢分布式锁时，服务端会对比分布式锁文件内记录的占有者的进程标识，以确认发起请求的服务替换进程的被替换服务进程是否原先占有过同一分布式锁，若是，则认为服务替换进程是原先占有该分布式锁，则通过删除分布式锁文件，确保能够主动、正确地释放分布式锁所有权，从而支持零等待地直接争抢分布式锁，显著提升Failover场景下业务服务的连续性。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (32)

1.一种客户端的分布式锁的分配方法，其中，该方法包括：

为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

2.根据权利要求1所述的方法，其中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，包括：

由所述服务替换进程，向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端反馈尝试创建失败，

由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

3.根据权利要求1或2所述的方法，其中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，包括：

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,所述删除请求包含所述服务替换进程的进程标识；

由所述服务替换进程向所述服务端发送同一分布式锁的新的锁文件的创建请求。

4.根据权利要求3所述的方法，其中，由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,向所述服务端发送同一分布式锁的新的锁文件的创建请求，包括：

向服务端发送事务序号获取请求，以从服务端的锁文件中获取锁文件在创建时的事务序号；

由所述服务替换进程在所述生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求，所述删除请求中还包含所述锁文件在创建时的事务序号；

从服务端接收所述锁文件是否删除成功的反馈，其中，所述服务端基于删除请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致反馈所述锁文件是否删除成功，

若删除成功，则基于从服务端接收的删除成功的反馈，向所述服务端发送同一分布式锁的新的锁文件的创建请求。

5.根据权利要求4所述的方法，其中，从服务端接收所述锁文件是否删除成功的反馈之后，还包括：

若删除不成功，则从所述服务接收所述服务替换进程抢占的所述锁文件失败的反馈。

6.根据权利要求2所述的方法，其中，由所述服务替换进程在所述生命周期结束前，向所述服务端发送尝试重新创建同一布式锁的新的具有生命周期的锁文件的请求之后，还包括：

若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

7.一种服务端的分布式锁的分配方法，其中，该方法包括：

根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

8.根据权利要求7所述的方法，其中，获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件，包括：

根据从所述服务替换进程接收的尝试重新创建请求，尝试创建所述服务替换进程的同一分布式锁的新的锁文件，若尝试失败，向所述服务替换进程反馈尝试创建失败；

获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件。

9.根据权利要求7或8所述的方法，其中，获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件，包括：

从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，根据所述删除锁文件的请求判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，删除所述服务进程所创建的锁文件；

根据从服务替换进程接收的创建请求，为所述替换进程创建同一分布式锁的新的锁文件。

10.根据权利要求9所述的方法，其中，创建对应的分布式锁的具有生命周期的锁文件的之后，还包括：

在所述锁文件中写入其创建时的事务序号；

从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，包括：

根据从客户端接收的事务序号获取请求，向所述客户端发送锁文件在创建时的事务序号；

从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识和所述锁文件在创建时的事务序号；

删除所述服务进程所创建的锁文件，包括：

判断所述删除锁文件请求中的事务序号与服务端的所述分布式锁的当前锁文件中的创建时的事务序号是否一致，

若一致，删除所述服务进程所创建的锁文件，向所述服务替换进程反馈删除成功，获取所述服务替换进程发送的创建同一分布式锁的新的锁文件的请求。

11.根据权利要求10所述的方法，其中，向所述服务替换进程反馈所述锁文件是否删除成功之后，还包括：

若删除不成功，则向服务替换进程反馈抢占所述锁文件失败。

12.根据权利要求8所述的方法，其中，尝试创建所述服务替换进程的同一分布式锁的新的锁文件之后，还包括：

若尝试创建成功，则向所述服务替换进程反馈抢占所述分布式锁成功。

13.一种客户端，其中，该客户端包括：

创建请求装置，用于为服务进程分配唯一的进程标识，供所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

故障切换装置，用于当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

继承请求装置，用于供所述服务替换进程，在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

14.根据权利要求13所述的客户端，其中，所述继承请求装置，用于供所述服务替换进程，向所述服务端发送尝试重新创建同一布式锁的新的锁文件的请求，若所述服务端反馈尝试创建失败，

供所述服务替换进程在所述生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

15.根据权利要求13或14所述的客户端，其中，所述继承请求装置，用于供所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求,所述删除请求包含所述服务替换进程的进程标识；供所述服务替换进程向所述服务端发送同一分布式锁的新的锁文件的创建请求。

16.根据权利要求15所述的客户端，其中，所述继承请求装置，用于向服务端发送事务序号获取请求，以从服务端的锁文件中获取锁文件在创建时的事务序号；供所述服务替换进程在所述生命周期结束前，向所述服务端发送所述服务进程所创建的锁文件的删除请求，所述删除请求中还包含所述锁文件在创建时的事务序号；从服务端接收所述锁文件是否删除成功的反馈，其中，所述服务端基于删除请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致反馈所述锁文件是否删除成功，

若删除成功，则基于从服务端接收的删除成功的反馈，向所述服务端发送同一分布式锁的新的锁文件的创建请求。

17.根据权利要求16所述的客户端，其中，所述继承请求装置，还用于从服务端接收所述锁文件是否删除成功的反馈之后，

若删除不成功，则从所述服务接收所述服务替换进程抢占的所述锁文件失败的反馈。

18.根据权利要求14所述的客户端，其中，所述继承请求装置，用于供所述服务替换进程在所述生命周期结束前，向所述服务端发送尝试重新创建同一布式锁的新的具有生命周期的锁文件的请求之后，

若所述服务端尝试创建成功，则从所述服务端获取所述服务替换进程抢占所述分布式锁成功的反馈。

19.一种服务端，其中，该服务端包括：

创建装置，用于根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

写入装置，用于根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

分配装置，用于获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

20.根据权利要求19所述的服务端，其中，所述分配装置，用于根据从所述服务替换进程接收的尝试重新创建请求，尝试创建所述服务替换进程的同一分布式锁的新的锁文件，若尝试失败，向所述服务替换进程反馈尝试创建失败；

获取所述服务替换进程在所述锁文件生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，创建所述服务替换进程的同一分布式锁的新的锁文件。

21.根据权利要求19或20所述的服务端，其中，分配装置，用于从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识，根据所述删除锁文件的请求判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，删除所述服务进程所创建的锁文件；

根据从服务替换进程接收的创建请求，为所述替换进程创建同一分布式锁的新的锁文件。

22.根据权利要求21所述的服务端，其中，所述写入装置，还用于在创建对应的分布式锁的具有生命周期的锁文件的之后，在所述锁文件中写入其创建时的事务序号；

所述分配装置，用于根据从客户端接收的事务序号获取请求，向所述客户端发送锁文件在创建时的事务序号；

从服务替换进程接收在所述锁文件的生命周期结束前发送的删除锁文件的请求,所述删除锁文件的请求包含所述服务替换进程的进程标识和所述锁文件在创建时的事务序号，判断所述删除锁文件请求中的事务序号与服务端的所分布式锁述分布式锁的当前锁文件中的创建时的事务序号是否一致，

若一致，删除所述服务进程所创建的锁文件，向所述服务替换进程反馈删除成功，获取所述服务替换进程发送的创建同一分布式锁的新的锁文件的请求。

23.根据权利要求22所述的服务端，其中，分配装置，用于向所述服务替换进程反馈所述锁文件是否删除成功之后，若删除不成功，则向服务替换进程反馈抢占所述锁文件失败。

24.根据权利要求20所述的服务端，其中，分配装置，用于尝试创建所述服务替换进程的同一分布式锁的新的锁文件之后，若尝试创建成功，则向所述服务替换进程反馈抢占所述分布式锁成功。

25.一种基于计算的设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

26.一种基于计算的设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

27.一种存储可执行指令的非暂态计算机可读存储介质，在所述可执行指令由电子设备执行时，使得所述电子设备：

为服务进程分配唯一的进程标识，由所述服务进程向服务端请求创建分布式锁的具有生命周期的锁文件后，向服务端发送在所述锁文件中写入所述进程标识的请求；

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

由所述服务替换进程在所述锁文件的生命周期结束前，向所述服务端发送所述分布式锁的所有权的继承请求，所述继承请求包括所述服务替换进程的进程标识。

28.一种存储可执行指令的非暂态计算机可读存储介质，在所述可执行指令由电子设备执行时，使得所述电子设备：

根据从客户端的服务进程接收的锁文件的创建请求，创建对应的分布式锁的具有生命周期的锁文件；

根据从所述服务进程接收的进程标识写入请求，在所述锁文件中写入所述服务进程的唯一的进程标识，其中，当所述服务进程故障时，由客户端启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程；

获取所述服务替换进程在所述锁文件的生命周期结束前，发送的所述分布式锁的继承请求，所述继承请求中包含所述服务替换进程的进程标识，判断所述服务替换进程的进程标识与所述锁文件中的当前进程标识是否一致，若一致，为所述服务替换进程创建同一分布式锁的新的锁文件。

29.一种锁文件的获取方法，包括：

第一服务进程被创建，其中，所述第一服务进程的进程标识与发生故障的第二服务进程的进程标识相同，所述第二服务进程对应于锁文件；

所述第一服务进程发送所述锁文件的继承请求，其中，所述继承请求包括所述第一服务进程的进程标识。

30.如权利要求29所述的方法，所述第一服务进程发送所述锁文件的继承请求，包括：

由所述第一服务进程发送尝试重新创建所述锁文件的请求，若尝试重新创建失败，由所述第一服务进程发送所述分布式锁的所有权的继承请求。

31.一种锁文件的获取方法，包括：

服务进程被创建，其中，所述服务进程包括进程标识；

所述服务进程发送锁文件的创建请求，其中，所述创建请求包括所述服务进程的进程标识。

32.如权利要求31所述的方法，所述服务进程发送锁文件的创建请求之后，还包括：

当所述服务进程故障时，启动新的服务替换进程来切换所述故障的服务进程，并将所述故障的服务进程的进程标识分配给所述服务替换进程。