[发明专利]加锁请求的处理方法及服务器

说明书

本发明提出一种锁请求的处理技术，第一锁服务器是第二锁服务器的接管锁服务器，所述第一锁服务器在获知所述第二锁服务器发生故障后进入静默状态，静默范围是第二锁服务器已经分配过权限的资源，第一锁服务器收到原本发送给第二锁服务器加锁请求，如果第二锁服务器未曾给这个资源分配资源，则所述第一锁服务器按照加锁请求给所述给相应的资源分配锁权限。应用该方案，可以把锁服务器发生故障所影响的范围减小，提高所管理系统系统的稳定性。

技术领域

本发明涉及计算机技术，尤其是涉及一种锁请求的处理方法及其系统。

背景技术

在由多个主机组成的分布式系统中，由锁服务器实现在同一时间、多个节点对同一资源的互斥访问。当主机需要对资源进行一些操作时，首先需要向锁服务器请求锁权限，当主机获取锁权限之后，才能对资源进行相应的操作，例如读操作或者写操作。所以，锁服务器的性能高低、可用性以及可靠性直接影响到整个分布式系统的性能、可用性和可靠性。

在分布式系统中，主机通过NAS(Network Attacked Storage，网络附属存储)网络与节点通信。每个节点中都设置有锁服务器，各个节点还和存储系统相连，存储系统中存储有文件等资源。

当主机需要对存储系统中的资源进行操作(例如读操作或者写操作)时，先通过主机上的应用程序向锁服务器申请锁权限，获得所服务器给资源分配的锁权限之后，再对文件进行操作。资源的已分配的锁权限与应用程序之间的对应关系，可以存储在各个节点中，也可以存储在各个节点都可以访问的共享存储中。例如，主机需要对存储系统中的文件进行读操作时，首先向某个节点中的锁服务器申请该文件的锁权限，主机在获得该文件的锁权限之后，才能对该文件进行读操作。文件的锁权限与拥有锁权限的应用的对应关系存储在节点中，拥有锁权限的是节点或者节点中的应用。即使拥有锁权限的是节点，这个节点也可以通过进一步的分析，获知是节点中的哪个应用需要使用存储系统中的资源。

当某个锁服务器发生故障时，故障锁服务器上的业务需要切换到未发生故障的锁服务器(后文称为非故障锁服务器)上。在使用NFS(Network File System，网络文件系统)或者Samba等协议时，为了加速主机的访问效率，在故障锁服务器上的业务切换到非故障锁服务器上，主机可以通过锁重申请求来重新申请各应用已经获取的文件的锁权限。这样，在分布式锁服务器集群中，需要安全的对锁重申请求和加锁请求进行控制，避免由于锁权限控制不当而导致多个应用看到的数据不一致，甚至多个应用同时读写数据时造成数据崩溃的问题。

而在现有技术中，当有锁服务器发生故障时，分布式系统中余下的全部锁服务器都进入静默状态。在静默期间，分布式系统中的锁服务器都只能处理重新申请锁权限的锁重申请求，不能处理申请新的锁权限的加锁请求。待故障锁服务器的已授权的锁权限的锁重申请求处理完成后，分布式系统中的锁服务器才退出静默状态，正常处理加锁请求。

在上述现有技术方案中，当分布式系统中有锁服务器发生故障时，分布式系统中的所有锁服务器需要进入静默状态，此时，对任意锁服务器发出的加锁请求，都会被拒绝处理，导致系统的性能和可靠性明显下降。

发明内容

本发明的第一方面，提供一种锁请求的处理方法，可以应用于第一锁服务器，其中，所述第一锁服务器是第二锁服务器的接管锁服务器，所述第一锁服务器存储有所述第二锁服务器的锁管理范围，该方法包括：所述第一锁服务器在获知所述第二锁服务器发生故障后进入静默状态，所述静默状态的静默范围是第二锁服务器已经分配过权限的资源；第一锁服务器接收第一加锁请求，所述第一加锁请求用于请求给第一资源加锁，所述第一加锁请求中携带有第一资源标识；所述第一锁服务器检测到所述第一资源属于所述第二锁服务器的管理范围；所述第一锁服务器查询第一资源信息记录表，所述第一资源信息记录表记录有已被所述第二锁服务器分配了锁权限的资源的ID，如果所述第一资源信息记录表中未记录所述第一资源标识，则所述第一锁服务器按照所述第一加锁请求给所述第一资源分配锁权限。