客户端访问文件系统的方法、系统、装置及存储介质与流程

本发明涉及计算机领域，特别是涉及一种客户端访问文件系统的方法、系统、装置及计算机可读存储介质。

背景技术：

目前，基于smb协议处理客户端与服务器之间的信息沟通的机制都是单线程队列机制，即将客户端的smb请求排成队列，单线程依次处理队列中的请求，只有当处理完一个请求后，才能处理下一个请求。这种机制对于外部访问来说就相当于一根独木桥，任何请求都只能单线程通过，这样在队列中的请求较多，或者当前正在处理的请求处理时间较长的情况下，后续的请求等待时间较长，不仅给用户不好的体验，还有可能造成请求数据丢失。例如，在视频监控场景中，会造成单路视频io响应超时，从而被踢出队列，导致该路视频数据的丢失。

因此，如何提高客户端与服务器之间的通信效率，避免因等待时间过长而造成的请求数据丢失，是本领域技术人员需要解决的技术问题。

技术实现要素：

本发明的目的是提供一种客户端访问文件系统的方法、系统、装置及计算机可读存储介质，用于提高客户端和服务器之间的通信效率，避免因等待时间过长而造成的请求数据丢失。

为解决上述技术问题，本发明提供一种客户端访问文件系统的方法，包括：

接收客户端发送的smb请求，并按照时间先后顺序将所述smb请求排进主线程的请求队列；

将所述主线程的请求队列中的smb请求中的访问任务分发至工作线程以处理所述访问任务。

可选地，所述处理所述访问任务具体为：

所述工作线程接收到所述访问任务后，分析所述访问任务中要访问的文件系统，生成相应的文件系统接口调用指令；

所述工作线程将所述文件系统接口调用指令发送至相应的文件系统接口，以调用所述文件系统接口，并通过所述文件系统接口完成所述访问任务。

可选地，所述通过所述文件系统接口完成所述访问任务具体包括：

检查预设时间内所述文件系统接口的缓存是否命中所述访问任务的数据；

若命中，则所述访问任务完成；

若未命中，则创建osd请求，将所述osd请求通过所述文件系统接口发送至所述文件系统以完成所述访问任务。

可选地，所述将所述主线程的请求队列中的smb请求分发至工作线程，具体为：

将所述主线程的请求队列中的smb请求以轮询的方式分发至所述工作线程。

可选地，所述将所述主线程的请求队列中的smb请求分发至工作线程，具体为：

将所述主线程的请求队列中的smb请求以文件绑定的方式分发至所述工作线程。

可选地，在所述任务完成后，还包括：

所述文件系统通过所述工作线程向所述客户端返回应答消息。

可选地，还包括：

当所述应答消息的数量大于等于阈值时，打开流控开关以停止将所述smb请求排进所述主线程的请求队列；

相应的，当所述应答消息的数量小于所述阈值后，关闭所述流控开关。

为解决上述技术问题，本发明提供一种客户端访问文件系统的装置，包括：

存储器，用于存储客户端访问文件系统的程序；

处理器，用于执行所述程序时实现如上述任一项所述的客户端访问文件系统的方法的步骤。

为解决上述技术问题，本发明提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述任一项所述的客户端访问文件系统的方法的步骤。

本发明所提供的客户端访问文件系统的方法，包括接收客户端发送的smb请求，按时间先后顺序将smb请求排进主线程的请求队列；将主线程的请求队列中的smb请求中的访问任务分发至工作线程以处理访问任务。相比于现有技术中的单线程处理机制，本发明提供的方法通过将访问任务分发给多个工作线程，实现了同时处理多个访问任务，这大大提高了客户端访问文件系统的效率，避免因等待时间过长而造成的请求数据丢失，从而优化了用户体验。本发明提供的客户端访问文件系统的系统、装置及计算机可读存储介质同样具有上述有益效果，因此不再赘述。

附图说明

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

图1为本发明实施例提供的第一种客户端访问文件系统的方法的流程图；

图2为本发明实施例提供的一种步骤s11中处理访问任务的对应的流程图；

图3为本发明实施例提供的一种步骤s21中通过文件系统接口完成访问任务对应的流程图；

图4为本发明实施例提供的第二种客户端访问文件系统的方法的流程图；

图5为本发明实施例提供的第三种客户端访问文件系统的方法的流程图；

图6为本发明实施例提供的一种客户端访问文件系统的系统的示意图；

图7为本发明实施例提供的一种客户端访问文件系统的装置的示意图。

具体实施方式

本发明的核心是提供一种客户端和服务器之间的通信方法、系统、装置及计算机可读存储介质，用于提高客户端和服务器之间的通信效率，避免因等待时间过长而造成的请求数据丢失。

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

图1为本发明实施例提供的第一种客户端访问文件系统的方法的流程图。如图1所示，客户端访问文件系统的方法包括：

s10：接收客户端发送的smb请求，并按照时间先后顺序将smb请求排进主线程的请求队列。

s11：将主线程的请求队列中的smb请求中的访问任务分发至工作线程以处理访问任务。

由于在现有技术中，基于smb协议处理客户端与服务器之间的信息沟通的机制都是单线程队列机制，即将客户端的smb请求排成队列，单线程依次处理队列中的请求，只有当处理完一个请求后，才能处理下一个请求，这种机制造成了smb请求等待时间过长的问题，因此本发明实施例提供的方法在原有的主线程的请求队列的基础上，增加了多个工作线程，相当于增加了处理请求的通道。

在具体实施中，对于步骤s10来说，先启动smb服务，当接收到客户端的smb请求时，按照smb请求产生的时间先后的顺序将smb请求排进主线程的请求队列，并从内存的现有进程中复制一份新进程，初始化io线程池；主线程解析客户端的smb请求的数据报文，在将数据报文解析为smb2请求时，按类型分发请求。

对于步骤s11来说，这里的每个工作线程的工作模式相当于现有技术中的单线程，只有当处理完一个请求后，才能处理下一个请求，且具有自己独立的请求队列。主线程处理smb服务请求，循环处理客户端发送的smb请求中和客户端相关的数据，读取数据报文；若解析数据报文得到用于访问文件系统的smb2请求后，解析该smb2请求中的参数类型，如建立会话、认证、读、写、读属性、写属性等，从而得到了该smb2请求中的访问任务(可能是读任务、写任务或者读写任务)，启动读写请求处理过程处理该访问任务，在该过程中创建smb读/写请求，并可以绑定对该请求的应答处理，即向被访问的文件系统索要对smb读/写请求的应答；主线程创建一个分发请求，该分发请求关联异步处理控制块，该异步处理控制块中包含了上述访问任务，该访问任务的内容包括smb读/写请求，要访问的文件系统，还可能包括要分发的工作线程和索要应答的请求，然后将这个异步处理控制块按分发策略分发至工作线程。这里对分发策略不做限定。工作线程获取异步处理控制块中的访问任务后，将访问任务排进自己的请求队列，并依次处理访问任务。

本发明实施例所提供的客户端访问文件系统的方法，包括接收客户端发送的smb请求，并按照时间先后顺序将smb请求排进主线程的请求队列；将主线程的请求队列中的smb请求中的访问任务分发至工作线程以处理访问任务。相比于现有技术中的单线程处理机制，本发明实施例提供的方法通过将访问任务分发至多个工作线程，实现了同时处理多个访问任务，这大大提高了客户端访问文件系统的效率，避免因等待时间过长而造成的请求数据丢失，从而优化了用户体验。

图2为本发明实施例提供的一种步骤s11中处理访问任务的对应的流程图。如图2所示，在上述具体实施例的基础上，在另一实施例中，步骤s11中，处理访问任务具体包括：

s20：工作线程接收到访问任务后，分析访问任务中要访问的文件系统，生成相应的文件系统接口调用指令。

s21：工作线程将文件系统接口调用指令发送至相应的文件系统接口，以调用文件系统接口，并通过文件系统接口完成访问任务。

在具体实施中，对于步骤s20来说，上一个实施例中已经提到，工作线程依次处理访问任务，该访问任务的内容包括要访问的文件系统，因此工作线程处理该访问任务，首先要分析访问任务中要访问的文件系统，然后生成相应的文件系统接口调用指令，文件调用指令中可以包括客户端的信息以及访问任务中的具体内容。

对于步骤s21来说，工作线程将文件系统接口调用指令发送至相应的文件系统接口，建立客户端与该文件系统的连接，从而实现客户端对服务器的访问，完成访问任务。

图3为本发明实施例提供的一种步骤s21中通过文件系统接口完成访问任务对应的流程图。如图3所示，在上述具体实施例的基础上，在另一实施例中，步骤s21中通过文件系统接口完成访问任务具体包括：

s30：检查预设时间内文件系统接口的缓存是否命中访问任务的数据，若命中，则进入步骤s31；若未命中，则进入步骤s32。

s31：访问任务完成。

s32：创建osd请求，将osd请求通过文件系统接口发送至对应的文件系统，从而完成访问任务。

需要说明的是，在步骤s30中，若未命中，则执行步骤s32，直至任务完成；若命中，则说明访问任务完成；因此，执行完步骤s32相当于进入了步骤s31。

在具体实施中，预设时间可以是用户设置的，也可以是系统默认设置。若文件系统接口的缓存命中任务的数据，文件系统即可在缓存中获取该数据；若未命中，需要通过osd请求直接建立客户端与文件系统的连接，从而完成访问任务。在这个过程中，对客户端来说是感觉不到延时的。

本发明实施例提供的客户端访问文件系统的方法，针对工作线程与文件系统接口建立连接时可能会遇到的不同情况设置了不同的策略，因此可以应对不同情况，使用户的访问体验更加流畅。

在上述具体实施例的基础上，在另一实施例中，步骤s11中的将主线程的请求队列中的smb请求分发至工作线程具体为：

将主线程的请求队列中的smb请求以轮询的方式分发至工作线程。

本实施例提供了一种主线程的分发策略，将主线程的请求队列中的smb请求以轮询的方式分发至工作线程，即将主线程的请求队列中的smb请求按一定顺序平均地分发至各工作线程。

在上述具体实施例的基础上，在另一实施例中，步骤s11中的将主线程的请求队列中的smb请求分发至工作线程具体为：

将主线程的请求队列中的smb请求以文件绑定的方式分发至工作线程。

本实施例提供了另一种主线程的分发策略，将主线程的请求队列中的smb请求以文件绑定的方式分发至工作线程，即可以设定某个工作线程用于处理某一类请求，将主线程的请求队列中的这一类请求分发至这个设定的工作线程。

图4为本发明实施例提供的第二种客户端访问文件系统的方法的流程图。如图4所示，在本发明实施例提供的第一种客户端访问文件系统的方法的基础上，客户端访问文件系统的方法还包括：

s40：在访问任务完成后，文件系统向客户端返回应答消息。

需要说明的是，仅在一次客户端访问文件系统的访问任务中，步骤s40是最后执行的。

在具体实施中，为了使整个通信流程更加流畅，在访问任务完成后，文件系统向客户端返回应答消息。而且，如果访问任务的内容中包括索要应答的请求，在访问任务完成后，更需要文件系统接口返回应答消息。在访问任务完成后，工作线程将异步处理控制块返回至主线程，主线程将新的访问任务写入该异步处理控制块，并启动应答处理任务，将应答消息返回至客户端。

本发明实施例提供的客户端访问文件系统的方法，通过在任务完成后，文件系统向客户端返回应答消息，方便客户端进行后续的操作。

图5为本发明实施例提供的第三种客户端访问文件系统的方法的流程图。如图5所示，在本发明实施例提供的第二种客户端访问文件系统的方法的基础上，客户端访问文件系统的方法还包括：

s50：当应答消息的数量大于等于阈值时，打开流控开关以停止将smb请求排进主线程的请求队列；相应的，当应答消息的数量小于阈值后，关闭流控开关。

需要说明的是，步骤s50与其他步骤没有顺序关系。

为了防止来自客户端的smb请求和来自文件系统的应答消息堵塞在请求队列中，可以根据主线程和工作线程的处理速度设置应答消息的数量的阈值，并启动一个监控任务用于监控应答消息的数量，在应答消息的数量超出阈值时打开流控开关，在应答消息的数量降低到阈值以下时关闭流控开关，继续接收来自客户端的smb请求。

本发明实施例提供的客户端访问文件系统的方法，通过流控开关控制客户端的smb请求进入主线程的请求队列，可以保证系统处理不过载，进而提升系统的可靠性、稳定性与数据流畅。

上文详述了客户端访问文件系统的方法对应的各个实施例，在此基础上，本发明还公开了与上述方法对应的系统。

图6为本发明实施例提供的一种客户端访问文件系统的系统的示意图。如图6所示，客户端访问文件系统的系统包括：

接收单元601，用于接收客户端发送的smb请求，并按照时间先后顺序将smb请求排进主线程的请求队列中；

异步处理控制单元602，用于将主线程的请求队列中的smb请求中的访问任务分发至工作线程以处理访问任务。

由于系统部分的实施例与方法部分的实施例相互对应，因此系统部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本发明实施例所提供的客户端访问文件系统的系统，包括接收单元，用于接收客户端发送的smb请求，并按照时间先后顺序将smb请求排进主线程的请求队列中；异步处理控制单元，用于将主线程的请求队列中的smb请求中的访问任务分发至工作线程以处理访问任务。相比于现有技术中的单线程处理机制，本发明提供的系统通过将主线程的请求队列中的smb请求分发至多个工作线程，实现了同时处理多个请求，这大大提高了客户端访问文件系统的效率，避免因等待时间过长而造成的请求数据丢失，从而优化了用户体验。

上文详述了客户端访问文件系统的方法及系统对应的各个实施例，在此基础上，本发明还公开了与上述方法对应的装置。

图7为本发明实施例提供的一种客户端访问文件系统的装置的示意图。如图7所示，客户端访问文件系统的装置700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessingunits，cpu)710(例如，一个或一个以上处理器)和存储器720，一个或一个以上存储应用程序733或数据732的存储介质730(例如一个或一个以上海量存储设备)。其中，存储器720和存储介质730可以是短暂存储或持久存储。存储在存储介质730的程序可以包括一个或一个以上单元(图示没标出)，每个单元可以包括对客户端访问文件系统的装置700中的一系列指令操作。更进一步地，处理器710可以设置为与存储介质730通信，在客户端访问文件系统的装置700上执行存储介质730中的一系列指令操作。

客户端访问文件系统的装置700还可以包括一个或一个以上电源740，一个或一个以上有线或无线网络接口750，一个或一个以上输入输出接口760，和/或，一个或一个以上操作系统731，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。

上述图1至图5所描述的软件性能测试的方法中的步骤由装置基于该图7所示的结构实现。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置及计算机可读存储介质的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法、系统、装置及计算机可读存储介质，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，功能调用装置，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

以上对本发明所提供的一种客户端访问文件系统的方法、系统、装置及计算机可读存储介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

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