CN108924266A - 一种基于分布式文件系统的客户端请求分离管理方法及装置 - Google Patents

Abstract

本申请公开一种基于分布式文件系统的客户端请求分离管理方法及装置，该方法包括：在接收到至少一个客户端请求后，将所有客户端请求分离存放到不同的软件层session中，这样，不同session可单独将自身存储的客户端请求发送至该客户端请求对应的元数据服务器中，以便元数据服务器对该客户端请求进行处理。可见，本申请在接收到客户端请求后，不再采用统一管理的方式，将所有客户端请求存放在同一个容器中进行管理，而是将所有客户端请求分离存放在不同的session中，从而可通过不同的session同时将各自的客户端请求发送至各个客户端请求对应的元数据服务器，进而通过这种分离管理的方式，实现了客户端各个session的并发功能，有效发挥了客户端多核系统的优势，提高了系统性能。

Description

一种基于分布式文件系统的客户端请求分离管理方法及装置

技术领域

本申请涉及分布式存储文件系统技术领域，具体涉及一种基于分布式文件系统的客户端请求分离管理方法及装置。

背景技术

当前，随着数据时代的到来，日常需要存储的数据量越来越大，在这种背景下，分布式文件系统的存储服务器开始得到了广泛地应用。

目前分布式文件系统的存储服务器在接收到客户端请求后，会将所有客户端请求存放到一个统一的容器中进行管理，比如，存放在一个统一的系统进程中，但随着大数据时代的到来，客户端请求数据爆炸式的增长，若仍仅依靠一个容器对所有客户端请求进行统一管理，将导致在对存放资源的容器进行数据查询时，出现遍历性能较差，且无并发能力的问题，并且，由于目前客户端系统大都以多核系统为主，这就导致目前的对客户端请求的统一存储及管理方式并不能发挥出多核分布式系统的优势。

因此，如何利用更先进的客户端请求管理方式取代传统的管理方式，实现在分布式文件系统的基础上提高客户端的高并发能力，从而有效发挥客户端多核系统的优势，已成为亟待解决的问题。

发明内容

为解决上述问题，本申请提供了一种基于分布式文件系统的客户端请求分离管理方法及装置，具体技术方案如下：

第一方面，本申请提供了一种基于分布式文件系统的客户端请求分离管理方法，所述方法应用于存储服务器，所述方法包括：

接收至少一个客户端请求；

将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器。

在一种可选的实现方式中，所述session分布在所述存储服务器的客户端中；所述存储服务器为分布式文件系统。

在一种可选的实现方式中，所述方法还包括：

将客户端已处理过的客户端请求的标识分离存放到对应的session中；

通过所述不同的session记录所述自身已处理过的客户端请求的标识。

在一种可选的实现方式中，所述将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器之后，还包括：

判断是否出现卸载unmount情况，所述unmount情况包括所述存储服务器的客户端不提供服务的情况；

若是，则删除所述session。

在一种可选的实现方式中，所述将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器之后，还包括：

在所述存储服务器的客户端被重置后，重新启动所述session。

第二方面，本申请提供了一种基于分布式文件系统的客户端请求分离管理装置，所述装置包括：

接收单元，用于接收至少一个客户端请求；

第一分离单元，用于将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器。

在一种可选的实现方式中，所述session分布在所述存储服务器的客户端中；所述存储服务器为分布式文件系统。

在一种可选的实现方式中，所述装置还包括：

第二分离单元，用于将客户端已处理过的客户端请求的标识分离存放到对应的session中；

记录单元，用于通过所述不同的session记录所述自身已处理过的客户端请求的标识。

在一种可选的实现方式中，所述装置还包括：

判断单元，用于判断是否出现卸载unmount情况，所述unmount情况包括所述存储服务器的客户端不提供服务的情况；

删除单元，用于若出现卸载unmount情况，则删除所述session。

在一种可选的实现方式中，所述装置还包括：

重启单元，用于在所述存储服务器的客户端被重置后，重新启动所述session。

在本申请提供的基于分布式文件系统的客户端请求分离管理方法中，在接收到至少一个客户端请求后，将所有接收到的客户端请求分离存放到不同的软件层session中，每个session中对应存放各自不同的客户端请求，这样，不同的session可以单独将自身存储的客户端请求发送至该客户端请求对应的元数据服务器(Metadata Server，简称mds)中，以便元数据服务器对该客户端请求进行处理。可见，本申请在接收到客户端请求后，不再采用统一管理的方式，将所有客户端请求存放在同一个容器中进行管理，而是将所有接收到的客户端请求分离存放在不同的session中，每个session中存放各自不同的客户端请求，从而可通过不同的session同时将各自的客户端请求发送至各个客户端请求对应的元数据服务器，进而通过这种分离管理的方式，实现了客户端各个session的并发功能，也实现了客户端请求的并发，有效发挥了客户端多核系统的优势，提高了系统性能。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种基于分布式文件系统的客户端请求分离管理方法的流程图；

图2为本申请实施例提供的重新启动及删除session的流程图；

图3为本申请实施例提供的客户端请求管理方式的对比示意图；

图4为本申请实施例提供的一种基于分布式文件系统的客户端请求分离管理装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了便于理解本申请提供的技术方案，下面先对本申请技术方案的研究背景进行简单说明。

众所周知，正如背景技术中的描述，目前随着大数据时代的到来，系统需要处理的数据量越来越大，特别是在分布式文件系统中，对于客户端请求对应的元数据的操作非常频繁，目前，分布式文件系统的存储服务器在接收到客户端请求后，会将所有客户端请求存放到一个统一的容器中进行管理，比如，存放在一个统一的系统进程中，但随着客户端请求数据爆炸式的增长，若仍仅依靠一个系统容器对所有客户端请求进行统一管理，将导致在对存放资源的容器进行数据查询时，出现遍历性能较差，以及无并发能力的问题，并且，这种统一管理的方式也无法发挥出多核分布式系统的优势。所以，如何利用更先进的客户端请求管理方式取代传统的管理方式，实现在分布式文件系统的中提高客户端的高并发能力，从而有效发挥客户端多核系统的优势，已成为亟待解决的问题。

基于此，本申请提出了一种基于分布式文件系统的客户端请求分离管理方法及装置，用于实现基于分布式文件系统的客户端请求智能管理。

以下将结合附图对本申请实施例提供的基于分布式文件系统的客户端请求分离管理方法进行详细说明。参见图1，其示出了本申请实施例提供的一种基于分布式文件系统的客户端请求分离管理方法的流程图，本实施例可以包括以下步骤：

S101：接收至少一个客户端请求。

在本实施例中，随着人们越来越多的采用分布式文件系统的存放服务器，为了在分布式文件系统的基础上提高客户端的高并发能力，实现对客户端请求的智能管理，发挥客户端多核系统的优势，在接收到至少一个客户端请求后，可以通过后续步骤S102实现对接收到的所有客户端请求的智能管理。

S102：将接收到的客户端请求分离存放到不同的软件层session中，以便不同的session分别将各自存储的客户端请求发送至对应的元数据服务器。

在本实施例中，通过步骤S101接收到至少一个客户端请求后，为了实现对这些客户端请求的智能管理，提高系统并发能力，可以将这些客户端请求分离存放到不同的session中，其中，一种可选的实现方式是，这些不同的session均分布存储服务器的客户端中，且该存储服务器为分布式文件系统。

进一步的，不同的session可以将自身存储的客户端请求发送至该客户端请求对应的元数据服务器中，以便对应的元数据服务器可以对该客户端请求进行处理，并在处理后，将所需的元数据发送回对应的session中，从而实现客户端中每个session与其存储的客户端请求所对应的元数据服务器之间的数据通信。

在本申请一些可能的实现方式中，本实施例在通过步骤S102将接收到的客户端请求分离存放到不同的软件层session中，以便不同的session分别与其存储的客户端请求所对应的元数据服务器之间进行数据通信之后，还包括步骤A-B：

步骤A：将客户端已处理过的客户端请求的标识分离存放到对应的session中。

在本实现方式中，针对于已处理过的客户端请求，即已通过session与元数据服务器之间的数据通信，完成对客户端请求的处理后，可以将这些已处理过的客户端端请求的标识存放在列表“oldest_tid”中，进而再通过对该列表解析拆分后，将各个处理过的客户端端请求的标识分离存放到对应的session中，并且，每个已处理过的客户端端请求的标识在元数据服务器端针对的也是固定的元数据服务器，即一个客户端请求对应了一个特定的元数据服务器。

步骤B：通过不同的session记录自身已处理过的客户端请求的标识。

在本实现方式中，通过步骤A将客户端已处理过的客户端请求的标识分离存放到对应的session中后，进一步可通过不同的session记录这些自身已处理过的客户端请求的标识，也就是说，可以通过不同的session单独记录并维护自身的列表“oldest_tid”，该表中存放的也是自身已处理过的客户端请求的标识。

在本申请一些可能的实现方式中，在通过步骤S101-S102将客户端请求分离存放到不同的软件层session中，以便不同的session分别将各自存储的客户端请求发送至对应的元数据服务器之后，本实施例进一步可以判断存储服务器是否出现卸载unmount情况，其中，unmount情况包括存储服务器的客户端不提供服务的情况，若出现了这种情况，则可以删除已建立的session，如图2所示，其示出了本申请实施例提供的重新启动及删除session的流程图，当出现unmount情况时，可以关闭session服务，并且将其删除，但需要说明的是，本实施不仅不会删除session对象本身，也不会删除session对象中存储的内容。

在本申请一些可能的实现方式中，在通过步骤S101-S102将客户端请求分离存放到不同的软件层session中，以便不同的session分别将各自存储的客户端请求发送至对应的元数据服务器之后，本实施例进一步还可以在存储服务器客户端进行重置(reset)时，对session进行重新启动(reopen)服务，如图2所示，如果出现客户端的session与元数据服务器在进行TCP通信时，出现连接超时等情况导致网络中断时，都将引起存储服务器客户端进行reset，此时，可以对session进行reopen服务，同时，保证session内的资源保持不变，进而避免出现非法删除session内的资源的情况，即保护了session资源，使其在系统运行过程中不被删除。

这样，在本申请提供的基于分布式文件系统的客户端请求分离管理方法中，在接收到至少一个客户端请求后，将所有接收到的客户端请求分离存放到不同的软件层session中，每个session中对应存放各自不同的客户端请求，这样，不同的session可以单独将自身存储的客户端请求发送至该客户端请求对应的元数据服务器中，以便元数据服务器对该客户端请求进行处理。可见，本申请在接收到客户端请求后，不再采用统一管理的方式，将所有客户端请求存放在同一个容器中进行管理，而是将所有接收到的客户端请求分离存放在不同的session中，每个session中存放各自不同的客户端请求，从而可通过不同的session同时将各自的客户端请求发送至各个客户端请求对应的元数据服务器，进而通过这种分离管理的方式，实现了客户端各个session的并发功能，也实现了客户端请求的并发，有效发挥了客户端多核系统的优势，提高了系统性能。

为便于理解，现结合图3所示客户端请求管理方式的对比示意图。对本申请实施例提供的基于分布式文件系统的客户端请求分离管理方法的实现效果进行介绍。

如图3所示，其示出了本申请实施例提供的实现客户端请求分离管理的效果与目前利用统一的容器对客户端请求进行管理的方法的对比示意图，从图4可以看出，本申请将所有客户端分离存放在不同的session中，即每个session中对应存放各自不同的客户端请求mds_requests，并且，由每个不同的session单独记录和维护自身的列表“oldest_tid”，这样，可以通过不同的session同时将各自的客户端请求mds_requests发送至各个客户端请求对应的元数据服务器mds端，进而可以通过这种分离管理的方式，实现客户端中各个session的并发功能，也实现了客户端请求的并发，有效发挥了客户端多核系统的优势，提高了系统性能。

上述实施例详细叙述了本申请方法的技术方案，相应地，本申请还提供了一种基于分布式文件系统的客户端请求分离管理装置，下面对该装置进行介绍。

参见图4，图4是本申请实施例提供的一种基于分布式文件系统的客户端请求分离管理装置的结构图，如图4所示，该装置包括：

接收单元401，用于接收至少一个客户端请求；

第一分离单元402，用于将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器。

可选地，所述session分布在所述存储服务器的客户端中；所述存储服务器为分布式文件系统。

可选地，所述装置还包括：

第二分离单元，用于将客户端已处理过的客户端请求的标识分离存放到对应的session中；

记录单元，用于通过所述不同的session记录所述自身已处理过的客户端请求的标识。

可选地，所述装置还包括：

判断单元，用于判断是否出现卸载unmount情况，所述unmount情况包括所述存储服务器的客户端不提供服务的情况；

删除单元，用于若出现卸载unmount情况，则删除所述session。

可选地，所述装置还包括：

重启单元，用于在所述存储服务器的客户端被重置后，重新启动所述session。

这样，在本申请提供的基于分布式文件系统的客户端请求分离管理装置中，在接收到至少一个客户端请求后，将所有接收到的客户端请求分离存放到不同的软件层session中，每个session中对应存放各自不同的客户端请求，这样，不同的session可以单独将自身存储的客户端请求发送至该客户端请求对应的元数据服务器中，以便元数据服务器对该客户端请求进行处理。可见，本申请在接收到客户端请求后，不再采用统一管理的方式，将所有客户端请求存放在同一个容器中进行管理，而是将所有接收到的客户端请求分离存放在不同的session中，每个session中存放各自不同的客户端请求，从而可通过不同的session同时将各自的客户端请求发送至各个客户端请求对应的元数据服务器，进而通过这种分离管理的方式，实现了客户端各个session的并发功能，也实现了客户端请求的并发，有效发挥了客户端多核系统的优势，提高了系统性能。

需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统或装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种基于分布式文件系统的客户端请求分离管理方法，其特征在于，所述方法应用于存储服务器，所述方法包括：

接收至少一个客户端请求；

将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器。

2.根据权利要求1所述的基于分布式文件系统的客户端请求分离管理方法，其特征在于，所述session分布在所述存储服务器的客户端中；所述存储服务器为分布式文件系统。

3.根据权利要求1所述的基于分布式文件系统的客户端请求分离管理方法，其特征在于，所述方法还包括：

将客户端已处理过的客户端请求的标识分离存放到对应的session中；

通过所述不同的session记录所述自身已处理过的客户端请求的标识。

4.根据权利要求1-3任一项所述的基于分布式文件系统的客户端请求分离管理方法，其特征在于，所述将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器之后，还包括：

判断是否出现卸载unmount情况，所述unmount情况包括所述存储服务器的客户端不提供服务的情况；

若是，则删除所述session。

5.根据权利要求1-3任一项所述的基于分布式文件系统的客户端请求分离管理方法，其特征在于，所述将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器之后，还包括：

在所述存储服务器的客户端被重置后，重新启动所述session。

6.一种基于分布式文件系统的客户端请求分离管理装置，其特征在于，所述装置应用于存储服务器，所述装置包括：

接收单元，用于接收至少一个客户端请求；

第一分离单元，用于将所述客户端请求分离存放到不同的软件层session中，以便所述不同的session分别将各自存储的客户端请求发送至对应的元数据服务器。

7.根据权利要求6所述的装置，其特征在于，所述session分布在所述存储服务器的客户端中；所述存储服务器为分布式文件系统。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二分离单元，用于将客户端已处理过的客户端请求的标识分离存放到对应的session中；

记录单元，用于通过所述不同的session记录所述自身已处理过的客户端请求的标识。

9.根据权利要求6-8任一项所述的装置，其特征在于，所述装置还包括：

判断单元，用于判断是否出现卸载unmount情况，所述unmount情况包括所述存储服务器的客户端不提供服务的情况；

删除单元，用于若出现卸载unmount情况，则删除所述session。

10.根据权利要求6-8任一项所述的装置，其特征在于，所述装置还包括：

重启单元，用于在所述存储服务器的客户端被重置后，重新启动所述session。