CN110287159B - 一种文件处理方法及装置 - Google Patents

Abstract

本申请公开一种文件处理方法及装置，所述方法包括：监听FTP目录中是否有新增文件，若有新增文件，则判断是否有空闲的处理器资源；若有空闲的处理器资源，则将所述新增文件作为待处理文件移入所述处理器资源对应的文件夹，并将所述待处理文件的文件名、所述处理器资源的编号以及所述待处理文件的处理状态存入数据库中；创建一个子任务利用所述处理器资源对所述待处理文件进行处理，并将处理结果推送至Kafka服务器。

Description

一种文件处理方法及装置

技术领域

本申请涉及一种文件处理方法及装置。

背景技术

Nodejs是单线程服务器技术，同一时刻只能处理一个文件，处理效率较低。如果用户端并发上传数据量巨大，那么就会造成服务器处理数据处理不过来，处理任务堵塞，导致服务器磁盘堆满，服务器故障等问题。

而在一些场景下，与某些第三方***的信息交互过程中，往往是以文件形式进行数据交互的。所以需要服务器具有很强的并发文件处理能力，但是由于Nodejs是单线程的，因此不具备并行处理能力。

发明内容

为解决上述技术问题，本申请实施例提供了一种文件处理方法及装置。

本申请实施例提供的文件处理方法，包括：

监听FTP目录中是否有新增文件，若有新增文件，则判断是否有空闲的处理器资源；

若有空闲的处理器资源，则将所述新增文件作为待处理文件移入所述处理器资源对应的文件夹，并将所述待处理文件的文件名、所述处理器资源的编号以及所述待处理文件的处理状态存入数据库中；

创建一个子任务利用所述处理器资源对所述待处理文件进行处理，并将处理结果推送至Kafka服务器。

在一实施方式中，所述监听FTP目录中是否有新增文件，若有新增文件，则判断是否有空闲的处理器资源，包括：

Watch模块定时轮训FTP目录，以查看FTP目录中是否有新增文件，若有新增文件，则所述Watch模块将所述新增文件的文件名传递给调度模块；

所述调度模块收到所述新增文件的文件名后是否有空闲的处理器资源。

在一实施方式中，所述将所述新增文件作为待处理文件移入所述处理器资源对应的文件夹，包括：

调度模块判断是否存在所述处理器资源对应的文件夹；若不存在，则创建所述处理器资源对应的文件夹，并将所述待处理文件存入该文件夹；若存在，则直接将所述待处理文件存入该文件夹；

其中，所述处理器资源对应的文件夹的文件夹名包含所述处理器资源的编号。

在一实施方式中，所述创建一个子任务利用所述处理器资源对所述待处理文件进行处理，包括：

调度模块通过Fork启动子任务，并将所述待处理文件的文件名和所述处理器资源的编号传入所述子任务中；

所述子任务启动后根据所述待处理文件的文件名和所述处理器资源的编号，获取需要处理的文件路径，并更新所述数据库中所述待处理文件的处理状态为处理中，而后开始对所述待处理文件进行解析。

在一实施方式中，所述方法还包括：

所述子任务成功处理结束后，更新所述数据库中所述待处理文件的处理状态为已结束，并将处理过的文件移入已处理文件夹。

本申请实施例提供的文件处理装置，包括：

Watch模块，用于监听FTP目录中是否有新增文件；

调度模块，用于若有新增文件，则判断是否有空闲的处理器资源；若有空闲的处理器资源，则将所述新增文件作为待处理文件移入所述处理器资源对应的文件夹，并将所述待处理文件的文件名、所述处理器资源的编号以及所述待处理文件的处理状态存入数据库中；创建一个子任务利用所述处理器资源对所述待处理文件进行处理，并将处理结果推送至Kafka服务器。

在一实施方式中，所述Watch模块，用于定时轮训FTP目录，以查看FTP目录中是否有新增文件，若有新增文件，则将所述新增文件的文件名传递给调度模块；

所述调度模块，用于收到所述新增文件的文件名后是否有空闲的处理器资源。

在一实施方式中，所述调度模块，用于判断是否存在所述处理器资源对应的文件夹；若不存在，则创建所述处理器资源对应的文件夹，并将所述待处理文件存入该文件夹；若存在，则直接将所述待处理文件存入该文件夹；其中，所述处理器资源对应的文件夹的文件夹名包含所述处理器资源的编号。

在一实施方式中，所述调度模块，用于通过Fork启动子任务，并将所述待处理文件的文件名和所述处理器资源的编号传入所述子任务中；所述子任务启动后根据所述待处理文件的文件名和所述处理器资源的编号，获取需要处理的文件路径，并更新所述数据库中所述待处理文件的处理状态为处理中，而后开始对所述待处理文件进行解析。

在一实施方式中，所述调度模块，用于所述子任务成功处理结束后，更新所述数据库中所述待处理文件的处理状态为已结束，并将处理过的文件移入已处理文件夹。

本申请实施例的技术方案，提高了Nodejs的处理能力以及充分利用服务器硬件资源，通过Nodejs的Cluster函数库，以及增加调度器模块为nodejs提供并行处理能力，从而充分利用服务器资源，提高了处理效率。另一方面，避免了由于服务器处理能力不足导致待处理文件堆积，磁盘空间不足，从而服务中断等问题。

附图说明

图1为本申请实施例提供的文件处理方法的流程示意图；

图2为本申请实施例提供的基于Nodejs的文件处理架构图；

图3为本申请实施例提供的文件处理装置的结构组成示意图。

具体实施方式

为便于理解本申请实施例的技术方案，以下对本申请实施例的相关技术进行说明。

在相关技术中，数据采集供应商通过文件传输协议(File Transfer Protocol，FTP)将采集数据以zip文件的形式推送到数据交换服务器；在数据交换服务器使用Nodejs程序对上传至数据交换服务器的zip文件进行解析以及解密，将处理解析后的数据结果推送到Kafka。

上述相关技术存在如下问题：1，Nodejs是单线程程序，虽然执行速度较Java快非常多，并且开发效率高，但是由于缺乏并行处理能力，提升数据处理能力手段有限，一旦数据量突然暴增，就会因为处理能力不足导致服务器耗尽磁盘，服务器宕机。2，由于其单线程特点，无法充分利用服务器多核CPU资源，造成资源浪费。3，单纯使用cluster集群的方案，由于所有进程并行执行，会导致资源抢占，任务队列同时处理同一个文件的情况产生，造成错误。4，如果采用锁机制进行分流处理的话，则锁会阻塞任务，造成性能下降。为解决上述问题，提出了本申请实施例的以下技术方案。

为了能够更加详尽地了解本申请实施例的特点与技术内容，下面结合附图对本申请实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本申请实施例。

图1为本申请实施例提供的文件处理方法的流程示意图，如图1所示，所述文件处理方法包括以下步骤：

步骤101：监听FTP目录中是否有新增文件，若有新增文件，则判断是否有空闲的处理器资源。

本申请实施例中，所述文件的格式可以是JSON文件。

本申请实施例中，所述监听FTP目录中是否有新增文件，若有新增文件，则判断是否有空闲的处理器资源，可以通过以下方式实现：

1)Watch模块定时轮训FTP目录，以查看FTP目录中是否有新增文件，若有新增文件，则所述Watch模块将所述新增文件的文件名传递给调度模块；

2)所述调度模块收到所述新增文件的文件名后是否有空闲的处理器资源。

这里，处理器资源包括但不局限于CPU资源。

这里，所述调度模块的功能通过Nodejs来实现，如所述调度模块为NodejsMaster。

步骤102：若有空闲的处理器资源，则将所述新增文件作为待处理文件移入所述处理器资源对应的文件夹，并将所述待处理文件的文件名、所述处理器资源的编号以及所述待处理文件的处理状态存入数据库中。

本申请实施例中，所述将所述新增文件作为待处理文件移入所述处理器资源对应的文件夹，可以通过以下方式实现：

调度模块判断是否存在所述处理器资源对应的文件夹；若不存在，则创建所述处理器资源对应的文件夹，并将所述待处理文件存入该文件夹；若存在，则直接将所述待处理文件存入该文件夹；

其中，所述处理器资源对应的文件夹的文件夹名包含所述处理器资源的编号。

步骤103：创建一个子任务利用所述处理器资源对所述待处理文件进行处理，并将处理结果推送至Kafka服务器。

本申请实施例中，所述创建一个子任务利用所述处理器资源对所述待处理文件进行处理，可以通过以下方式实现：

1)调度模块通过Fork启动子任务，并将所述待处理文件的文件名和所述处理器资源的编号传入所述子任务中；

2)所述子任务启动后根据所述待处理文件的文件名和所述处理器资源的编号，获取需要处理的文件路径，并更新所述数据库中所述待处理文件的处理状态为处理中，而后开始对所述待处理文件进行解析。

本申请实施例中，所述子任务成功处理结束后，更新所述数据库中所述待处理文件的处理状态为已结束，并将处理过的文件移入已处理文件夹。

为更加详尽了解本申请实施例的技术方案，以下结合具体示例对本申请实施例的技术方案进行详尽说明。

图2为本申请实施例提供的基于Nodejs的文件处理架构图，如图2所示，数据交换服务器包括FTP目录，客户端可以通过FTP将采集数据推送到数据交换服务器的FTP目录。在数据交换服务器中创建一个调度模块，即Nodejs Master模块(以下简称Master模块)，Master模块通过Watch模块(一个定时轮训文件夹的模块)去监听FTP目录是否有新增文件，如果有新增文件，那么判断是否有空闲CPU资源，如果有空闲CPU资源则将新增文件移入CPU对应编号的文件夹，同时将待处理文件名，CPU编号，处理状态存入数据库(Redis)中，并创建一个子进程对该文件进行处理，处理后推入Kafka服务器(或者是Kafka集群)中。通过此方案可以有效避免多任务请求同一个数据文件的情况，并且有效避免锁的使用，提升并行处理能力。

参照图2，图2所示的架构的具体流程如下：

1)通过PM2工具启动Master模块(即调度模块)，由于每一台服务器只有一个Master模块，所以，一旦Master模块异常终止，整个服务就会停止服务，服务器就会因为数据文件过多，磁盘耗费光，服务中断。由于PM2有监控Nodejs程序并能第一时间自动重启Nodejs程序的特点，从而实现Master模块的高可用。

2)Master模块通过Watch模块定时轮训(目前设置为100ms)FTP目录查看是否有需要处理的文件，如果有，则将文件名传递给Master模块。

3)Master模块收到需要处理的文件名以后，Master模块判断CPU是否有空余资源，如果没有，则进入休眠100MS，并监听子任务退出事件，当休眠时间结束后返回步骤2)进行处理。如果有CPU空闲资源，则进行步骤4)的处理。

4)Master模块将待处理文件名，CPU编号存入Redis中，并将该任务标记为待进行。

5)Master模块判断是否存在以CPU编号为文件夹名的文件夹，如果不存在则创建，并将该文件存入此文件夹，如果存在则将待处理文件存入该文件夹。

6)Master模块通过Fork启动子任务(利用Nodejs的Cluster模块创建子进程)，并将文件名，CPU编号传入子任务中，同时将子任务的pid存入redis对应的cpu编号中。

7)子任务启动后获取文件名以及CPU编号。通过CPU编号以及文件名获取需要处理的文件路径，并更新Redis中文件处理任务状态为处理中，然后开始进行文件解析。

8)文件解析成功后，将解析后的结果推送至Kafka服务器，如果文件解析失败，则退出子任务，子任务退出码为999。

9)当子任务成功处理结束后，更新Redis中该文件的处理状态为已结束，并退出，退出码为0。

10)Master模块通过退出事件可以获取到该子任务运行结束，并读取Redis中文件处理状态，如果是已结束，则将该处理文件移入已处理文件夹，如果不是已结束，说明子任务异常终止。需要重新启动该子任务。重新处理文件。

11)如果子任务退出，并且退出码为0，则重新执行第2)步。

本申请实施例的技术方案，提出一种任务调度方案，优化了Nodejs程序在多核CPU并行计算效率，通过单一任务调度单元(即Master模块)分配任务的方式避免了并行任务间的冲突，提高了Nodejs的并发处理效率。

本申请实施例的上述方案可以通过如下代码实现，需要说明的是，以下代码属于伪代码，在不偏离本申请实施例技术方案宗旨的前提下，任何形式的代码所实现的功能都属于本申请实施例的保护范围：

图3为本申请实施例提供的文件处理装置的结构组成示意图，如图3所示，所述文件处理装置包括：

Watch模块301，用于监听FTP目录中是否有新增文件；

调度模块302，用于若有新增文件，则判断是否有空闲的处理器资源；若有空闲的处理器资源，则将所述新增文件作为待处理文件移入所述处理器资源对应的文件夹，并将所述待处理文件的文件名、所述处理器资源的编号以及所述待处理文件的处理状态存入数据库中；创建一个子任务利用所述处理器资源对所述待处理文件进行处理，并将处理结果推送至Kafka服务器。

在一实施方式中，所述Watch模块301，用于定时轮训FTP目录，以查看FTP目录中是否有新增文件，若有新增文件，则将所述新增文件的文件名传递给调度模块302；

所述调度模块302，用于收到所述新增文件的文件名后是否有空闲的处理器资源。

在一实施方式中，所述调度模块302，用于判断是否存在所述处理器资源对应的文件夹；若不存在，则创建所述处理器资源对应的文件夹，并将所述待处理文件存入该文件夹；若存在，则直接将所述待处理文件存入该文件夹；其中，所述处理器资源对应的文件夹的文件夹名包含所述处理器资源的编号。

在一实施方式中，所述调度模块302，用于通过Fork启动子任务，并将所述待处理文件的文件名和所述处理器资源的编号传入所述子任务中；所述子任务启动后根据所述待处理文件的文件名和所述处理器资源的编号，获取需要处理的文件路径，并更新所述数据库中所述待处理文件的处理状态为处理中，而后开始对所述待处理文件进行解析。

在一实施方式中，所述调度模块302，用于所述子任务成功处理结束后，更新所述数据库中所述待处理文件的处理状态为已结束，并将处理过的文件移入已处理文件夹。

本领域技术人员应当理解，图3所示的文件处理装置中的各模块的实现功能可参照前述文件处理方法的相关描述而理解。图3所示的文件处理装置中的各模块的功能可通过运行于处理器上的程序而实现，也可通过具体的逻辑电路而实现。

本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和智能设备，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个***，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个第二处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

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

Claims (6)

1.一种文件处理方法，其特征在于，所述方法包括：

监听FTP目录中是否有新增文件，若有新增文件，则判断是否有空闲的处理器资源；

若有空闲的处理器资源，则调度模块判断是否存在所述处理器资源对应的文件夹；若不存在，则创建所述处理器资源对应的文件夹，并将待处理文件存入该文件夹；若存在，则直接将所述待处理文件存入该文件夹；其中，所述处理器资源对应的文件夹的文件夹名包含所述处理器资源的编号，并将所述待处理文件的文件名、所述处理器资源的编号以及所述待处理文件的处理状态存入数据库中；

调度模块通过Fork启动子任务，并将所述待处理文件的文件名和所述处理器资源的编号传入所述子任务中；所述子任务启动后根据所述待处理文件的文件名和所述处理器资源的编号，获取需要处理的文件路径，并更新所述数据库中所述待处理文件的处理状态为处理中，而后开始对所述待处理文件进行解析，并将处理结果推送至Kafka服务器。

2.根据权利要求1所述的方法，其特征在于，所述监听FTP目录中是否有新增文件，若有新增文件，则判断是否有空闲的处理器资源，包括：

Watch模块定时轮训FTP目录，以查看FTP目录中是否有新增文件，若有新增文件，则所述Watch模块将所述新增文件的文件名传递给调度模块；

所述调度模块收到所述新增文件的文件名后是否有空闲的处理器资源。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述子任务成功处理结束后，更新所述数据库中所述待处理文件的处理状态为已结束，并将处理过的文件移入已处理文件夹。

4.一种文件处理装置，其特征在于，所述装置包括：

Watch模块，用于监听FTP目录中是否有新增文件；

调度模块，用于若有新增文件，则判断是否有空闲的处理器资源；若有空闲的处理器资源，则判断是否存在所述处理器资源对应的文件夹；若不存在，则创建所述处理器资源对应的文件夹，并将待处理文件存入该文件夹；若存在，则直接将所述待处理文件存入该文件夹；其中，所述处理器资源对应的文件夹的文件夹名包含所述处理器资源的编号，并将所述待处理文件的文件名、所述处理器资源的编号以及所述待处理文件的处理状态存入数据库中；通过Fork启动子任务，并将所述待处理文件的文件名和所述处理器资源的编号传入所述子任务中；所述子任务启动后根据所述待处理文件的文件名和所述处理器资源的编号，获取需要处理的文件路径，并更新所述数据库中所述待处理文件的处理状态为处理中，而后开始对所述待处理文件进行解析，并将处理结果推送至Kafka服务器。

5.根据权利要求4所述的装置，其中，

所述Watch模块，用于定时轮训FTP目录，以查看FTP目录中是否有新增文件，若有新增文件，则将所述新增文件的文件名传递给调度模块；

所述调度模块，用于收到所述新增文件的文件名后是否有空闲的处理器资源。

6.根据权利要求4所述的装置，其中，所述调度模块，用于所述子任务成功处理结束后，更新所述数据库中所述待处理文件的处理状态为已结束，并将处理过的文件移入已处理文件夹。

Images