分布式文件架构的任务处理方法和装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种分布式文件架构的任务处理方法和装置。
背景技术
分布式文件架构通常包括任务框架和若干任务处理器。其中,任务框架可用来调度任务处理器处理相关的任务。一个任务的处理通常包括有多个处理阶段,当某个处理阶段发生异常时,后续需要重新处理该异常任务,如何确保异常任务的执行效率和数据准确率已成为目前亟待解决的问题。
发明内容
有鉴于此,本申请提供一种分布式文件架构的任务处理方法和装置。
具体地,本申请是通过如下技术方案实现的:
一种分布式文件架构的任务处理方法,所述分布式文件架构包括任务框架以及若干任务处理器,所述任务处理方法应用于任务框架,包括:
提取待处理的任务;
确定所述任务所属的任务处理器;
调用所述任务处理器对所述任务进行处理,并基于所述任务处理器返回的处理结果更新所述任务的处理状态信息;
当所述任务处理器返回处理异常的处理结果时,将所述任务和所述任务的处理状态信息记录到异常任务表中;
基于预设的策略提取所述异常任务表中的异常任务;
根据所述异常任务的处理状态信息,调用所述异常任务所属的任务处理器继续对所述异常任务进行处理。
一种分布式文件架构的任务处理装置,所述分布式文件架构包括任务框架以及若干任务处理器,所述任务处理装置应用于任务框架,包括:
任务提取单元,提取待处理的任务;
处理器确定单元,确定所述任务所属的任务处理器;
处理器调用单元,调用所述任务处理器对所述任务进行处理,并基于所述任务处理器返回的处理结果更新所述任务的处理状态信息;
异常记录单元,当所述任务处理器返回处理异常的处理结果时,将所述任务和所述任务的处理状态信息记录到异常任务表中;
异常提取单元,基于预设的策略提取所述异常任务表中的异常任务;
异常处理单元,根据所述异常任务的处理状态信息,调用所述异常任务所属的任务处理器继续对所述异常任务进行处理。
由以上描述可以看出,本申请任务框架可以记录异常任务的处理状态信息,在恢复时可根据该处理状态信息调用任务处理器继续对异常任务进行处理,提高任务处理速率,节省处理资源,避免数据错误。
附图说明
图1是本申请一示例性实施例示出的一种分布式文件架构的任务处理方法的流程示意图。
图2是本申请一示例性实施例示出的一种创建待处理任务的流程示意图。
图3是本申请一示例性实施例示出的一种用于分布式文件架构的任务处理装置的流程示意图。
图4是本申请一示例性实施例示出的一种分布式文件架构的任务处理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
分布式文件架构对任务的处理通常包括以下过程:
1.创建待处理的任务。当待处理的任务已被创建时,该任务处于Pending状态,即该任务的处理状态信息为Pending状态。
2.将任务拆分为多个子任务。当任务已被成功拆分为多个子任务时,该任务处于SplitUp状态。
3.处理拆分后的多个子任务。当该任务的所有子任务均已被处理完毕时,该任务处于Merging状态。
4.合并处理完毕的多个子任务。当合并完毕该任务的所有子任务时,该任务处于Merged状态。
5.对合并后的任务进行扫尾处理。当该任务已完成扫尾处理时,该任务处于Finalize状态。
相关技术中,当任务发生异常时,处于Deferred状态。针对处于Deferred状态的异常任务,任务框架将其恢复为Pending状态,然后调用任务处理器对该任务进行处理,这就可能需要重新执行合并处理,造成任务数据的不准确,同时消耗系统大量的处理资源。
举例来说,假设任务异常时处于Merged状态,即任务已完成合并,在扫尾阶段出现了异常,那么任务框架可将该任务恢复到Pending状态,任务框架检测到该任务已存在对应的子任务,则可以将该任务推进到SplitUp状态。接着,任务框架又检测到该任务的各个子任务均已处理完毕,则可继续将该任务推进到Merging状态,然后调用任务处理器重新执行合并阶段和扫尾阶段。由于任务合并是对所有子任务处理结果的汇总,任务量大,且只能单机执行,重新合并会消耗大量的处理资源。另一方面,由于该任务在异常时已处于Merged状态,即该任务已完成合并,重新合并会导致数据异常,比如:若该合并操作是合并两个文件的文件路径,由于该任务异常时已完成两个文件路径的合并,异常恢复时再提取合并后的路径进行合并,就会导致严重的错误。
针对上述问题,本申请提供一种分布式文件架构的任务处理方法,记录异常任务的处理状态信息,以在恢复异常任务时,提升任务处理速度,避免数据错误。
图1是本申请一示例性实施例示出的一种分布式文件架构的任务处理方法的流程示意图。基于业务层面的划分,该分布式文件架构包括任务框架和若干任务处理器,所述任务框架和所述任务处理器的物理载体可以为服务器或者服务器集群,本申请对此不作特殊限制。
请参考图1,所述分布式文件架构的任务处理方法可以应用在分布式文件架构的任务框架中,包括有以下步骤:
步骤101,提取待处理的任务。
在本实施例中,任务框架可以基于预设的时间周期从数据库中提取待处理的任务,任务框架也可以不停的遍历数据库,以提取待处理的任务,本申请对此不作特殊限制。
在本实施例中,任务框架可以提取出所述待处理的任务的元数据,所述元数据可以包括:任务类型、任务日期、触发时间、依赖任务、所属任务处理器等信息。
步骤102,确定所述任务所属的任务处理器。
步骤103,调用所述任务处理器对所述任务进行处理,并基于所述任务处理器返回的处理结果更新所述任务的处理状态信息。
在本实施例中,任务框架在确定待处理任务所属的任务处理器后,可以调用任务处理器对任务进行处理。
参照前述任务处理过程,任务框架可以先调用所述任务处理器对所述任务进行拆分,当拆分完毕后,可以将该任务的处理状态信息更新为SplitUp状态,并可以继续调用任务处理器处理拆分后的子任务,这部分的处理与实现可以参照相关技术,本申请在此不再一一赘述。
步骤104,当所述任务处理器返回处理异常的处理结果时,将所述任务和所述任务的处理状态信息记录到异常任务表中。
在本实施例中,任务处理器可根据任务框架的调用对任务进行不同阶段的处理,若处理完毕,则可以将处理后的结果返回给任务框架,若处理过程中发生异常,则可以将处理异常的处理结果返回给任务框架。
在本实施例中,任务框架在接收到处理异常的处理结果时,可以将该任务和该任务当前的处理状态信息一同记录到异常任务表中。其中,所述异常任务表用于存储异常的任务。具体地,任务框架可以在该异常任务表中新增一列字段,用于存储异常任务的处理状态信息。
举例来说,假设任务在扫描阶段出现了异常,那么该任务当前的处理状态信息为Merged状态,任务框架可以将该任务和Merged状态一同记录到异常任务表中。
步骤105,基于预设的策略提取所述异常任务表中的异常任务。
在本实施例中,任务框架可以定期提取异常任务表中的异常任务,以进行异常任务的恢复。当然,在实际应用中,也可以采用其他的策略提取所述异常任务表中的异常任务,本申请对此不作特殊限制。
步骤106,根据所述异常任务的处理状态信息,调用所述异常任务所属的任务处理器继续对所述异常任务进行处理。
基于前述步骤105,在提取到异常任务后,任务框架可以基于该异常任务的处理状态信息确定所述处理状态信息对应的下一处理阶段,然后调用所述异常任务所属的任务服务器对所述异常任务进行所述下一处理阶段的处理。
仍以步骤104中的举例为例,任务框架提取到该异常任务,而该异常任务的处理状态信息为Merged状态,说明该任务已合并完毕,在实现时,任务框架根据Merged状态,可以确定该任务下一处理阶段是扫尾处理,进而可以调用该任务所属是任务处理器对该任务进行扫描阶段的处理。相较于相关技术,无需将还任务恢复Pending状态,进而无需进行任务拆分、子任务处理的检测,也无需重新对该任务进行合并处理,节省处理资源,提高任务处理速率,同时避免了重新合并导致的数据错误。
由以上描述可以看出,本申请任务框架可以记录异常任务的处理状态信息,在恢复时可根据该处理状态信息调用任务处理器继续对异常任务进行处理,提高任务处理速率,节省处理资源,避免数据错误。
相关技术中,在创建待处理任务时,任务框架可定期向任务处理器查询需要处理的任务,任务处理器会将需要处理的任务的元数据发送给任务框架,由任务框架查询是否已创建该待处理的任务,并在未创建该待处理的任务时,创建该任务。然而,采用这样的实现方式,每当任务处理器返回元数据时,任务框架都需要提取所有已创建的任务进行一次判断,严重浪费任务框架的处理资源。
针对这个问题,本申请提供一种待处理任务的创建方法,请参考图2,该方法可包括以下步骤:
步骤201,任务处理器获取待处理任务的幂等字段。
在本实施例中,任务处理器也可以根据预设的时间周期获取待处理任务的幂等字段。所述幂等字段包括能够唯一确定一个任务的信息,以基金文件为例,该幂等字段可以包括:机构ID、任务日期以及任务处理器ID。这些幂等字段通常为静态数据,任务处理器获取这些数据的成本非常低。
步骤202,任务处理器根据所述幂等字段判断是否已创建所述待处理任务。
在本实施例中,根据获取到的幂等字段,任务处理器可以提取已创建的待处理任务,并判断已创建的待处理任务的幂等字段和获取到的幂等字段是否相同,若完全相同,则可以确定已创建该待处理任务,若不完全相同,则可以确定尚未创建该待处理任务。
步骤203,任务处理器在确定未创建所述待处理任务时,获取所述待处理任务的元数据。
基于前述步骤202的判断结果,若任务处理器确定未创建所述待处理任务时,可以继续获取该待处理任务的元数据。其中,所述元数据包括有上述幂等字段,还包括该任务的触发时间、文件路径信息、依赖任务、附加记录等其他信息。
步骤204,任务处理器将所述元数据发送给任务框架。
在本实施例中,任务处理器可以在任务框架查询待处理任务时,将获取到的待处理任务的元数据发送给任务框架。
步骤205,任务框架根据所述元数据创建所述待处理任务。
在本实施例中,任务框架在接收到任务处理器发送的元数据后,可以直接根据该元数据创建对应的待处理任务,大大节省了任务框架的处理资源。
由以上描述可以看出,本申请任务处理器可以根据幂等字段判断是否已创建待处理任务,针对已创建的待处理任务,任务处理器无需再获取该任务的元数据,节省了任务处理器的资源。对于任务框架而言,需要进行任务创建与否的判断,大大节省了任务框架的处理资源。
与前述分布式文件架构的任务处理方法的实施例相对应,本申请还提供了分布式文件架构的任务处理装置的实施例。
本申请分布式文件架构的任务处理装置的实施例可以应用在分布式文件架构的任务框架上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在任务框架的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图3所示,为本申请分布式文件架构的任务处理装置所在任务框架的一种硬件结构图,除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外,实施例中装置所在的任务框架通常根据该任务框架的实际功能,还可以包括其他硬件,对此不再赘述。
图4是本申请一示例性实施例示出的一种分布式文件架构的任务处理装置的框图。
请参考图4,所述分布式文件架构的任务处理装置300可以应用在前述图3所示的任务框架中,包括有:任务提取单元301、处理器确定单元302、处理器调用单元303、异常记录单元304、异常提取单元305、异常处理单元306以及任务创建单元307。
其中,任务提取单元301,提取待处理的任务;
处理器确定单元302,确定所述任务所属的任务处理器;
处理器调用单元303,调用所述任务处理器对所述任务进行处理,并基于所述任务处理器返回的处理结果更新所述任务的处理状态信息;
异常记录单元304,当所述任务处理器返回处理异常的处理结果时,将所述任务和所述任务的处理状态信息记录到异常任务表中;
异常提取单元305,基于预设的策略提取所述异常任务表中的异常任务;
异常处理单元306,根据所述异常任务的处理状态信息,调用所述异常任务所属的任务处理器继续对所述异常任务进行处理。
可选的,所述异常处理单元306,确定所述处理状态信息对应的下一处理阶段,并调用所述异常任务所属的任务服务器对所述异常任务进行所述下一处理阶段的处理。
可选的,所述任务的处理状态信息包括:
Pending状态,用于表示所述任务已被创建;
SplitUp状态,用于表示所述任务已被拆分为多个子任务;
Merging状态,用于表示所述子任务均已处理完毕;
Merged状态,用于表示所述子任务已合并完毕;
Finalize状态,用于表示所述任务已完成扫尾处理。
任务创建单元307,接收任务处理器发送的待处理任务的元数据,并根据所述元数据创建对应的任务;其中,所述元数据由所述任务处理器在根据所述待处理任务的幂等字段确定所述任务未被创建时获取。
可选的,所述幂等字段包括能够唯一确定一个任务的信息。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。