任务消息处理系统及方法与流程

文档序号:12459590阅读:153来源:国知局
任务消息处理系统及方法与流程

本发明涉及通信技术领域,尤其涉及一种任务消息处理系统及方法。



背景技术:

目前,在控制系统向与其连接的各个任务处理器分配任务消息时,一般均采用单节点分配方式。即,要求用户手动为当前待执行的任务消息分配对应的任务处理器。然而,在用户无法获知各个任务处理器的空闲状态时,由于无法根据任务处理器的空闲状态为当前待执行的任务消息选择任务处理器,用户手动分配的任务处理器可能并没有处于空闲状态,而其他任务处理器中仍含有处于空闲状态的任务处理器,从而造成不能合理的调用任务处理器。现有技术的缺陷在于,分配任务的方式为手动指定方式,不仅较为繁琐,浪费人力,而且不能合理的调用任务处理器。



技术实现要素:

本发明的主要目的在于提供一种任务消息处理系统及方法,旨在解决分配任务较为繁琐,浪费人力,以及不能合理的调用任务处理器的技术问题。

本发明提供的任务消息处理系统包括控制器、消息队列管理器和任务处理器;

所述控制器用于在接收到任务消息时,将所述任务消息发送至所述消息队列管理器;

所述任务处理器用于在处于空闲状态时,向所述消息队列管理器获取任务消息。

可选的,所述任务处理器还用于确定获取的所述任务消息对应的运行方式,以及根据确定的所述运行方式执行所述任务消息。

可选的,所述控制器还用于在接收到任务消息时,确定所述任务消息是否具有关联任务消息;

所述控制器还用于在所述任务消息具有关联任务消息时,获取所述关联任务消息,并将所述关联任务消息与任务消息按照预设次序打包并生成一个任务消息组,以及将所述任务消息组发送至消息队列管理器;

所述任务处理器还用于在获取的任务消息为任务消息组时,确定所述任务消息组中的各个任务消息的执行次序,并按照执行次序依次执行所述任务消息组中的各个任务消息。

可选的,所述任务消息处理系统还包括监控器;

所述监控器用于获取任务处理器的运行状态;

所述监控器还用于在运行状态为失败时,记录运行失败信息,并将所述运行失败信息发送至控制器,以及返回调用所述控制器和任务处理器。

可选的,所述监控器还用于在侦测到任务处理器启动时,注册一个与所述任务处理器对应的临时节点;

所述监控器还用于在侦测到任务处理器宕机时,删除与所述任务处理器对应的临时节点。

此外,本发明进一步提供的任务消息处理方法包括:

控制器在接收到任务消息时,将所述任务消息发送至消息队列管理器;

任务处理器在处于空闲状态时,向所述消息队列管理器获取任务消息。

可选的,所述任务处理器在处于空闲状态时,向所述消息队列管理器获取任务消息的步骤之后,还包括:

任务处理器确定获取的所述任务消息对应的运行方式;

任务处理器根据确定的所述运行方式执行所述任务消息。

可选的,所述控制器在接收到任务消息时,将所述任务消息发送至消息队列管理器的步骤包括:

控制器在接收到任务消息时,确定所述任务消息是否具有关联任务消息;

在所述任务消息具有关联任务消息时,获取所述关联任务消息,并将所述关联任务消息与任务消息按照预设次序打包并生成一个任务消息组;

将所述任务消息组发送至消息队列管理器;

所述任务处理器在处于空闲状态时,向所述消息队列管理器获取任务消息的步骤之后,还包括:在获取的任务消息为任务消息组时,所述任务处理器确定所述任务消息组中的各个任务消息的执行次序,并按照执行次序依次执行所述任务消息组中的各个任务消息。

可选的,所述任务消息处理方法还包括:

监控器获取任务处理器的运行状态;

在运行状态为失败时,监控器记录运行失败信息,并将所述运行失败信息发送至控制器;

在控制器接收到运行失败信息时,返回执行所述将所述任务消息发送至消息队列管理器的步骤。

可选的,所述任务消息处理方法还包括:

所述监控器在侦测到任务处理器启动时,注册一个与所述任务处理器对应的临时节点;

所述监控器在侦测到任务处理器宕机时,删除与所述任务处理器对应的临时节点。

本发明提出的任务消息处理系统及方法,通过控制器在接收到任务消息时,将所述任务消息发送至消息队列管理器,并通过任务处理器在处于空闲状态时,向所述消息队列管理器获取任务消息,从而不需要用户手动为任务处理器分配任务,节约了人力,而且系统能够自动的根据任务处理器的空闲状态获取任务消息,从而实现了合理的调用任务处理器。

附图说明

图1为本发明任务消息处理系统第一实施例的功能模块示意图;

图2为本发明任务消息处理系统第四实施例的功能模块示意图;

图3为本发明任务消息处理方法第一实施例的流程示意图;

图4为本发明任务消息处理方法第二实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。

具体实施方式

应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。

参照图1,图1为本发明任务消息处理系统第一实施例的功能模块示意图。需要强调的是,对本领域的技术人员来说,图1所示功能模块图仅仅是一个较佳实施例的示例图,本领域的技术人员围绕图1所示的任务消息处理系统的功能模块,可轻易进行新的功能模块的补充;各功能模块的名称是自定义名称,仅用于辅助理解该任务消息处理系统的各个程序功能块,不用于限定本发明的技术方案,本发明技术方案的核心是,各自定义名称的功能模块所要达成的功能。

本实施例提出一种任务消息处理系统,所述任务消息处理系统包括:

控制器10、消息队列管理器20和任务处理器30;

所述控制器10用于在接收到任务消息时,将所述任务消息发送至所述消息队列管理器20;

在本实施例中,用户可以预先通过控制器10提供的WEB页面登记任务消息,例如任务名称、任务编号、任务执行时间段、关联任务消息以及是否重试等信息。其中,任务执行时间段为可选项,若未登记,则可以默认为一次性任务。关联任务消息可以为前置任务消息,若包括前置任务消息,则控制器10会将相关联的各个任务消息进行打包,组成任务消息组,任务消息组中的各个任务消息具有预设的执行顺序。在任务处理器30获取到任务消息组后,按照预设的执行顺序执行任务消息组中的各个任务消息。在登记是否重试信息时,可以登记若任务执行失败是否重试以及重试次数等信息。

所述任务处理器30用于在处于空闲状态时,向所述消息队列管理器20获取任务消息;

在本实施例中,控制器10可以获取任务处理器30的运行状态。可选的,可以通过监控模块实时监控任务处理器30的运行状态,每个任务处理器30在执行任务时均会在监控模块上登记状态,控制器10通过监控模块获取任务处理器30的运行状态。从而控制器10可以找到处于空闲状态的任务处理器30,处于空闲状态的任务处理器30想消息队列管理器20获取任务消息。

可以理解的是,在任务处理器30当前未执行任何任务时,即可认为任务处理器30当前处于空闲状态。此外,若任务处理器30可并行处理的任务数量最大值大于1,则在任务处理器30当前执行的任务数量小于其对应的任务数量最大值时,则认为任务处理器30当前处于空闲状态。

本发明提供的任务消息处理系统,通过控制器10在接收到任务消息时,将所述任务消息发送至消息队列管理器20,并通过任务处理器30在处于空闲状态时,向所述消息队列管理器20获取任务消息,从而不需要用户手动为任务处理器30分配任务,节约了人力,而且系统能够自动的根据任务处理器30的空闲状态获取任务消息,从而实现了合理的调用任务处理器30。

进一步地,基于本发明任务消息处理系统的第一实施例,本发明还提出了任务消息处理系统的第二实施例,与第一实施例不同的是,在第二实施例中,所述任务处理器30还用于执行获取的所述任务消息。

可选的,任务处理器30可以采用预设的运行方法执行任务消息。

可选的,所述任务处理器30还用于确定获取的所述任务消息对应的运行方式,以及根据确定的所述运行方式执行所述任务消息。可选的,任务消息中可以携带对应的运行方式,在任务处理器30获取到任务消息后,对任务消息进行解析以获得对应的运行方式。从而可以更加高效地处理任务消息。

进一步地,基于本发明任务消息处理系统的第一或第二实施例,本发明还提出了任务消息处理系统的第三实施例,与第一或第二实施例不同的是,在第三实施例中,所述控制器10还用于在接收到任务消息时,确定所述任务消息是否具有关联任务消息;

所述控制器10还用于在所述任务消息具有关联任务消息时,获取所述关联任务消息,并将所述关联任务消息与任务消息按照预设次序打包并生成一个任务消息组,以及将所述任务消息组发送至消息队列管理器20;

在所述任务处理器30获取的任务消息为任务消息组时,所述任务处理器30还用于确定所述任务消息组中的各个任务消息的执行次序,并按照执行次序依次执行所述任务消息组中的各个任务消息。

在本实施例中,关联任务消息可以为前置任务消息,若包括前置任务消息,则控制器10会将相关联的各个任务消息进行打包,组成任务消息组,任务消息组中的各个任务消息具有预设的执行顺序。在任务处理器30获取到任务消息组后,按照预设的执行顺序执行任务消息组中的各个任务消息。本实施例可以将相关联的任务消息打包发送至同一任务处理器30,并且携带对应的执行次序,避免了相关联的任务消息发送至不同的任务处理器30以至于无法处理任务消息的问题产生。

进一步地,基于本发明任务消息处理系统的第一至第三任一实施例,本发明还提出了任务消息处理系统的第四实施例,参照图2,图2为本发明任务消息处理系统第四实施例的功能模块示意图,与第一至第三任一实施例不同的是,在第四实施例中,所述任务消息处理系统还包括监控器40;

所述监控器40用于获取任务处理器30的运行状态;

所述监控器40还用于在运行状态为失败时,记录运行失败信息,并将所述运行失败信息发送至控制器10,以及返回调用所述控制器10和任务处理器30。

在本实施例中,任务处理器30在运行时,会在监控器40上登记运行状态为运行中。在任务处理器30运行结束时,会在监控器40上登记运行状态为等待。在任务处理器30运行失败时,会在监控器40上登记运行状态为失败,并记录相应的失败信息。

控制器10在收到运行失败信息后,根据注册时的配置信息执行重试操作,重新调度等。即,重新将所述任务消息发送至消息队列管理器20,任务处理器30在处于空闲状态时,向所述消息队列管理器20获取任务消息。从而在任务处理器30执行任务消息失败时能够及时返回并重新调用。

可选的,任务处理器30还可以记录每个任务消息的执行结果,并将执行结果上报。

进一步的,所述监控器40还用于在侦测到任务处理器30启动时,注册一个与所述任务处理器30对应的临时节点;所述监控器40还用于在侦测到任务处理器30宕机时,删除与所述任务处理器30对应的临时节点。从而实现了对任务处理器30的存活状态的实时监控。

可选的,每个任务消息在执行时都会在监控器40上登记任务编号,控制器10通过这些任务编号在页面上展示正在执行的任务。

可选的,控制器10页面还可以提供查询任务执行历史信息的功能,用户可以查询任务消息的执行结果以及执行时间等。

本发明进一步提供一种任务消息处理方法,参照图3,图3为本发明任务消息处理方法第一实施例的流程示意图,所述任务消息处理方法包括:

步骤S10,控制器在接收到任务消息时,将所述任务消息发送至消息队列管理器;

在本实施例中,用户可以预先通过控制器提供的WEB页面登记任务消息,例如任务名称、任务编号、任务执行时间段、关联任务消息以及是否重试等信息。其中,任务执行时间段为可选项,若未登记,则可以默认为一次性任务。关联任务消息可以为前置任务消息,若包括前置任务消息,则控制器会将相关联的各个任务消息进行打包,组成任务消息组,任务消息组中的各个任务消息具有预设的执行顺序。在任务处理器获取到任务消息组后,按照预设的执行顺序执行任务消息组中的各个任务消息。在登记是否重试信息时,可以登记若任务执行失败是否重试以及重试次数等信息。

步骤S20,任务处理器在处于空闲状态时,向所述消息队列管理器获取任务消息。

在本实施例中,控制器可以获取任务处理器的运行状态。可选的,可以通过监控模块实时监控任务处理器的运行状态,每个任务处理器在执行任务时均会在监控模块上登记状态,控制器通过监控模块获取任务处理器的运行状态。从而控制器可以找到处于空闲状态的任务处理器,处于空闲状态的任务处理器想消息队列管理器获取任务消息。

可以理解的是,在任务处理器当前未执行任何任务时,即可认为任务处理器当前处于空闲状态。此外,若任务处理器可并行处理的任务数量最大值大于1,则在任务处理器当前执行的任务数量小于其对应的任务数量最大值时,则认为任务处理器当前处于空闲状态。

本发明提供的任务消息处理方法,通过控制器在接收到任务消息时,将所述任务消息发送至消息队列管理器,并通过任务处理器在处于空闲状态时,向所述消息队列管理器获取任务消息,从而不需要用户手动为任务处理器分配任务,节约了人力,而且系统能够自动的根据任务处理器的空闲状态获取任务消息,从而实现了合理的调用任务处理器。

进一步地,基于本发明任务消息处理方法的第一实施例,本发明还提出了任务消息处理方法的第二实施例,参照图4,图4为本发明任务消息处理方法第二实施例的流程示意图,与第一实施例不同的是,在第二实施例中,所述步骤S20之后,还包括:

步骤S30,任务处理器执行获取的所述任务消息。

可选的,任务处理器可以采用预设的运行方法执行任务消息。

可选的,步骤S30包括:所述任务处理器确定获取的所述任务消息对应的运行方式,以及根据确定的所述运行方式执行所述任务消息。可选的,任务消息中可以携带对应的运行方式,在任务处理器获取到任务消息后,对任务消息进行解析以获得对应的运行方式。从而可以更加高效地处理任务消息。

进一步地,基于本发明任务消息处理方法的第一或第二实施例,本发明还提出了任务消息处理方法的第三实施例,与第一或第二实施例不同的是,在第三实施例中,所述步骤S10包括:

控制器在接收到任务消息时,确定所述任务消息是否具有关联任务消息;

在所述任务消息具有关联任务消息时,获取所述关联任务消息,并将所述关联任务消息与任务消息按照预设次序打包并生成一个任务消息组;

将所述任务消息组发送至消息队列管理器;

所述步骤S20之后,还包括:在获取的任务消息为任务消息组时,所述任务处理器确定所述任务消息组中的各个任务消息的执行次序,并按照执行次序依次执行所述任务消息组中的各个任务消息。

在本实施例中,关联任务消息可以为前置任务消息,若包括前置任务消息,则控制器会将相关联的各个任务消息进行打包,组成任务消息组,任务消息组中的各个任务消息具有预设的执行顺序。在任务处理器获取到任务消息组后,按照预设的执行顺序执行任务消息组中的各个任务消息。本实施例可以将相关联的任务消息打包发送至同一任务处理器,并且携带对应的执行次序,避免了相关联的任务消息发送至不同的任务处理器以至于无法处理任务消息的问题产生。

进一步地,基于本发明任务消息处理方法的第一至第三任一实施例,本发明还提出了任务消息处理方法的第四实施例,与第一至第三任一实施例不同的是,在第四实施例中,所述任务消息处理方法还包括:

监控器获取任务处理器的运行状态;

在运行状态为失败时,监控器记录运行失败信息,并将所述运行失败信息发送至控制器;

在控制器接收到运行失败信息时,返回执行所述将所述任务消息发送至消息队列管理器的步骤。

在本实施例中,任务处理器在运行时,会在监控器上登记运行状态为运行中。在任务处理器运行结束时,会在监控器上登记运行状态为等待。在任务处理器运行失败时,会在监控器上登记运行状态为失败,并记录相应的失败信息。

控制器在收到运行失败信息后,根据注册时的配置信息执行重试操作,重新调度等。即,重新将所述任务消息发送至消息队列管理器,任务处理器在处于空闲状态时,向所述消息队列管理器获取任务消息。从而在任务处理器执行任务消息失败时能够及时返回并重新调用。

可选的,任务处理器还可以记录每个任务消息的执行结果,并将执行结果上报。

进一步的,所述任务消息处理方法还包括:

所述监控器在侦测到任务处理器启动时,注册一个与所述任务处理器对应的临时节点;

所述监控器在侦测到任务处理器宕机时,删除与所述任务处理器对应的临时节点。从而实现了对任务处理器的存活状态的实时监控。

可选的,每个任务消息在执行时都会在监控器上登记任务编号,控制器通过这些任务编号在页面上展示正在执行的任务。

可选的,控制器页面还可以提供查询任务执行历史信息的功能,用户可以查询任务消息的执行结果以及执行时间等。

需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1