本发明涉及数据处理技术领域，特别是指一种集群文件系统及其文件锁分配方法。
背景技术：
集群文件系统是指运行在多台计算机之上，之间通过某种方式相互通信从而将集群内所有存储空间资源整合、虚拟化并对外提供文件访问服务的文件系统。其与NTFS、EXT等本地文件系统的目的不同，前者是为了扩展性，后者运行在单机环境，纯粹管理块和文件之间的映射以及文件属性。集群文件系统具有高可用的特点，即是指集群文件系统遭受人为操作失误或自然故障等时，在一定限度内仍能提供正常的文件访问，一般采用副本或者纠删技术对数据进行保护，灾后冗余数据降级后需要进行数据同步；上述的文件访问和数据同步修复的过程中，应用了文件锁机制，即令文件仅能够被持有文件锁的用户访问。
现有的集群文件系统在进行文件的数据修复时，一般是通过划分网段将数据恢复和前端业务进行物理隔离，虽然消除了前端业务数据的带宽冲突，但无法避免前端业务与数据修复之间的进程压力冲突，导致数据修复时会影响前端业务的读写请求，而且用户需要为低概率发生的数据恢复增加物理链路，无疑增加了硬件成本和管理运行成本。
技术实现要素：
有鉴于此，本发明的目的在于提出一种集群文件系统及其文件锁分配方法，使数据修复时不影响前端业务，保证前端业务性能，体现集群文件系统高可用特点，充分复用利用硬件资源，进而降低用户成本。
基于上述目的本发明提供的一种集群文件系统的文件锁分配方法，所述集群文件系统包括：文件锁模块、代理模块；所述方法包括：
所述代理模块从所述文件锁模块获取对于一个文件的文件锁并接收来自多个业务客户端对该文件的多个第一加锁请求；
所述代理模块将所述多个第一加锁请求依时序建立等待队列，按所述等待队列顺序依次响应所述多个第一加锁请求，将所述文件锁分配给相应的业务客户端持有；
所述代理模块监测文件锁状态，当所有业务客户端均不再持有所述文件锁且所述等待队列为空并在后续的预设时长内没有接收到新的第一加锁请求时，将所述文件锁释放；
在所述代理模块未持有文件锁的状态下，所述文件锁模块接收来自修复客户端的第二加锁请求，并将文件锁分配给修复客户端持有。
优选的，所述文件锁模块将文件锁分配给修复客户端持有之后，还包括步骤：
文件锁模块监测所述修复客户端持有文件锁进行文件修复的进度，当修复数据达到预设字长时，令所述修复客户端释放其持有的文件锁。
优选的，所述预设字长为128k。
优选的，所述代理模块将所述多个第一加锁请求依时序建立等待队列，按所述等待队列顺序依次响应所述多个第一加锁请求，将所述文件锁分配给相应的业务客户端持有之后，还包括步骤：
所述代理模块判断当前持有文件锁的业务客户端的加锁区间与所述等待队列中下一第一加锁请求所要求的加锁区间是否存在冲突，若是，则将所述下一第一加锁请求保持于所述等待队列中；若否，则响应所述下一第一加锁请求。
优选的，所述预设时长为：0-10s。
另一方面，本发明还提供了一种应用如上任意一项所述的方法的集群文件系统，其包括用于分配文件锁的文件锁模块，还包括：
代理模块，用于从所述文件锁模块获取对于一个文件的文件锁并接收来自多个业务客户端对该文件的多个第一加锁请求；将所述多个第一加锁请求依时序建立等待队列，按所述等待队列顺序依次响应所述多个第一加锁请求，将所述文件锁分配给相应的业务客户端持有；监测文件锁状态，当所有业务客户端均不再持有所述文件锁且所述等待队列为空并在后续的预设时长内没有接收到新的第一加锁请求时，将所述文件锁释放；
所述文件锁模块进一步用于在所述代理模块未持有文件锁的状态下，接收来自修复客户端的第二加锁请求，并将文件锁分配给修复客户端持有。
优选的，所述文件锁模块进一步用于：监测所述修复客户端持有文件锁进行文件修复的进度，当修复数据达到预设字长时，令所述修复客户端释放其持有的文件锁。
优选的，所述预设字长为128k。
优选的，所述代理模块进一步用于：判断当前持有文件锁的业务客户端的加锁区间与所述等待队列中下一第一加锁请求所要求的加锁区间是否存在冲突，若是，则将所述下一第一加锁请求保持于所述等待队列中；若否，则响应所述下一第一加锁请求。
优选的，所述预设时长为：0-10s。
从上面所述可以看出，本发明提供的集群文件系统及其文件锁分配方法，将前端业务进程与数据修复进程进行逻辑隔离，使数据修复时不影响前端业务，具体包括如下优点：
(1)当前端业务客户端有访问请求时，后端数据同步修复会等待。
(2)保证业务数据安全的同时降低了因数据同步对前端业务的影响，降低硬件成本和运营管理成本。
(3)后端可自动利用前端访问的空闲或访问压力较小的时段进行数据同步修复，在不影响前端业务的同时，尽量缩短数据同步修复的时间窗口，提高数据安全。
(4)无须专业工程师介入，降低了运营维护成本。
(5)数据同步修复能与前端业务逻辑隔离，避免IO冲突影响前端业务性能。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例的集群文件系统的文件锁分配方法流程图；
图2为本发明实施例的集群文件系统结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。
需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。
本发明实施例提供了一种集群文件系统及其文件锁分配方法。现有的集群文件系统一般都包括文件锁模块，用于分配文件锁，具体的其会根据客户端的对于某文件的加锁请求，将文件锁分配给相应的客户端持有；在客户端完成其既定的工作后，会将文件锁释放，此时文件锁即可以被分配至其他的客户端。本发明实施例中，使用的文件锁可以为读写锁或互斥锁，使用不同类型的文件锁不影响本发明实施的技术效果，且上述各类型的文件锁的具体功能为现有技术，说明书中不再详述。对于上述的客户端，一般包括业务客户端和修复客户端。业务客户端一般位于系统前端、由用户使用，通过业务客户端进行前端业务过程；修复客户端一般位于系统后端，同于进行文件的数据修复过程。
本实施例中，所述的集群文件系统包括：文件锁模块和代理模块。其中，文件锁模块与现有技术中一样，用户分配文件锁；代理模块为本发明的专有模块，用于对来自业务客户端的加锁请求(本实施例中为第一加锁请求)进行分配管理。具体的，本实施例的集群文件系统的文件锁分配方法，包括以下步骤：
所述代理模块从所述文件锁模块获取对于一个文件的文件锁并接收来自多个业务客户端对该文件的多个第一加锁请求；
所述代理模块将所述多个第一加锁请求依时序建立等待队列，按所述等待队列顺序依次响应所述多个第一加锁请求，将所述文件锁分配给相应的业务客户端持有；
所述代理模块监测文件锁状态，当所有业务客户端均不再持有所述文件锁且所述等待队列为空并在后续的预设时长内没有接收到新的第一加锁请求时，将所述文件锁释放；
在所述代理模块未持有文件锁的状态下，所述文件锁模块接收来自修复客户端的第二加锁请求，并将文件锁分配给修复客户端持有。
通过上述实施例可见，本发明的集群文件系统的文件锁分配方法，通过对来自业务客户端的第一加锁请求和来自修复客户端的第二加锁请求进行逻辑上的隔离，使第一加锁请求的优先级高于第二加锁请求；在效果上，当前端业务有访问请求时，数据同步修复进程会避让；若前端无业务访问时后端数据同步修复进程会几乎可以尽全力进行。进一步的，通过预设时长的设置，灵活调节业务客户端和修复客户端加锁优先级，控制修复客户端的同步速度，使其可复用物理链路，节省用户成本。此外，本发明的方法还可适用与多种数据保护算法，比如冗余副本，纠删码技术等；也可以适用于其他后端同步需求，比如分层存储、数据再平衡等。
参考图1，为本发明实施例的集群文件系统的文件锁分配方法流程图。
作为一个更加具体的实施例，所述集群文件系统的文件锁分配方法，包括以下步骤：
步骤101、所述代理模块从所述文件锁模块获取对于一个文件的文件锁并接收来自多个业务客户端对该文件的多个第一加锁请求。
对于集群文件系统中的某个文件，业务客户端对于该文件加锁请求一般是指同一业务客户端发出的对于文件不同数据区间的加锁请求，以及不同业务客户端发出的对于文件的加锁请求，上述加锁请求在本实施例中称其为第一加锁请求。
本步骤中，代理模块首先从文件锁模块获取文件锁。在代理模块持有文件锁的状态下，来自业务客户端的第一加锁请求均会被发送至代理模块进行处理。
步骤102、所述代理模块将所述多个第一加锁请求依时序建立等待队列，按所述等待队列顺序依次响应所述多个第一加锁请求，将所述文件锁分配给相应的业务客户端持有。
对于接收到的多个第一加锁请求，首先根据其时间顺序建立等待队列，在等待队列中，多个第一加锁请求按照时间由早到晚的顺序依次排列。接下来，按照等待队列的中多个第一加锁请求顺序依次响应，并进一步的将文件锁分配给相应的业务客户端持有。也就是说，当前持有文件锁的业务客户端完成工作将文件锁释放后，文件锁不会向其他所有的加锁请求发出端提供同等的获取机会，而是根据等待队列，将文件锁分配给等待队列中下一个发出第一加锁请求的业务客户端。
步骤103、所述代理模块判断当前持有文件锁的业务客户端的加锁区间与所述等待队列中下一第一加锁请求所要求的加锁区间是否存在冲突，若是，则执行步骤104；若否，则执行步骤105。
本步骤中，在一个业务客户端当前持有文件锁的情况下，进一步的判断等待队列中下一第一加锁请求所要求的加锁区间是否与当前持有文件锁的业务客户端的加锁区间存在冲突。所述加锁区间是指，不同的业务客户端发出的第一加锁请求所要求加锁的文件区间，加锁区间存在冲突是指两者的加锁区间存在重叠的部分；加锁区间不存在冲突是指两者的加锁区间不存在重叠的部分，再加锁区间不存在重叠的部分的情况下，则可以将文件锁同时分配给相应的两个业务客户端同时持有，该两个业务客户端完成各自的文件数据访问工作时，不会产生冲突。
步骤104、将所述下一第一加锁请求保持于所述等待队列中。
在当前持有文件锁的业务客户端的加锁区间与所述等待队列中下一第一加锁请求所要求的加锁区存在冲突时，将下一第一加锁请求保持于等待队列中，待当前持有文件锁的业务客户端将文件锁释放后，在将文件锁分配给等待队列中发出下一第一加锁请求的业务客户端。
步骤105、响应所述下一第一加锁请求。
在当前持有文件锁的业务客户端的加锁区间与所述等待队列中下一第一加锁请求所要求的加锁区不存在冲突时，响应等待队列中下一第一加锁请求，将文件锁同时分配给发出下一第一加锁请求的业务客户端。
步骤106、所述代理模块监测文件锁状态，当所有业务客户端均不再持有所述文件锁且所述等待队列为空并在后续的预设时长内没有接收到新的第一加锁请求时，将所述文件锁释放。
本步骤中，会持续监测文件锁的状态，当监测到所有业务客户端持有的文件锁均已释放且等待队列为空时，进一步的在后续的预设时长内持续没有监测到有接收新的第一加锁请求并加入等待队列时，将所述文件锁释放。具体的，所述的预设时长的可选范围为：0-10s；优选的预设时长设置为1s。
步骤107、在所述代理模块未持有文件锁的状态下，所述文件锁模块接收来自修复客户端的第二加锁请求，并将文件锁分配给修复客户端持有。
文件锁被代理模块释放后，文件锁模块能够接收并响应来自修复客户端的第二加锁请求，根据所述的第二加锁请求，将文件锁分配给修复客户端持有，修复客户端持有文件锁后即开始对所述文件进行数据同步修复。
步骤108、文件锁模块监测所述修复客户端持有文件锁进行文件修复的进度，当修复数据达到预设字长时，令所述修复客户端释放其持有的文件锁。
在将文件锁分配给修复客户端持有，修复客户端持有文件锁对所述文件进行数据同步修复的过程中，监测所述修复客户端持有文件锁进行文件修复的进度，当修复数据达到预设字长时，立刻发出指令，使修复客户端释放其持有的文件锁。作为优选的，所述预设字长为128k。
通过本步骤，将修复客户端持有文件锁进行数据同步修复的时长进行限制，修复客户端想要继续数据同步修复时，需要重新发送第二加锁请求，这样能够尽可能的使文件锁有业务客户端持有，优选业务数据处理。
参考图2，为本发明实施例的集群文件系统结构示意图。
另一方面，本发明实施例还提供了一种集群文件系统，该集群文件系统应用了如上述实施例所述的文件锁分配方法。所述集群文件系统除了包括用于分配文件锁的文件锁模块201之外，还包括：代理模块202。
本实施例中，所述的代理模块202用于从所述文件锁模块201获取对于一个文件的文件锁并接收来自多个业务客户端203对该文件的多个第一加锁请求；将所述多个第一加锁请求依时序建立等待队列，按所述等待队列顺序依次响应所述多个第一加锁请求，将所述文件锁分配给相应的业务客户端203持有；监测文件锁状态，当所有业务客户端203均不再持有所述文件锁且所述等待队列为空并在后续的预设时长内没有接收到新的第一加锁请求时，将所述文件锁释放；
此外，在本实施例中，所述文件锁模块201进一步用于在所述代理模块202未持有文件锁的状态下，接收来自修复客户端204的第二加锁请求，并将文件锁分配给修复客户端204持有。
在优选实施方式中，所述文件锁模块201进一步用于：监测所述修复客户端204持有文件锁进行文件修复的进度，当修复数据达到预设字长时，令所述修复客户端204释放其持有的文件锁。其中，所述预设字长为128k。
在优选实施方式中，所述代理模块202进一步用于：判断当前持有文件锁的业务客户端203的加锁区间与所述等待队列中下一第一加锁请求所要求的加锁区间是否存在冲突，若是，则将所述下一第一加锁请求保持于所述等待队列中；若否，则响应所述下一第一加锁请求。其中，所述预设时长为：0-10s；优选的，所述预设时长为1s。
所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明它们没有在细节中提供。因此，凡在本发明的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明的保护范围之内。