CN110401724B - 文件管理方法、文件传输协议服务器及存储介质 - Google Patents

Abstract

本发明实施例提供一种文件管理方法、FTP服务器以及存储介质。该方法包括：接收FTP客户端发送的FTP请求；基于FTP请求对kafka系统中的消息执行相应操作，其中，FTP服务器上的FTP应用所配置的根目录下的文件夹一一对应地映射为kafka系统中的话题，根目录下的任一文件夹下的文件一一对应地映射为kafka系统中的与该文件夹相对应的话题下的消息；将操作结果返回FTP客户端。上述方法可以缩短传输链路，减少磁盘IO次数，从而可以降低故障概率，并且可以有效提高FTP系统的数据传输效率。

Description

文件管理方法、文件传输协议服务器及存储介质

技术领域

本发明涉及计算机领域，更具体地涉及一种文件管理方法、文件传输协议服务器以及存储介质。

背景技术

目前，在安防领域已广泛应用人脸识别技术来进行安防布控。在这种应用场景中，文件传输协议(FTP)应用常使用kafka系统中的消息作为数据来源。此外，FTP应用还具有自己的存储空间。FTP应用的存储空间在磁盘中分配。FTP应用所配置的根目录下的文件夹对应着存储空间中的同名文件夹，FTP根目录下的每个文件夹中的每个文件对应着存储空间中的同名文件。FTP服务器一端的FTP应用接收到FTP请求时，是针对存储空间中的文件执行操作，而无法针对kafka系统中的消息进行操作。因此，FTP服务器与FTP客户端之间传输数据的话，FTP服务器一端的FTP应用需要预先将待传输的文件从kafka系统中获取出来放到FTP应用的存储空间中。当FTP服务器接收到FTP客户端发送的与获取文件相关的FTP请求时，FTP服务器的FTP应用访问自己的存储空间，从中获取待传输的文件，并将待传输的文件传输到FTP客户端。FTP客户端的FTP应用将待传输的文件放到自己的存储空间中。

上述技术方案存在如下问题：

1、由于文件传输链条较长，出现故障的概率增加；

2、文件传输过程中需要多次写磁盘导致磁盘输入输出(IO)利用率不高，传输延迟较大。

发明内容

考虑到上述问题而提出了本发明。本发明提供了一种文件管理方法、FTP服务器以及存储介质。

根据本发明一方面，提供了一种文件管理方法，应用于FTP服务器。该方法包括：接收FTP客户端发送的FTP请求；基于FTP请求对卡夫卡(kafka)系统中的消息执行相应操作，其中，FTP服务器上的FTP应用所配置的根目录下的文件夹一一对应地映射为kafka系统中的话题，根目录下的任一文件夹下的文件一一对应地映射为kafka系统中的与该文件夹相对应的话题下的消息；将操作结果返回FTP客户端。

示例性地，FTP服务器包括消息缓存器，消息缓存器包括与kafka系统中的一个或多个话题一一对应的一个或多个话题存储空间，与任一话题对应的话题存储空间包括与该话题的一个或多个分区一一对应的一个或多个存储段，每个存储段用于缓存来自对应分区的消息。

示例性地，FTP请求是用于指示查看根目录下的文件夹信息的根目录列表请求，基于FTP请求对kafka系统中的消息执行相应操作包括：基于根目录列表请求启动消费者程序；利用消费者程序从kafka系统中获取所有话题的标识信息；其中，操作结果包括所有话题的标识信息。

示例性地，FTP服务器包括话题缓存器，在基于根目录列表请求启动消费者程序之前，基于FTP请求对kafka系统中的消息执行相应操作还包括：响应于根目录列表请求的接收，在话题缓存器中查找用于记录所有话题的标识信息的封装文件；如果封装文件存在，则从封装文件中提取所有话题的标识信息，以获得操作结果，其中，基于根目录列表请求启动消费者程序的步骤在封装文件不存在的情况下执行；在利用消费者程序从kafka系统中获取所有话题的标识信息之后，基于FTP请求对kafka系统中的消息执行相应操作还包括：将所有话题的标识信息封装成封装文件，并将封装文件缓存在话题缓存器中。

示例性地，FTP请求是用于指示查看根目录下的目标文件夹下的文件信息的文件夹列表请求，基于FTP请求对kafka系统中的消息执行相应操作包括：基于文件夹列表请求启动一个或多个消费者程序，一个或多个消费者程序与目标文件夹所对应的目标话题的一个或多个目标分区一一对应；对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息；其中，操作结果包括从一个或多个目标分区获取的消息的标识信息。

示例性地，在对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息之后，基于FTP请求对kafka系统中的消息执行相应操作还包括：对于一个或多个目标分区中的每个目标分区，将从该目标分区获取的消息缓存在消息缓存器中的对应存储段中。

示例性地，在基于文件夹列表请求启动一个或多个消费者程序以及对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息的过程中，基于FTP请求对kafka系统中的消息执行相应操作还包括：响应于当前时刻的文件夹列表请求的接收，遍历消息缓存器中与一个或多个目标分区相对应的一个或多个存储段；在遍历过程中，从一个或多个存储段中找出缓存有消息的特定存储段，并确定操作结果包括特定存储段当前缓存的消息的标识信息；对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息包括：在遍历过程中，对于一个或多个存储段中的任一存储段，如果该存储段未缓存消息，则利用该存储段的对应消费者程序从该存储段的对应分区中获取位于已消费消息位置之后的预定数量的消息，并将已消费消息位置更新为当前获取的最后一条消息的偏移地址。

示例性地，FTP请求是用于指示下载根目录下的目标文件夹下的目标文件的下载请求，基于FTP请求对kafka系统中的消息执行相应操作包括：基于下载请求获取与目标文件相对应的目标消息；其中，操作结果包括目标消息。

示例性地，基于下载请求获取与目标文件相对应的目标消息包括：响应于下载请求的接收，启动消费者程序；利用消费者程序从kafka系统中获取目标消息。

示例性地，基于下载请求获取与目标文件相对应的目标消息包括：响应于下载请求的接收，在消息缓存器中查询与目标文件夹相对应的目标话题存储空间；遍历目标话题存储空间中的存储段，以查询并获取目标消息。

示例性地，FTP请求是用于指示删除根目录下的目标文件夹下的目标文件的删除请求，基于FTP请求对kafka系统中的消息执行相应操作包括：响应于删除请求的接收，在消息缓存器中查询与目标文件夹相对应的目标话题存储空间；遍历目标话题存储空间中的存储段，以查询并删除与目标文件相对应的目标消息。

示例性地，FTP请求是用于指示将目标文件上传到根目录下的目标文件夹的上传请求，基于FTP请求对kafka系统中的消息执行相应操作包括：从上传请求中提取目标文件或接收FTP客户端发送的目标文件；基于上传请求启动生产者程序；利用生产者程序将目标文件作为对应消息存储到kafka系统中与目标文件夹相对应的目标话题下。

示例性地，FTP服务器包括文件缓存器，在基于上传请求启动生产者程序之前，基于FTP请求对kafka系统中的消息执行相应操作还包括：响应于上传请求，将目标文件缓存到文件缓存器，其中，启动生产者程序的步骤在缓存结束时执行；利用生产者程序将目标文件作为对应消息存储到kafka系统中与目标文件夹相对应的目标话题下包括：利用生产者程序将目标文件作为对应消息从文件缓存器存储到目标话题下。

示例性地，在基于FTP请求对kafka系统中的消息执行相应操作之前，方法还包括：对FTP请求进行解析，以确定FTP请求的类型，其中，FTP请求包括以下一种或多种：列表请求、下载请求、删除请求、上传请求，其中，列表请求包括根目录列表请求和/或文件夹列表请求。

根据本发明另一方面，提供了一种FTP服务器，包括：接收模块，用于接收FTP客户端发送的FTP请求；操作模块，用于基于FTP请求对kafka系统中的消息执行相应操作，其中，FTP服务器上的FTP应用所配置的根目录下的文件夹一一对应地映射为kafka系统中的话题，根目录下的任一文件夹下的文件一一对应地映射为kafka系统中的与该文件夹相对应的话题下的消息；返回模块，用于将操作结果返回FTP客户端。

根据本发明另一方面，提供了一种FTP服务器，包括处理器和存储器，其中，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器运行时用于执行上述文件管理方法。

根据本发明另一方面，提供了一种存储介质，在所述存储介质上存储了程序指令，所述程序指令在运行时用于执行上述文件管理方法。

根据本发明实施例的文件管理方法、FTP服务器以及存储介质，将FTP服务器的FTP应用中的文件夹映射为kafka系统中的话题，并将FTP应用中的文件映射为kafka系统中的消息，这样在执行FTP的相关操作时，可以直接针对kafka系统中的消息进行操作，而无需再经由FTP的存储空间才能对文件进行操作。上述文件管理方法可以缩短传输链路，减少磁盘IO次数，从而可以降低故障概率，并且可以有效提高FTP系统的数据传输效率。

附图说明

通过结合附图对本发明实施例进行更详细的描述，本发明的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与本发明实施例一起用于解释本发明，并不构成对本发明的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1示出用于实现根据本发明实施例的文件管理方法和FTP服务器的示例电子设备的示意性框图；

图2示出根据本发明一个实施例的文件管理方法的示意性流程图；

图3示出根据本发明一个实施例的FTP服务器和FTP客户端交互的示意图；

图4示出根据本发明一个实施例的消息缓存器的存储结构的示意图；

图5示出根据本发明一个实施例的FTP服务器接收到根目录列表请求时返回给FTP客户端的信息的示意图；

图6示出根据本发明一个实施例的FTP服务器接收到文件夹列表请求时返回给FTP客户端的信息的示意图；

图7示出了根据本发明一个实施例的FTP服务器的示意性框图；以及

图8示出了根据本发明一个实施例的FTP服务器的示意性框图。

具体实施方式

为了使得本发明的目的、技术方案和优点更为明显，下面将参照附图详细描述根据本发明的示例实施例。显然，所描述的实施例仅仅是本发明的一部分实施例，而不是本发明的全部实施例，应理解，本发明不受这里描述的示例实施例的限制。基于本发明中描述的本发明实施例，本领域技术人员在没有付出创造性劳动的情况下所得到的所有其它实施例都应落入本发明的保护范围之内。

为了至少部分解决上述问题，本发明实施例提供了一种文件管理方法、FTP服务器以及存储介质。根据本发明实施例的文件传输技术，可以缩短传输链路，减少磁盘IO次数，进而可以降低故障概率并且可以有效提高FTP系统的数据传输效率。根据本发明实施例的文件管理方法可以应用于任何FTP传输领域，包括但不限于同一网段内的FTP服务器和FTP客户端传输数据，或者不同网段内的FTP服务器和FTP客户端经由网闸跨网传输数据，等等。

首先，参照图1来描述用于实现根据本发明实施例的文件管理方法和FTP服务器的示例电子设备100。

如图1所示，电子设备100包括一个或多个处理器102、一个或多个存储装置104。可选地，电子设备100还可以包括输入装置106、输出装置108、以及通信装置110，这些组件通过总线系统112和/或其它形式的连接机构(未示出)互连。应当注意，图1所示的电子设备100的组件和结构只是示例性的，而非限制性的，根据需要，所述电子设备也可以具有其他组件和结构。

所述处理器102可以采用数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、微处理器中的至少一种硬件形式来实现，所述处理器102可以是中央处理单元(CPU)、图像处理器(GPU)、专用的集成电路(ASIC)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元中的一种或几种的组合，并且可以控制所述电子设备100中的其它组件以执行期望的功能。

所述存储装置104可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器102可以运行所述程序指令，以实现下文所述的本发明实施例中(由处理器实现)的客户端功能以及/或者其它期望的功能。在所述计算机可读存储介质中还可以存储各种应用程序和各种数据，例如所述应用程序使用和/或产生的各种数据等。

所述输入装置106可以是用户用来输入指令的装置，并且可以包括键盘、鼠标、麦克风和触摸屏等中的一个或多个。

所述输出装置108可以向外部(例如用户)输出各种信息(例如图像和/或声音)，并且可以包括显示器、扬声器等中的一个或多个。可选地，所述输入装置106和所述输出装置108可以集成在一起，采用同一交互装置(例如触摸屏)实现。

所述通信装置110可以与FTP客户端通信，以在电子设备100与FTP客户端之间传输数据(例如文件、请求等)。通信装置110可以包括有线网卡、无线网卡、网络线缆等中的一个或多个。

示例性地，用于实现根据本发明实施例的文件管理方法和FTP服务器的示例电子设备可以在诸如个人计算机或远程服务器等的设备上实现。

下面，将参考图2描述根据本发明实施例的文件管理方法。图2示出根据本发明一个实施例的文件管理方法200的示意性流程图。如图2所示，文件管理方法200包括以下步骤S210、S220和S230。

在步骤S210，接收FTP客户端发送的FTP请求。

本文描述的文件管理方法200可以是应用于FTP服务器的，该服务器可以是支持FTP的任意设备，例如安装有FTP服务器程序(即FTP服务器的FTP应用)的设备，该设备也可以是个人计算机、移动终端、服务器设备等。上述文件管理方法200可以理解为与FTP服务器程序所对应的方法。

FTP客户端可以是支持FTP的任意设备，例如安装有FTP客户端程序(即FTP客户端的FTP应用)的设备，该设备可以是个人计算机、移动终端、服务器设备、网闸等。FTP客户端和FTP服务器可以是相同类型的设备(例如都是个人计算机)，也可以是不同类型的设备(例如一个是个人计算机，一个是服务器设备)。

FTP服务器可以用于存储文件，其存储的文件可以由一个或多个FTP客户端共享。

当FTP客户端与FTP服务器建立连接之后，FTP客户端可以向FTP服务器发送FTP请求，以对FTP服务器上的文件进行访问、下载或者删除等操作或者向FTP服务器上传文件。

在步骤S220，基于FTP请求对kafka系统中的消息执行相应操作，其中，FTP服务器上的FTP应用所配置的根目录下的文件夹一一对应地映射为卡夫卡系统中的话题，根目录下的任一文件夹下的文件一一对应地映射为卡夫卡系统中的与该文件夹相对应的话题下的消息。

可选地，本文所述的kafka系统可以实现在独立于FTP服务器或FTP客户端的设备上。

如上所述，在现有技术中，FTP应用所配置的根目录(可以简称为FTP根目录)下的文件夹对应着存储空间的同名文件夹，FTP根目录下的每个文件夹中的每个文件则对应着存储空间中的同名文件。而根据本发明实施例，可以对FTP应用的目录结构进行适配，以使FTP应用的目录结构中的文件夹或文件不再对应存储空间中的同名文件夹或同名文件，而是对应kafka系统中的话题或消息。FTP应用的目录结构的适配方式如下：FTP服务器中“/”作为FTP根目录，该根目录下包括一个或多个文件夹，这些文件夹的名称是kafka系统里面的话题(topic)的名称。每个文件夹下的文件是kafka系统中对应话题下的消息(message)，每个消息代表FTP应用中的一个文件。

通过以上适配方式，可以使得FTP应用能够直接访问和操作kafka系统中的消息，即在利用FTP应用传输文件时，可以将kafka系统中的消息作为FTP应用的文件进行传输。这样，FTP应用可以无需将文件从kafka系统中获取到自己的存储空间再进行访问和传输，而是可以一步到位地访问和传输kafka系统中的消息。

示例性地，FTP请求可以包括列表(list)请求、下载(get)请求、删除(delete)请求和上传(put)请求中的一种或多种。示例性地，列表请求可以包括根目录列表请求和/或文件夹列表请求。当FTP服务器接收到FTP客户端发送的FTP请求时，可以首先对FTP请求进行解析，以确定FTP请求的类型，随后针对每种类型的FTP请求执行相应的操作。

列表请求是指关于查看FTP根目录下的文件夹信息或者FTP根目录下的某个文件夹下的文件信息的请求。例如，当FTP客户端的用户(下文简称用户)在FTP根目录下进行列表查询(list)时，可以启动消费者程序(kafka consumer)去kafka系统里面获取(fetch)所有话题的标识信息，并将所有话题的标识信息返回给FTP客户端。如果用户在根目录下的某个文件夹里面进行列表查询，则可以启动消费者程序去kafka系统里面获取该话题所对应的一个或多个分区(partition)里面的消息，将获取到的消息的标识信息返回给FTP客户端。

下载请求是指关于从FTP服务器下载某个文件的请求。当FTP客户端发起下载请求时，FTP服务器可以将所请求的文件对应的kafka消息发送给FTP客户端。

上传请求是指关于向FTP服务器上传某个文件的请求。当FTP客户端发起上传请求时，可以接收FTP客户端上传的文件内容，并可以启动一个生产者程序(kafka producer)来将接收到的文件内容存储到kafka系统的指定的话题中。

删除请求是指关于删除FTP服务器上的某个文件的请求。当FTP服务器接收到FTP客户端发出的删除请求时，可以从本地缓存(如本文所述的消息缓存器)中查询并删除需要删除的消息，或者可以向kafka系统发送删除指令，由kafka系统按照预设规则在合适的时间删除指定的消息。

在步骤S230，将操作结果返回FTP客户端。

FTP服务器可以将执行与FTP请求相对应的操作所获得的操作结果返回给FTP客户端。例如，当接收到的是根目录列表请求时，操作结果可以包括kafka系统中的所有话题的标识信息，即可以将kafka系统中的所有话题的标识信息返回给FTP客户端。又例如，当接收到的是文件夹列表请求时，操作结果可以包括目标文件夹所对应的目标话题中的至少部分消息的标识信息，即可以将该目标话题中的至少部分消息的标识信息返回给FTP客户端。又例如，当接收到的是下载请求时，操作结果可以包括与目标文件相对应的目标消息，即可以将该目标消息返回给FTP客户端。又例如，当接收到的是上传请求时，操作结果可以包括关于目标文件是否成功上传到FTP服务器的信息。又例如，当接收到的是删除请求时，操作结果可以包括关于目标文件是否成功删除的信息。

根据本发明实施例的文件管理方法，将FTP服务器的FTP应用中的文件夹映射为kafka系统中的话题，并将FTP应用中的文件映射为kafka系统中的消息，这样在执行FTP的相关操作时，可以直接针对kafka系统中的消息进行操作，而无需再经由FTP的存储空间才能对文件进行操作。上述文件管理方法可以缩短传输链路，减少磁盘IO次数，从而可以降低故障概率，并且可以有效提高FTP系统的数据传输效率。

附加地，根据本发明实施例，可以将FTP和kafka集成为同一服务，这样可以避免FTP和kafka之间的跨进程的数据同步，从而可以提高系统稳定性。

示例性地，根据本发明实施例的文件管理方法可以在具有存储器和处理器的设备、装置或者系统中实现。

根据本发明实施例的文件管理方法可以部署在个人终端处，诸如智能电话、平板电脑、个人计算机等。

根据本发明实施例，FTP服务器可以包括消息缓存器，消息缓存器包括与卡夫卡系统中的一个或多个话题一一对应的一个或多个话题存储空间，与任一话题对应的话题存储空间包括与该话题的一个或多个分区一一对应的一个或多个存储段，每个存储段用于缓存来自对应分区的消息。

属于同一个话题的消息可以分配到一个或多个分区中存储，本领域技术人员可以理解kafka系统中的话题与分区之间的关系，本文不做赘述。

图3示出根据本发明一个实施例的FTP服务器和FTP客户端交互的示意图。如图3所示，FTP服务器可以包括FTP应用模块，FTP应用模块可以包括消息缓存器。此外，FTP应用模块还可以包括请求解析模块。FTP客户端发起FTP请求之后，请求解析模块可以对接收到的FTP请求进行分析，判断其类型。消息缓存器可以作为中间缓存，用于缓存kafka系统中的一个或多个话题下的至少部分消息。FTP应用模块可以用于执行本文描述的文件管理方法200。

可选地，消息缓存器可以缓存来自kafka系统的消息和/或来自FTP客户端的文件等数据。例如，FTP应用模块可以将从kafka系统获取的消息暂时缓存在消息缓存器中，再将消息从消息缓存器取出并发送到FTP客户端。消息缓存器可以位于FTP服务器的内存中，采用消息缓存器缓存数据的方式可以有效提高数据传输的速度，尤其是在所传输的数据量较大时。

图4示出根据本发明一个实施例的消息缓存器的存储结构的示意图。如图4所示，消息缓存器针对每个话题分别分配一个话题存储空间，例如topic1、topic2、topic3等。此外，每个话题存储空间还划分为一个或多个存储段，如topic的segment1和segment2等。话题存储空间的每个存储段与kafka系统中的对应话题的一个分区对应。例如，在kafka系统中，存在一个话题topic1，该话题下的所有消息可以分别存储在两个分区partition1和partition2中。消息缓存器中topic1的segment1用于缓存来自partition1的消息，消息缓存器中topic1的segment2用于缓存来自partition2的消息。

示例性地，消息缓存器可以用于将每条消息转换为对应的文件进行缓存，每个文件的文件名包含对应消息在kafka系统中的键值(key)、分区号(partition ID)和偏移地址(offset)，每个文件的内容属性为对应消息的内容。

偏移地址也可以称为偏移量，本领域技术人员可以理解kafka系统中的消息的偏移量的含义和作用，本文不做赘述。如图4所示，kafka系统中的消息可以转换为文件，例如File1、File2等，缓存在消息缓存器中。可选地，kafka系统中的消息作为文件的规则为：将key+partition ID+offset作为文件名，将消息的内容作为文件的内容(content)属性。

根据本发明实施例，FTP请求是用于指示查看根目录下的文件夹信息的根目录列表请求，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)可以包括：基于根目录列表请求启动消费者程序；利用消费者程序从kafka系统中获取所有话题的标识信息；其中，操作结果包括所有话题的标识信息。

如上所述，在接收到根目录列表请求时，可以将kafka系统中的所有话题的标识信息返回给FTP客户端。

图5示出根据本发明一个实施例的FTP服务器接收到根目录列表请求时返回给FTP客户端的信息的示意图。图5所示的图是在FTP客户端的显示界面上所显示的图。用户可以在FTP客户端的显示界面上针对该图执行一些操作，例如点击某个文件夹的图标，FTP客户端可以相应生成文件夹列表请求并向FTP服务器发送该请求，以请求查看该文件夹下的文件信息。

当前图5所展示的是FTP服务器的根目录下的所有文件夹的标识信息，即kafka系统中的所有话题的标识信息。图5所示的根目录下共包括五个文件夹，即_consumer_offsets、default、NETGATE、NETGATE_OUTPUT和test1，这五个文件夹的名称分别是kafka系统中的五个话题的名称。

示例性地，话题的标识信息可以包括但不限于对应话题的名称、类型、最近修改时间、大小中的一项或多项。可选地，可以将FTP根目录下的每个文件夹的名称设定为kafka系统中的对应话题的名称(如图5所示)。

FTP服务器在接收到根目录列表请求时，可以启动消费者程序。该消费者程序可以从kafka系统中查询所有话题的标识信息。随后，FTP服务器可以将该标识信息返回FTP客户端，以在FTP客户端的显示界面上显示。

根据本发明实施例，FTP服务器包括话题缓存器，在基于根目录列表请求启动消费者程序之前，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)还可以包括：响应于根目录列表请求的接收，在话题缓存器中查找用于记录所有话题的标识信息的封装文件；如果封装文件存在，则从封装文件中提取所有话题的标识信息，以获得操作结果，其中，基于根目录列表请求启动消费者程序的步骤在封装文件不存在的情况下执行；在利用消费者程序从kafka系统中获取所有话题的标识信息之后，基于FTP请求对kafka系统中的消息执行相应操作还包括：将所有话题的标识信息封装成封装文件，并将封装文件缓存在话题缓存器中。

示例性地，话题缓存器与上述消息缓存器可以是同一缓存器，也可以是不同缓存器。话题缓存器可以位于FTP服务器的内存中。

可选地，FTP应用模块首次接收到FTP客户端的根目录列表请求时，可以启动一个消费者程序从kafka系统中获取所有话题的标识信息，并将这些标识信息封装成文件，缓存在话题缓存器中。当用户下次查看根目录，即FTP应用模块再次接收到根目录列表请求时，可以直接从话题缓存器中查询话题的标识信息，而无需再从kafka系统中查询。这种方案可以提高FTP系统的响应速度，提升用户体验。

上述采用话题缓存器的实施例仅是一种示例而非限制。在另一个示例中，话题缓存器可以省略。在这种情况下，FTP服务器每次接收到根目录列表请求时，直接利用消费者程序从kafka系统中查询所有话题，获得所有话题的标识信息并将所有话题的标识信息发送给FTP客户端。

根据本发明实施例，FTP请求是用于指示查看根目录下的目标文件夹下的文件信息的文件夹列表请求，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)可以包括：基于文件夹列表请求启动一个或多个消费者程序，一个或多个消费者程序与目标文件夹所对应的目标话题的一个或多个目标分区一一对应；对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息；其中，操作结果包括从一个或多个目标分区获取的消息的标识信息。

文件夹列表请求可以是，例如list/topic1，表示用户请求查看topic1这个文件夹下的文件信息。

需注意，本文所述的目标文件夹、目标话题、目标分区等术语仅为了方便描述，而不包含任何特殊含义，目标文件夹可以是FTP根目录下的任一文件夹，目标话题是与目标文件夹对应的话题，目标分区是与目标话题对应的分区。

如上所述，kafka系统中的每个话题下的消息可以分配到一个或多个分区中存储。每个分区可以对应一个消费者程序。例如，假设topic1划分为两个分区，则可以启动两个消费者程序分别到对应的分区中获取(即消费)消息。每个分区中的消息可以一次性全部消费完，也可以分批消费。例如，可以利用一个或多个消费者程序从一个或多个目标分区中一次性获取全部消息。又例如，可以利用一个或多个消费者程序从一个或多个目标分区中分批获取全部消息，每个消费者程序每次从对应的目标分区中获取部分消息直至获取完全部消息。又例如，可以利用一个或多个消费者程序从一个或多个目标分区中一次性获取或分批获取部分消息。在消息数量较大的情况下，采用分批获取的方案有利于提高数据的传输效率。

通过消费者程序消费消息之后，可以获得消息的标识信息，FTP服务器可以将这些标识信息返回给FTP客户端，以在FTP客户端的显示界面上显示。

根据本发明实施例，在对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息之后，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)还可以包括：对于一个或多个目标分区中的每个目标分区，将从该目标分区获取的消息缓存在消息缓存器中的对应存储段中。

上文已经描述了消息缓存器的存储结构，此处不再赘述。在一个示例中，消息缓存器的容量较大，可以选择一次性获取目标分区中的全部消息，并将这些消息缓存在对应存储段中。在另一个示例中，消息缓存器的容量有限，每个存储段的存储容量是固定的，此时可以每次从目标分区获取预定数量的消息并缓存在对应存储段中。

根据本发明实施例，在基于文件夹列表请求启动一个或多个消费者程序以及对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息的过程中，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)还可以包括：响应于当前时刻的文件夹列表请求的接收，遍历消息缓存器中与一个或多个目标分区相对应的一个或多个存储段；在遍历过程中，从一个或多个存储段中找出缓存有消息的特定存储段，并确定操作结果包括特定存储段当前缓存的消息的标识信息；对于一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息可以包括：在遍历过程中，对于一个或多个存储段中的任一存储段，如果该存储段未缓存消息，则利用该存储段的对应消费者程序从该存储段的对应分区中获取位于已消费消息位置之后的预定数量的消息，并将已消费消息位置更新为当前获取的最后一条消息的偏移地址。

如上所述，目标话题的一个或多个目标分区中的消息可以分批获取，在这种情况下，FTP客户端可以向FTP服务器多次发送针对目标文件夹的文件夹列表请求。每次接收到文件夹列表请求时，FTP应用模块可以遍历一次消息缓存器中与一个或多个目标分区相对应的一个或多个存储段，如果其中存在空的存储段则可以从对应分区中获取下一批消息缓存在该存储段中。同时，还可以从上述一个或多个存储段中找出缓存有消息的特定存储段，将该特定存储段中当前缓存的消息的标识信息返回给FTP客户端。

在一个示例中，与一个或多个目标分区相对应的一个或多个存储段是按照预定顺序排序的，特定存储段是排在先前已返回标识信息的存储段之后的存储段。在另一个示例中，特定存储段是与一个或多个目标分区相对应的一个或多个存储段中缓存有消息的任一存储段，其可以是随机选择的。

下面举例说明。例如，假设文件夹列表请求是list/topic1，kafka系统中的话题topic1共划分为5个分区，分别编号为partition1……partition5，在消息缓存器中相应分配有5个存储段，分别编号为segment1……segment5。此外，假设每个分区包括1000条消息。当首次接收到FTP客户端发送的list/topic1请求时，可以从partition1……partition5这五个分区中分别获取各自的前100条消息，共获得500条消息，并将从partition1……partition5获取的消息一一对应地缓存在segment1……segment5这五个存储段中。随后，可以首先将当前缓存在任一存储段(例如segment3)的100条消息的标识信息，或者直接将缓存在segment1(segment1……segment5依次排序)的100条消息的标识信息，发送到FTP客户端并在FTP客户端的显示界面上显示以供用户查看。

图6示出根据本发明一个实施例的FTP服务器接收到文件夹列表请求时返回给FTP客户端的信息的示意图。图6中用户选中的是NETGATE这个文件夹，显示的是kafka系统中NETGATE这一话题下的消息的标识信息。示例性地，任一消息的标识信息可以包括但不限于消息的名称、类型、最近修改日期、大小中的一项或多项。

在将当前的、标识信息返回至FTP客户端的某个存储段(例如segment1)的100条消息下载到FTP客户端之后，FTP应用模块可以再次接收针对目标文件夹的文件夹列表请求，将另一存储段(例如segment2)中缓存的100条消息的标识信息发送到FTP客户端，在FTP客户端的显示界面上显示。因此，FTP客户端的显示界面上显示的标识信息可以不断更新。此外，在将segment1的100条消息下载到FTP客户端之后，可以可选地将segment1中的100条消息删除。随后，在FTP应用模块下一次接收到文件夹列表请求且遍历每个存储段时，会发现segment1是空的，此时可以从kafka系统中获取partition1中的下一批，即第101-200条消息，并将获取的新的100条消息缓存在segment1中。其他分区中的消息的处理方式也是类似的，每次遍历存储段时，如果某一存储段中没有缓存消息，则可以从其对应分区中获取新的一批消息进行缓存。

示例性地，已消费消息位置是用于标记对应分区先前已消费到的消息的位置，例如，已消费消息位置可以是对应存储段上一批缓存的消息中的最后一条消息的偏移地址。在消费者程序消费消息时，kafka系统可以用消息的偏移地址来记录已消费到的消息。任一存储段每次从kafka系统获取新的一批消息时，可以通过已消费消息位置找到所需获取的消息。获取新的一批消息之后，还可以利用对应消费者程序记录新的已消费消息位置。

示例性地，在遍历过程中，对于一个或多个存储段中的任一存储段，如果该存储段未缓存消息，则利用该存储段的对应消费者程序从该存储段的对应分区中获取位于已消费消息位置之后的预定数量的消息包括：在遍历过程中，对于一个或多个存储段中的任一存储段，如果该存储段未缓存消息，则利用该存储段的对应消费者程序向kafka系统提交关于已消费消息位置的位置信息，例如先前获得的最后一条消息的offset，进而利用该存储段的对应消费者程序从kafka系统中获取位于已消费消息位置之后的预定数量的消息。

可以理解，在任意一次遍历过程中，任一存储段的对应分区中当前剩余的消息达到预定数量的情况下，可以获取并缓存预定数量的消息，任一存储段的对应分区中当前剩余的消息未达到预定数量的情况下，可以获取并缓存该分区中的全部剩余消息。

由于消息分段缓存在消息缓存器中，当某个存储段中的消息为空时，可以异步获取新一批的消息。这种方案可以大大提高数据传输的效率，减少响应时间。

根据本发明实施例，FTP请求是用于指示下载根目录下的目标文件夹下的目标文件的下载请求，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)可以包括：基于下载请求获取与目标文件相对应的目标消息；其中，操作结果包括目标消息。

下载请求可以是例如get/topic1/file1，表示FTP客户端需要下载文件夹topic1下的文件file1，即kafka系统中的话题topic1下的与file1对应的消息。在接收到下载请求时，FTP应用模块可以从kafka系统或上述消息缓存器中获取对应的消息并将其返回给FTP客户端。

在接收到上述文件夹列表请求，例如list/topic1之后，FTP服务器将若干消息的标识信息返回给FTP客户端，例如将消息缓存器中与topic1对应的话题存储空间下的segment1中的100条消息的标识信息返回给FTP客户端。随后，FTP客户端可以逐条发送下载请求，即依次发送get/topic1/file1,get/topic1/file2,……,get/topic1/file100。每接收到一条下载请求，FTP服务器即将对应的消息返回给FTP客户端，因此，FTP服务器可以依次将消息缓存器中的file1,file2,……,file100返回给FTP客户端。

示例性地，基于下载请求获取与目标文件相对应的目标消息可以包括：响应于下载请求的接收，启动消费者程序；利用消费者程序从卡夫卡系统中获取目标消息。

在不采用消息缓存器的情况下，每次接收到下载请求，FTP应用模块可以直接从kafka系统中获取所需的消息，并将该消息发送给FTP客户端。

示例性地，基于下载请求获取与目标文件相对应的目标消息可以包括：响应于下载请求的接收，在消息缓存器中查询与目标文件夹相对应的目标话题存储空间；遍历目标话题存储空间中的存储段，以查询并获取目标消息。

在采用消息缓存器的情况下，每次接收到下载请求，FTP应用模块可以从消息缓存器中获取所需的消息，并将该消息发送给FTP客户端。

例如，当接收到get/topic1/file1请求时，可以在消息缓存器中查询topic1这一目标话题存储空间，随后，可以遍历该存储空间的所有存储段，以查询file1这一消息。示例性地，可以利用字节数组输入流(ByteArrayInputStream)从消息缓存器中读取目标消息，并以字符串形式发送给FTP客户端。

根据本发明实施例，FTP请求是用于指示删除根目录下的目标文件夹下的目标文件的删除请求，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)可以包括：响应于删除请求的接收，在消息缓存器中查询与目标文件夹相对应的目标话题存储空间；遍历目标话题存储空间中的存储段，以查询并删除与目标文件相对应的目标消息。

删除请求可以是例如delete/topic1/file1，表示FTP客户端需要删除文件夹topic1下的文件file1，即kafka系统中的话题topic1下的与file1对应的消息。

示例性地，FTP客户端每次发送针对目标文件的下载请求并接收到FTP服务器返回的消息之后，可以随后发送针对该目标文件的删除请求。也就是说，FTP客户端每下载一条消息，即可以请求FTP服务器删除该消息。例如，FTP客户端可以依次发送以下请求：get/topic1/file1,delete/topic1/file1,get/topic1/file2,delete/topic1/file2,……,get/topic1/file100,delete/topic1/file100。

当FTP服务器接收到FTP客户端发送的删除请求时，可以在消息缓存器中查询目标话题存储空间，随后遍历该目标话题存储空间中的所有存储段，找到需要删除的消息将其从消息缓存器中删除。

操作结果可以包括关于目标文件是否成功删除的信息。在采用消息缓存器的情况下，可以将从消息缓存器中删除目标消息是否成功的信息返回给FTP客户端。

在不采用消息缓存器的情况下，FTP应用模块接收到删除请求之后，可以向kafka系统发送删除指令，以通知kafka系统删除目标消息。可选地，kafka系统可以响应于该删除指令删除目标消息。在这种情况下，可以将从kafka系统中删除目标消息是否成功的信息返回给FTP客户端。

在不采用消息缓存器的情况下，FTP应用模块接收到删除请求之后，可以向kafka系统发送上述删除指令，也可以不发送上述删除指令。可选地，kafka系统可以按照kafka系统的预设规则在合适的时刻删除目标消息。例如，kafka系统可以定期清理自己存储的消息，在此过程中，有可能删除目标消息。在这种情况下，FTP应用模块接收到删除请求之后，可以默认目标消息删除成功，并可以将该成功信息返回给FTP客户端。

根据本发明实施例，FTP请求是用于指示将目标文件上传到根目录下的目标文件夹的上传请求，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)可以包括：从上传请求中提取目标文件或接收FTP客户端发送的目标文件；基于上传请求启动生产者程序；利用生产者程序将目标文件作为对应消息存储到kafka系统中与目标文件夹相对应的目标话题下。

上传请求可以是例如put/topic1/file1，表示FTP客户端需要将其文件file1上传到FTP服务器的文件夹topic1下。

当接收到上传请求时，FTP服务器可以启动生产者程序，以将目标文件作为消息存储到kafka系统中。本领域技术人员可以理解生产者程序的实现方式，本文不做赘述。

根据本发明实施例，FTP服务器包括文件缓存器，在基于上传请求启动生产者程序之前，基于FTP请求对kafka系统中的消息执行相应操作(步骤S220)还可以包括：响应于上传请求，将目标文件缓存到文件缓存器，其中，启动生产者程序的步骤在缓存结束时执行；利用生产者程序将目标文件作为对应消息存储到kafka系统中与目标文件夹相对应的目标话题下包括：利用生产者程序将目标文件作为对应消息从文件缓存器存储到目标话题下。

文件缓存器与上述消息缓存器以及话题缓存器这三者可以分别是不同的缓存器，也可以其中的任意两者或三者是同一缓存器。

当接收到上传请求时，FTP服务器可以首先在文件缓存器中创建一个空的文件。并且，示例性地，FTP服务器可以使用字节数组输出流(ByteArrayOutputStream)接收FTP客户端上传的文件内容，并可以暂时将上传的目标文件的文件内容填充到在文件缓存器中所创建的文件中。当目标文件传输完毕后，可以调用ByteArrayOutputStream的Close方法。Close方法可以启动生产者程序来将接收到的文件内容作为消息存储到kafka系统的目标话题下。

下面结合图3-6描述FTP客户端和FTP服务器交互的一种示例性流程。首先，用户在FTP客户端上登录FTP应用后，可以直接或经由网闸等向FTP服务器发送根目录列表请求，FTP服务器中的FTP应用模块随即返回kafka系统中所有话题的标识信息，以由FTP客户端显示这些标识信息(参见图5)。用户点击任一文件夹之后，FTP客户端可以发出与该文件夹相关的文件夹列表请求，例如list/topic1(参见图3)。随后，FTP应用模块请求获取kafka系统中话题topic1下的消息，kafka系统将消息返回给FTP应用模块(即响应topic1下的消息)。假设topic1具有两个分区partition1和partition2，可以首先从topic1下获取这两个分区中的各前100条消息，分别缓存在消息缓存器中的话题存储空间topic1中的两个存储段segment1和segment2中(参见图4)。随后，FTP应用模块将segment1中的100条消息的标识信息返回给FTP客户端(即响应list/topic1请求)，以由FTP客户端显示这些标识信息(参见图6)。

随后，FTP客户端向FTP服务器发送下载请求get/topic1/file1，FTP应用模块从消息缓存器中查找对应的消息返回给FTP客户端。随后，FTP客户端向FTP服务器发送删除请求delete/topic1/file1，FTP应用模块删除消息缓存器中与file1对应的消息。FTP客户端不断循环发送get、delete这两个请求，直至将segment1中的100条消息全部下载完为止。此时FTP客户端的显示界面清空，没有显示消息的标识信息。此时，FTP客户端可以再次发送文件夹列表请求list/topic1，FTP应用模块将话题存储空间topic1中的segment2中的100条消息的标识信息返回给FTP客户端。与此同时，FTP应用模块还可以从kafka系统中获取partition1中的第101-200条消息并将新获取的100条消息缓存在segment1中。FTP客户端接收到segment2中的消息的标识信息之后，可以通过get、delete请求逐条下载并删除segment2中的消息。类似地，segment2中的消息下载完成之后，FTP客户端可以再次发送文件夹列表请求list/topic1，此时FTP应用模块可以返回segment1中缓存的新的100条消息的标识信息，并从kafka系统中获取partition2中的第101-200条消息并将新获取的100条消息缓存在segment2中。FTP客户端可以按照上述方式不断发送list、get、delete请求，直至将topic1下的消息全部下载完为止。

下面描述文件管理方法200的一种应用场景。如上所述，目前，在安防领域已广泛应用人脸识别技术来进行安防布控。人脸识别开发单位采用视频网提供人脸识别后台服务，安防系统采用内部的安防网进行工作。为保障安全，视频网和安防网之间可以经由网闸传输数据。视频网一端具有FTP服务器和对应的kafka系统，安防网一端也具有FTP服务器和对应的kafka系统，二者通过网闸(可以理解为FTP客户端)进行数据传输。视频网一端的kafka系统中新生产出数据后，数据会被转移到视频网一端的FTP服务器并将数据落盘存储在存储空间中，网闸不断发出数据摆渡请求，当网闸发现视频网的FTP服务器上有新数据后，先从视频网一端的FTP服务器下载数据，再向安防网一端的FTP服务器上传数据并落盘到安防网一端的FTP服务器的存储空间中，从而完成数据从视频网到安防网的摆渡。随后，安防网一端的FTP服务器作为生产者向安防网一端的kafka系统生产该数据。

按照现有技术，视频网一端监控某些场所的人脸数据，该人脸数据可以是例如可疑人员的人脸图像、身份信息、人脸特征等中的一种或多种。每当采集到新的人脸数据时，会在视频网一端的kafka系统中生产出一条新的人脸数据，该条人脸数据可以随即被转移到FTP服务器的FTP应用的存储空间中进行存储。人脸数据在kafka系统中作为消息存储，而转移到(磁盘上的)存储空间时，格式发生变化，存储空间中的人脸数据无法与kafka系统中的原始消息对应上。即FTP客户端能够查看到的是存储空间中的新格式的人脸数据，而不关心也无法找到其在kafka系统中的原始消息。

而采用本申请的文件管理方法，当接收到网闸发出的FTP请求时，视频网一端的FTP应用可以直接访问kafka系统中与FTP请求中包含的文件夹或文件具有映射关系的话题或消息，将其中的人脸数据直接或经由缓存器(参考上述消息缓存器)传输到网闸，并经由网闸传输到安防网一端并直接作为消息生产到公安网一端的kafka系统中，在视频网和安防网均无需在FTP应用存储空间落盘。这样可以缩短视频网和安防网之间的传输链路，减少磁盘IO次数，大大提高了传输速度。需理解，上述消息缓存器仅作暂时缓存之用，作用与磁盘不同，读取速度也比磁盘快得多。相应地，在安防网一端，同样可以将接收到的人脸数据直接或经由缓存器(参考上述文件缓存器)传输到kafka系统中进行存储，而忽略FTP应用的存储空间，这样可以进一步缩短视频网和公安网之间的传输链路，减少磁盘IO次数。此外，采用本申请提供的文件管理方案，从FTP客户端(例如所述网闸)的角度来看，其仍然可以执行与在现有技术中相同的操作，除了数据传输速度变快以外，FTP客户端感知不到变化。在经由网闸跨网传输的应用场景下，本发明实施例提供的文件传输方法200可以大大提高网闸摆渡的效率。

根据本发明另一方面，提供一种FTP服务器。图7示出了根据本发明一个实施例的FTP服务器700的示意性框图。

如图7所示，根据本发明实施例的FTP服务器700包括接收模块710、操作模块720和返回模块730。所述各个模块可分别执行上文中结合图2-6描述的文件管理方法的各个步骤/功能。以下仅对该FTP服务器700的各部件的主要功能进行描述，而省略以上已经描述过的细节内容。

接收模块710用于接收文件传输协议客户端发送的文件传输协议请求。接收模块710可以由图1所示的电子设备中的处理器102运行存储装置107中存储的程序指令来实现。

操作模块720用于基于文件传输协议请求对卡夫卡系统中的消息执行相应操作，其中，文件传输协议服务器上的文件传输协议应用所配置的根目录下的文件夹一一对应地映射为卡夫卡系统中的话题，根目录下的任一文件夹下的文件一一对应地映射为卡夫卡系统中的与该文件夹相对应的话题下的消息。操作模块720可以由图1所示的电子设备中的处理器102运行存储装置107中存储的程序指令来实现。

返回模块730用于将操作结果返回文件传输协议客户端。返回模块730可以由图1所示的电子设备中的处理器102运行存储装置107中存储的程序指令来实现。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

图8示出了根据本发明一个实施例的FTP服务器800的示意性框图。FTP服务器800包括存储装置(即存储器)810、以及处理器820。

所述存储装置810存储用于实现根据本发明实施例的文件管理方法中的相应步骤的计算机程序指令。

所述处理器820用于运行所述存储装置810中存储的计算机程序指令，以执行根据本发明实施例的文件管理方法的相应步骤。

在一个实施例中，所述计算机程序指令被所述处理器820运行时用于执行以下步骤：接收FTP客户端发送的FTP请求；基于FTP请求对Kafka系统中的消息执行相应操作，其中，FTP服务器上的FTP应用所配置的根目录下的文件夹一一对应地映射为Kafka系统中的话题，根目录下的任一文件夹下的文件一一对应地映射为Kafka系统中的与该文件夹相对应的话题下的消息；将操作结果返回FTP客户端。

此外，根据本发明实施例，还提供了一种存储介质，在所述存储介质上存储了程序指令，在所述程序指令被计算机或处理器运行时用于执行本发明实施例的文件管理方法的相应步骤，并且用于实现根据本发明实施例的FTP服务器中的相应模块。所述存储介质例如可以包括智能电话的存储卡、平板电脑的存储部件、个人计算机的硬盘、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、便携式紧致盘只读存储器(CD-ROM)、USB存储器、或者上述存储介质的任意组合。

在一个实施例中，所述程序指令在被计算机或处理器运行时可以使得计算机或处理器实现根据本发明实施例的FTP服务器的各个功能模块，并和/或者可以执行根据本发明实施例的文件管理方法。

在一个实施例中，所述程序指令在运行时用于执行以下步骤：接收FTP客户端发送的FTP请求；基于FTP请求对Kafka系统中的消息执行相应操作，其中，FTP服务器上的FTP应用所配置的根目录下的文件夹一一对应地映射为Kafka系统中的话题，根目录下的任一文件夹下的文件一一对应地映射为Kafka系统中的与该文件夹相对应的话题下的消息；将操作结果返回FTP客户端。

根据本发明实施例的FTP服务器中的各模块可以通过根据本发明实施例的实施文件管理的电子设备的处理器运行在存储器中存储的计算机程序指令来实现，或者可以在根据本发明实施例的计算机程序产品的计算机可读存储介质中存储的计算机指令被计算机运行时实现。

尽管这里已经参考附图描述了示例实施例，应理解上述示例实施例仅仅是示例性的，并且不意图将本发明的范围限制于此。本领域普通技术人员可以在其中进行各种改变和修改，而不偏离本发明的范围和精神。所有这些改变和修改意在被包括在所附权利要求所要求的本发明的范围之内。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个设备，或一些特征可以忽略，或不执行。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本发明并帮助理解各个发明方面中的一个或多个，在对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该本发明的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如相应的权利要求书所反映的那样，其发明点在于可以用少于某个公开的单个实施例的所有特征的特征来解决相应的技术问题。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域的技术人员可以理解，除了特征之间相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的FTP服务器中的一些模块的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

以上所述，仅为本发明的具体实施方式或对具体实施方式的说明，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。本发明的保护范围应以权利要求的保护范围为准。

Claims (16)

1.一种文件管理方法，应用于文件传输协议服务器，所述方法包括：

接收文件传输协议客户端发送的文件传输协议请求；

基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作，其中，所述文件传输协议服务器上的文件传输协议应用所配置的根目录下的文件夹一一对应地映射为所述卡夫卡系统中的话题，所述根目录下的任一文件夹下的文件一一对应地映射为所述卡夫卡系统中的与该文件夹相对应的话题下的消息；

将操作结果返回所述文件传输协议客户端；

其中，在所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作之前，所述方法还包括：

对所述文件传输协议请求进行解析，以确定所述文件传输协议请求的类型，其中，所述文件传输协议请求包括以下一种或多种：列表请求、下载请求、删除请求、上传请求，其中，所述列表请求包括根目录列表请求和/或文件夹列表请求。

2.如权利要求1所述的方法，其中，所述文件传输协议服务器包括消息缓存器，所述消息缓存器包括与所述卡夫卡系统中的一个或多个话题一一对应的一个或多个话题存储空间，与任一话题对应的话题存储空间包括与该话题的一个或多个分区一一对应的一个或多个存储段，每个存储段用于缓存来自对应分区的消息。

3.如权利要求1或2所述的方法，其中，所述文件传输协议请求是用于指示查看所述根目录下的文件夹信息的根目录列表请求，所述基于所述文件传输协议请求对所述卡夫卡系统中的消息执行相应操作包括：

基于所述根目录列表请求启动消费者程序；

利用所述消费者程序从所述卡夫卡系统中获取所有话题的标识信息；

其中，所述操作结果包括所述所有话题的标识信息。

4.如权利要求3所述的方法，其中，所述文件传输协议服务器包括话题缓存器，

在所述基于所述根目录列表请求启动消费者程序之前，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作还包括：

响应于所述根目录列表请求的接收，在所述话题缓存器中查找用于记录所述所有话题的标识信息的封装文件；

如果所述封装文件存在，则从所述封装文件中提取所述所有话题的标识信息，以获得所述操作结果，其中，所述基于所述根目录列表请求启动消费者程序的步骤在所述封装文件不存在的情况下执行；

在所述利用所述消费者程序从所述卡夫卡系统中获取所有话题的标识信息之后，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作还包括：

将所述所有话题的标识信息封装成所述封装文件，并将所述封装文件缓存在所述话题缓存器中。

5.如权利要求1或2所述的方法，其中，所述文件传输协议请求是用于指示查看所述根目录下的目标文件夹下的文件信息的文件夹列表请求，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作包括：

基于所述文件夹列表请求启动一个或多个消费者程序，所述一个或多个消费者程序与所述目标文件夹所对应的目标话题的一个或多个目标分区一一对应；

对于所述一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息；

其中，所述操作结果包括从所述一个或多个目标分区获取的消息的标识信息。

6.如引用权利要求2的权利要求5所述的方法，其中，在对于所述一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息之后，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作还包括：

对于所述一个或多个目标分区中的每个目标分区，将从该目标分区获取的消息缓存在所述消息缓存器中的对应存储段中。

7.如权利要求6所述的方法，其中，在所述基于所述文件夹列表请求启动一个或多个消费者程序以及所述对于所述一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息的过程中，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作还包括：

响应于当前时刻的文件夹列表请求的接收，遍历所述消息缓存器中与所述一个或多个目标分区相对应的一个或多个存储段；

在遍历过程中，从所述一个或多个存储段中找出缓存有消息的特定存储段，并确定所述操作结果包括所述特定存储段当前缓存的消息的标识信息；

所述对于所述一个或多个目标分区中的每个目标分区，利用对应消费者程序从该目标分区中获取至少部分消息包括：

在遍历过程中，对于所述一个或多个存储段中的任一存储段，如果该存储段未缓存消息，则利用该存储段的对应消费者程序从该存储段的对应分区中获取位于已消费消息位置之后的预定数量的消息，并将所述已消费消息位置更新为当前获取的最后一条消息的偏移地址。

8.如权利要求1或2所述的方法，其中，所述文件传输协议请求是用于指示下载所述根目录下的目标文件夹下的目标文件的下载请求，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作包括：

基于所述下载请求获取与所述目标文件相对应的目标消息；

其中，所述操作结果包括所述目标消息。

9.如权利要求8所述的方法，其中，所述基于所述下载请求获取与所述目标文件相对应的目标消息包括：

响应于所述下载请求的接收，启动消费者程序；

利用所述消费者程序从所述卡夫卡系统中获取所述目标消息。

10.如引用权利要求2的权利要求8所述的方法，其中，所述基于所述下载请求获取与所述目标文件相对应的目标消息包括：

响应于所述下载请求的接收，在所述消息缓存器中查询与所述目标文件夹相对应的目标话题存储空间；

遍历所述目标话题存储空间中的存储段，以查询并获取所述目标消息。

11.如权利要求2所述的方法，其中，所述文件传输协议请求是用于指示删除所述根目录下的目标文件夹下的目标文件的删除请求，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作包括：

响应于所述删除请求的接收，在所述消息缓存器中查询与所述目标文件夹相对应的目标话题存储空间；

遍历所述目标话题存储空间中的存储段，以查询并删除与所述目标文件相对应的目标消息。

12.如权利要求1或2所述的方法，其中，所述文件传输协议请求是用于指示将目标文件上传到所述根目录下的目标文件夹的上传请求，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作包括：

从所述上传请求中提取所述目标文件或接收所述文件传输协议客户端发送的所述目标文件；

基于所述上传请求启动生产者程序；

利用所述生产者程序将所述目标文件作为对应消息存储到所述卡夫卡系统中与所述目标文件夹相对应的目标话题下。

13.如权利要求12所述的方法，其中，所述文件传输协议服务器包括文件缓存器，

在所述基于所述上传请求启动生产者程序之前，所述基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作还包括：

响应于所述上传请求，将所述目标文件缓存到所述文件缓存器，其中，启动所述生产者程序的步骤在缓存结束时执行；

所述利用所述生产者程序将所述目标文件作为对应消息存储到所述卡夫卡系统中与所述目标文件夹相对应的目标话题下包括：

利用所述生产者程序将所述目标文件作为对应消息从所述文件缓存器存储到所述目标话题下。

14.一种文件传输协议服务器，包括：

接收模块，用于接收文件传输协议客户端发送的文件传输协议请求；

操作模块，用于基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作，其中，所述文件传输协议服务器上的文件传输协议应用所配置的根目录下的文件夹一一对应地映射为所述卡夫卡系统中的话题，所述根目录下的任一文件夹下的文件一一对应地映射为所述卡夫卡系统中的与该文件夹相对应的话题下的消息；

返回模块，用于将操作结果返回所述文件传输协议客户端；

其中，所述文件传输协议服务器还包括：

解析模块，用于在所述操作模块基于所述文件传输协议请求对卡夫卡系统中的消息执行相应操作之前，对所述文件传输协议请求进行解析，以确定所述文件传输协议请求的类型，其中，所述文件传输协议请求包括以下一种或多种：列表请求、下载请求、删除请求、上传请求，其中，所述列表请求包括根目录列表请求和/或文件夹列表请求。

15.一种文件传输协议服务器，包括处理器和存储器，其中，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器运行时用于执行如权利要求1至13任一项所述的文件管理方法。

16.一种存储介质，在所述存储介质上存储了程序指令，所述程序指令在运行时用于执行如权利要求1至13任一项所述的文件管理方法。

Images