前文，在此不再赘述。
[0164]步骤62中在第一客户端请求释放的锁存储在第一锁管理服务器中的前提下，还针对该锁被所述第一客户端占用的情况。因此，在所述第一锁管理服务器确定所述锁存储在所述第一锁管理服务器中之后，还可以执行以下步骤:
[0165]所述第一锁管理服务器判断所述锁的状态是否被所述第一客户端占用，如果是，则执行步骤62，如果否，则根据分布式系统中部署的CMS是否同时管理锁管理服务器和客户端的状态，可能会执行以下步骤:
[0166]若所述第一锁管理服务器中所述锁的状态为占用，且占用所述锁的第二客户端发生故障，则所述第一锁管理服务器将所述锁的状态设置为空闲。
[0167]具体来讲，在第一客户端请求释放的锁存储在第一锁管理服务器的前提下，如果该锁被第一客户端占用，则说明该锁释放请求是合法的，该锁可以被释放，此时，第一锁管理服务器关闭该锁的租约定时器、将该锁的状态设置为空闲，将该锁的持有者设置为无。之后通知第一客户端锁释放成功。
[0168]在第一客户端请求释放的锁存储在第一锁管理服务器的前提下，如果该锁不被第一客户端占用，而是被其他客户端(例如第二客户端)占用，则说明该锁已经被分配给第二客户端。此时第一锁管理服务器需要针对第二客户端的状态是工作正常的情况以及第二客户端的状态是发生故障的情况分别做不同的处理。第一锁管理服务器可以通过CMS获知第二客户端的状态。
[0169]如果CMS仅支持锁管理服务器状态查询，则第一锁管理服务器通过CMS无法得到第二客户端的状态，也即第一锁管理服务器无法获知第二客户端是工作正常还是发生故障，因此，第一锁管理服务器只能通知第一客户端锁释放失败。
[0170]如果CMS同时支持锁管理服务器和客户端状态查询，则第一锁管理服务器通过CMS可以获知第二客户端是工作正常还是发生故障，如果第二客户端工作正常，则表明第二客户端正在正常占用该锁，第一锁管理服务器不能将释放该锁，只能通知第一客户端锁分配失败；如果第二客户端发生故障，则表明第二客户端没有能力占用该锁，第一锁管理服务器将该锁的状态设置为空闲，将该锁的持有者设置为无。之后通知第一客户端锁释放成功。
[0171]步骤63中针对第一客户端请求申请的锁未存储在第一锁管理服务器中的情况。
[0172]具体来讲，第一锁管理服务器接收到第一客户端发送的锁释放请求，但是第一客户端请求释放的锁未存储在第一锁管理服务器中，一种实施方式为第一锁管理服务器不对该锁释放请求进行响应。另一种实施方式为:第一锁管理服务器生成锁，并设置生成的锁的状态为占用。第一锁管理服务器生成锁是为了缩短以后其他客户端申请锁的等待时间，如果以后有其他客户端向第一锁管理服务器生成锁，则由于第一锁管理服务器存储有该锁，所以其他客户端无需等待，即可申请到该锁。第一锁管理服务器将生成的锁置为占用是因为:第一锁管理服务器中没有该锁，则说明原本存储有该锁的原始锁管理服务器发生了故障，考虑到可能在原始锁管理服务器发生故障之前，该锁已经被分配给其他客户端占用，为避免同一个资源对应的锁分配给多个客户端，造成多个客户端访问资源发生冲突，将生成的锁置为占用。
[0173]下面举一个例子说明客户端从申请锁到释放锁的全过程。请参考图7，图7为本发明实施例中客户端进行锁操作的流程图。包括以下步骤:
[0174]步骤1:客户端申请资源标识为ResourceX对应的锁，以Hash_clutser计算得到Server_l 0到Server_l上申请该锁。
[0175]步骤2:Server_l首先通过ResourceX检查锁是否为自己所管理。是，则继续检查锁是否已被占用。如果空闲，则启动租约定时器，将锁置为占用状态，记录锁的持有者为客户端。
[0176]步骤3:Server_l通知客户端申请锁成功锁。
[0177]步骤4:客户端访问锁对应的资源。
[0178]步骤5:客户端对锁对应的资源访问完成。
[0179]步骤6:客户端释放锁给Server_l。
[0180]步骤7:Server_l关闭租约定时器，锁置为空闲。
[0181]在以上步骤中可能出现以下冲突情况:
[0182]在步骤I中，客户端发现Server_l已经发生故障，则需要通过Server_l专有的Hash_serveice，重亲jfi十算亲jf 的 Server0
[0183]在步骤2中，Server_l检查锁已被占用，则通知客户端申请锁失败。
[0184]在步骤7中，ServerJ检查锁释放请求是否是客户端所发送，如果不是客户端发送的锁释放请求，锁释放请求将被丢失。
[0185]为使本领域的技术人员更加理解本发明实施例，下面举例说明锁管理服务器对锁申请请求的处理过程。请参考图8，图8为本发明实施例中锁管理服务器对锁申请请求进行处理的示意图。包括以下步骤:
[0186]申请步骤1:客户端请求申请资源标识为ResourceX对应的锁，以Hash_clutser计算得到Server_l。判断Server_l的状态，如果工作正常，则转入申请步骤2，否则转入申请步骤1.1。
[0187]申请步骤1.1，客户端继续执行Server_l的Hash_service (ResourceX的历史故障节点列表，ResourceX)，此时ResourceX的历史故障节点列表包含:Server_l。假设计算得到Server_2。如果Server_2工作正常，则转入申请步骤2。否则需反复执行此步骤，直到找到工作正常的Server，转入申请步骤2 ;或分布式系统中的所有锁管理服务器全部发生故障，转入申请步骤5。
[0188]申请步骤2:Server_l (或Server_2)检查锁是否存在。如果存在，说明这把锁已经被申请过，转入申请步骤3。否则，转入申请步骤2.10
[0189]申请步骤2.1:检查锁申请请求是否合法。此时做检查点I。
[0190]检查点1:通过ResourcelD，来检查锁是否为自己所管理。检查方式为:执行锁管理服务器集群的Hash_cluster，得到的ServerlD，与自己的ID比较即可。
[0191](I)如果是自己管理的锁，则检查完成，转入申请步骤2.2。
[0192](2)如果不是自己管理的锁，则表示锁的原始锁管理服务器发生故障。此时做检查点2。
[0193]检查点2:检查ResourceX的历史故障节点列表中是否存在工作正常的Server。
[0194](I)如果存在，则本次锁申请请求为非法请求，转入申请步骤5。
[0195](2)如果不存在，则检查完成，转入申请步骤2.2。
[0196]申请步骤2.2:Serverl (或Server2)根据ResourceID创建锁，并分配给客户端。
[0197]申请步骤3:检查锁是否已被占用。⑴如果锁的状态为空闲，则启动租约定时器，将锁置为占用状态，锁的持有者置为客户端。转入申请步骤4。(2)如果锁已经被占用，转入申请步骤3.10
[0198]申请步骤3.1:(1)如果“CMS仅支持锁管理服务器状态查询”，转入申请步骤5。
(2)如果“CMS同时支持锁管理服务器和客户端状态查询”，并且锁的持有者不是无，则转入申请步骤3.2。
[0199]申请步骤3.2，查询锁的持有者状态。
[0200](I)如果锁的持有者工作正常，则转入申请步骤5。
[0201](2)如果锁的持有者发生故障，将锁置为占用状态，锁的持有者置为客户端。转入申请步骤4。
[0202]申请步骤4:通知客户端，锁申请成功。操作完成。
[0203]申请步骤5:通知客户端，锁申请失败。操作完成。
[0204]为使本领域的技术人员更加理解本发明实施例，下面举例说明锁管理服务器对锁释放请求的处理过程。请参考图9，图9为本发明实施例中锁管理服务器对锁释放请求进行处理的示意图。包括以下步骤:
[0205]释放步骤1:客户端请求释放资源标识为ResourceX对应的锁，以Hash_clutser计算得到Server_l。判断Server_l的状态，如果工作正常，则转入释放步骤2，否则转入释放步骤1.1。
[0206]释放步骤1.1:客户端继续执行Server_l的Hash_service (ResourceX的历史故障节点列表，ResourceX)，此时ResourceX的历史故障节点列表包含:Server_l。假设计算得到Server_2。如果Server_2工作正常，则转入释放步骤2。否则需反复执行此步骤，直到找到工作正常的Server，转入释放步骤2 ;或分布式系统中的所有锁管理服务器全部发生故障，转入释放步骤5。
[0207]释放步骤2:Server_l (或Server_2)检查锁是否存在。如果存在，说明这把锁已经被申请过，转入释放步骤3。否则，转入释放步骤2.10
[0208]释放步骤2.2:Serverl (或Server2)根据ResourceID创建锁。将锁的状态置为占用，锁的持有者置为无。
[0209]释放步骤3:检查锁的持有者是否是客户端。(I)如果锁的持有者是客户端，则关闭租约定时器，将锁置为空闲状态，锁的持有者置为无。转入释放步骤4。(2)如果锁的持有者不是客户端，转入释放步骤3.10
[0210]释放步骤3.1:(1)如果“CMS仅支持锁管理服务器状态查询”，转入释放步骤5。
(2)如果“CMS同时支持锁管理服务器和客户端状态查询”，并且锁的持有者不是无，则转入释放步骤3.2。
[0211]释放步骤3.2，查询锁的持有者状态。
[0212](I)如果锁的持有者工作正常，则转入释放步骤5。
[0213](2)如果锁的持有者发生故障，将锁置为空闲状态，锁的持有者置为无。转入释放步骤4。
[0214]释放步骤4:通知客户端，锁释放成功。操作完成。
[0215]释放步骤5:通知客户端，锁释放失败。操作完成。
[0216]本发明实施例还提供锁管理服务器集群扩容。如果锁管理服务器集群需要从N个锁管理服务器扩大到N+1个锁管理服务器，原本N个锁管理服务器中Server ID的最小值为M，则服务器ID有效范围由[M，M+N)变为[M，M+N+1)，哈希桶的范围由[M，M+N)变为[Μ, M+N+1)，客户端可以利用变化后的服务器ID有效范围以及哈希同的范围，要利用Hash_cluster以Resource ID为入参得到中间结果，再获得中间结果对N+1的余数[0，N+1)，余数加上M即为新的Server ID。
[0217]对于扩容进来的锁管理服务器(简称为扩容锁管理服务器)，需要首先设置为启动状态，启动扩容锁管理服务器所管理的资源对应的锁的初始化，待初始化完成之后设置为正常工作状态，此时，扩容锁管理服务器才能对外提供服务。此外，需要将N变为N+1、扩容后锁管理服务器集群中的锁管理服务器的ServerlD、以及扩容后锁管理服务器集群中的锁管理服务器的状态同步到客户端。如果扩容锁管理服务器发现自己管理了其他锁管理服务器(例如:第五锁管理服务器)的锁，并且第五锁管理服务器的状态为正常工作，则扩容锁管理服务器删除这些锁。
[0218]其中，扩容锁管理服务器所管理的资源对应的锁的初始化的方式为:向CMS获取扩容锁管理服务器管理的锁，建立锁，将建立的锁为占用，待建立的锁超时之后，则建立的锁可用。在扩容锁管理服务器所管理的资源对应的锁的初始化实现的过程中，扩容锁管理服务器可以接收客户端发送的锁申请请求或锁释放请求。操作过程参见前文。
[0219]对于锁管理服务器从发生故障恢复到工作正常的情况，与锁管理服务器集群扩容有相似之处。对于从发生故障恢复到工作正常的锁管理服务器(下文简称恢复的锁管理服务器)，需要首先设置为启动状态，启动恢复的锁管理服务器所管理的资源对应的锁的初始化，待初始化完成之后设置为正常工作状态，此时，恢复的锁管理服务器才能对外提供服务。
[0220]其中，恢复的锁管理服务器所管理的资源对应的锁的初始化的方式，可参考扩容锁管理服务器所管理的资源对应的锁的初始化的方式。
[0221]本发明实施例还提供资源扩容。如果需要资源扩容，则只需将扩容进来的资源其添加到CMS即可。对于扩容进来的资源对应的锁，首次被申请时该锁被添加到对应的锁管理服务器。
[0222]本发明实施例还提供锁管理服务器