CN110245008B - 定时任务处理方法、系统和设备 - Google Patents

Abstract

本发明实施例提供一种定时任务处理方法、系统和设备，该方法包括：从第一消息队列中拉取定时任务对应的消息，消息中包括定时任务的下一次执行时间和业务参数；若根据当前时间与下一次执行时间之间的第一时间差确定当前需要消费消息，则根据业务参数消费消息；将消费消息得到的定时任务处理结果发送至定时任务对应的终端设备。将对定时任务的处理转换为对消息的处理，相比于传统的基于数据库的定时任务处理模式，本方案采用消息系统代替了数据库，将定时任务转换为消息，对消息的处理无需进行加锁、解锁，在高并发的定时任务场景中，可以提高定时任务并发处理效率。

Description

定时任务处理方法、系统和设备

技术领域

本发明涉及互联网技术领域，尤其涉及一种定时任务处理方法、系统和设备。

背景技术

用户在很多实际应用场景中会有产生定时任务的需求，比如：每周一上午8点提醒起床；从当前时间起每隔15秒推送一条音频；10分钟后提醒我去抢购，等等。

这些定时任务背后的业务处理逻辑较为简单，核心的诉求是按照预期的时间执行任务。当这样的定时任务的数量较大的时候，那么传统的解决方案就回出现瓶颈，例如一个拥有100万用户的终端产品，假设这个产品有一个倒计时的功能，如果用户设定一个10分钟的倒计时，每隔15秒推送一段音频，假设全部用户都设定这一功能，那么理论上，这个产品单单这个功能就可能产生100万*40即4千万的定时任务。

目前，一种常用的调度定时任务的方式是采用Apache开源的定时调度框架Quartz，Quartz是一个开源的作业调度框架，能够很容易的解决任务定时调度问题，可以单机进行处理，也可以进行集群作业，以集群作业为例说明Quartz的解决方案。Quartz集群中包括多个Quartz服务器节点，多个Quartz服务器节点共用一个数据库，数据库中存储有任务(Job)相关信息。每个Quartz服务器节点都是一个独立的Quartz应用。

在介绍Quartz的原理之前，要介绍4个基本概念(接口)：

Job：表示一个任务，要执行的具体内容，是一个接口，其运行时信息放在JobDataMap中。

JobDetail：JobDetail表示一个具体的可执行的调度程序，Job是这个可执行程调度程序所要执行的内容，即每次调度一个Job都会生成这个Job的JobDetail实例。另外JobDetail还包含了任务调度的方案和策略。

Trigger：代表一个调度参数的配置，主要是时间配置，用于告诉什么时候去调。

Scheduler：代表一个调度容器，一个调度容器中可以注册多个JobDetail和Trigger。当Trigger与JobDetail组合即形成了装配好的作业，就可以被Scheduler容器调度了。这里面包含一个线程池(ThreadPool)用来并行调度每个作业，以此提高效率。

上述结构用一个图来表示，如图1所示。

基于上述结构的介绍，当某个Quartz服务器节点的Scheduler被启动后，通过线程池中的线程拉取数据库中的任务，将任务实例化并运行，以获得任务处理结果。由于任务相关信息是存储在数据库中的，在进行任务获取时，需要使用加锁/解锁机制，简单来说就是，在获取任务时，需要判断相应行锁是否被其他线程占用，若被其他线程占用，则等待锁的释放；若没有被其他线程占用，则获取锁进行加锁处理，执行任务处理，处理完成后释放锁。

由此可见，Quartz架构下，采用数据库作为数据中心来存储定时任务，定时任务的处理过程中存在复杂的加锁、解锁过程。当面对重量级任务即定时任务数量极大的场景时，加锁、解锁的过程将会使得对这海量的定时任务的并发处理效率很低。

发明内容

有鉴于此，本发明实施例提供一种定时任务处理方法、系统和设备，用以提高海量定时任务的处理效率。

第一方面，本发明实施例提供一种定时任务处理方法，应用于服务端的处理系统侧，包括：

从第一消息队列中拉取定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

若根据当前时间与所述下一次执行时间之间的第一时间差确定当前需要消费所述消息，则根据所述业务参数消费所述消息；

将消费所述消息得到的定时任务处理结果发送至所述定时任务对应的终端设备。

第二方面，本发明实施例提供一种定时任务处理系统，包括：

包括至少一个消息队列的消息存储子系统，以及与每个所述消息队列对应的至少一个消息消费子系统；

所述消息存储子系统，用于将从终端设备接收到的与定时任务对应的消息存入所述至少一个消息队列中的第一消息队列中，所述消息中包括所述定时任务的下一次执行时间和业务参数；

与所述第一消息队列对应的目标消息消费子系统，用于从所述第一消息队列中拉取所述消息，若根据当前时间与所述下一次执行时间之间的第一时间差确定当前需要消费所述消息，则根据所述业务参数消费所述消息；将消费所述消息得到的定时任务处理结果发送至所述终端设备。

第三方面，本发明实施例提供一种定时任务处理装置，应用于服务端，包括：

获取模块，用于从第一消息队列中拉取定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

消费模块，用于若根据当前时间与所述下一次执行时间之间的第一时间差确定当前需要消费所述消息，则根据所述业务参数消费所述消息；

发送模块，用于将消费所述消息得到的定时任务处理结果发送至所述定时任务对应的终端设备。

在一个可能的设计中，上述定时任务处理装置的结构中包括处理器和存储器，所述存储器用于存储支持定时任务处理装置执行上述第一方面中定时任务处理方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。所述定时任务处理装置还可以包括通信接口，用于定时任务处理装置与其他设备或通信网络通信。

本发明实施例提供了一种计算机存储介质，用于储存定时任务处理装置所用的计算机软件指令，其包含用于执行上述第一方面中定时任务处理方法所涉及的程序。

第四方面，本发明实施例提供一种定时任务处理方法，应用于终端设备侧，包括：

生成与定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

将所述消息发送至服务端的定时任务处理系统，以使所述定时任务处理系统将所述消息存入消息队列，并在从所述消息队列中拉取到所述消息时，根据所述下一次执行时间和所述业务参数对所述消息进行消费；

接收所述定时任务处理系统发送的消费所述消息得到的定时任务处理结果。

第五方面，本发明实施例提供一种定时任务处理装置，位于终端设备中，包括：

生成模块，用于生成与定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

发送模块，用于将所述消息发送至服务端的定时任务处理系统，以使所述定时任务处理系统将所述消息存入消息队列，并在从所述消息队列中拉取到所述消息时，根据所述下一次执行时间和所述业务参数对所述消息进行消费；

接收模块，用于接收所述定时任务处理系统发送的消费所述消息得到的定时任务处理结果。

在一个可能的设计中，上述定时任务处理装置的结构中包括处理器和存储器，所述存储器用于存储支持定时任务处理装置执行上述第四方面中定时任务处理方法的程序，所述处理器被配置为用于执行所述存储器中存储的程序。所述定时任务处理装置还可以包括通信接口，用于定时任务处理装置与其他设备或通信网络通信。

本发明实施例提供了一种计算机存储介质，用于储存定时任务处理装置所用的计算机软件指令，其包含用于执行上述第四方面中定时任务处理方法所涉及的程序。

本发明实施例提供的定时任务处理方法、装置、系统和设备，将定时任务转换为对应的消息存入某个消息队列中，进而基于消息中包含的相关参数对消息进行消费，从而将对定时任务的处理转换为对消息的处理。相比于传统的基于数据库的定时任务处理模式，本发明实施例中采用消息系统代替了数据库，将定时任务转换为消息，对消息的处理无需进行加锁、解锁，在高并发的定时任务场景中，可以提高定时任务并发处理效率。

附图说明

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

图1为本发明实施例提供的定时任务处理系统的结构图；

图2为本发明实施例提供的一种消息消费子系统的结构图；

图3为本发明实施例提供的定时任务处理方法实施例一的流程图；

图4为本发明实施例提供的定时任务处理方法实施例二的流程图；

图5为本发明实施例提供的定时任务处理方法实施例三的流程图；

图6为本发明实施例提供的定时任务处理方法的交互图；

图7为本发明实施例提供的定时任务处理装置实施例一的结构示意图；

图8为与图7所示实施例提供的定时任务处理装置对应的电子设备的结构示意图；

图9为本发明实施例提供的定时任务处理装置实施例二的结构示意图；

图10为与图9所示实施例提供的定时任务处理装置对应的电子设备的结构示意图。

具体实施方式

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

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应当理解，尽管在本发明实施例中可能采用术语第一、第二、第三等来描述XXX，但这些XXX不应限于这些术语。这些术语仅用来将XXX区分开。例如，在不脱离本发明实施例范围的情况下，第一XXX也可以被称为第二XXX，类似地，第二XXX也可以被称为第一XXX。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

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

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

在一实际应用场景中，用户在终端设备中输入定时任务对应的消息，终端设备将消息发送至服务端的定时任务处理系统中，以使得定时任务处理系统对该消息进行消费处理，并将得到的处理结果反馈至终端设备。其中，终端设备是相对于定时任务处理系统而言的，是指请求该定时任务处理系统进行定时任务处理的设备，可以是手机、平板电脑、PC机、服务器等电子设备。其中，本发明实施例中提及的消息的消费可以理解为是通过消息的使用来实现定时任务的处理。在该场景中，位于服务端的定时任务处理系统的组成可以如图1所示：

包括至少一个消息队列的消息存储子系统，以及与每个消息队列对应的至少一个消息消费子系统。

其中，消息队列用于存储消息，该消息对应于定时任务，即将定时任务转换为消息存储于消息队列中；消息消费子系统用于从对应的消息队列中拉取消息，并对消息进行消费。

在对消息进行消费的过程中，可能会需要调用定时任务涉及的业务系统，如图1中所示。

其中，本发明实施例中的消息存储子系统也可以称为消息发布/订阅系统，消息队列也可以称为消息服务器。该子系统可以基于Kafka、Redis、MetaQ等平台或中间件实现。

可选地，每个消息消费子系统可以实现为一个物理设备，可以通过该物理设备中的多个进程对消息进行消费处理。

但是，可选地，每个消息消费子系统还可以采用流式计算的方式对消息进行消费处理，此时，该消息消费子系统也可以称为流式计算子系统，用于对消息进行实时流式消费处理，可以采用诸如Storm、Jstorm、Flink、Spark Streaming等流式计算平台实现。此时，每个消息消费子系统可能对应于多个物理设备中的多个进程。基于此，本发明实施例中可以采用消息和流式计算的方式解决定时调度问题，即进行定时任务的处理，将传统的定时任务转换为轻量级的消息，通过对消息进行处理实现对定时任务的处理。

该定时任务处理系统的工作过程，概括来说为，当消息存储子系统从终端设备接收到与某个定时任务对应的消息后，将该消息存入到至少一个消息队列中的一个消息队列中，假设为第一消息队列中。进而，与该第一消息队列对应的消息消费子系统从该第一消息队列中拉取其中存储的消息，假设当前拉取到该消息，则若根据当前时间与该消息的下一次执行时间之间的第一时间差确定当前需要消费该消息，则根据该消息的业务参数消费该消息，将消费该消息得到的定时任务处理结果发送至终端设备。

在一可选实施例中，消息存储子系统在接收到终端设备发送的消息后，可以随机从多个消息队列中选择一个消息队列存入该消息，也可以按照各消息队列中已存入消息的数量从中选择具有最少消息数量的消息队列存入该消息。

在另一可选实施例中，可以预先为每个消息队列设定对应的时间级别，该时间级别的作用可以简单描述为：对消息按照其对应的时间级别进行归类存储，即对应于某时间级别的消息需要被存入该时间级别对应的消息队列中存储。另外，不同时间级别的消息队列对应的消息消费子系统的初始数量可以是不同的，具体表现为1：N的对应关系。举例来说，时间级别可以包括：秒、分钟、小时、天。可以初始设定一个秒级消息队列对应的消息消费子系统的数量为20个(1:20)，一个分钟级消息队列对应的消息消费子系统的数量为10个(1:10)，一个小时级消息队列对应的消息消费子系统的数量为5个(1:5)，一个天级消息队列对应的流式计算子系统的数量为1个(1:1)。

另外，对应于不同时间级别的消息消费子系统从对应的消息队列中拉取消息的频率也可以是不同的，比如秒级消息队列的拉取频率为1秒钟拉取一次，高于拉取频率为1分钟拉取一次的分钟级消息队列。

由于在一些实际应用中，对应于不同时间级别的定时任务的数量往往不同，比如，秒级、分钟级、小时级、天级的定时任务的数量可能呈现依次递减的特征，此时，根据不同时间级别对应的定时任务数量，为不同时间级别的消息队列设置不同数量的消息消费子系统，可以保证有充分的资源对消息进行消费处理。因此，若某消息队列对应的时间级别表示定时任务的执行频率越频繁，则该消息队列对应的消息消费子系统的数量越多。

基于此，可以理解的是，如果在消息消费的过程中，发现某时间级别的消息的负载量很大，则此时可以动态地增加相应的消息消费子系统即可，从而能够保证定时任务的并发处理效率。

在对定时任务处理系统的组成以及工作过程进行上述简单介绍之后，下面对定时任务对应的消息的组成以及消息的详细消费处理过程进行说明。

本发明实施例中提及的定时任务可以理解为是需要在指定时间或按照指定时间间隔进行作业的任务，比如：周一至周五的上午8点提醒起床；从当前时间起倒计时30分钟内，每隔15秒推送一条音频。

当用户需要触发一个定时任务时，可以在终端设备的相关配置界面中对该定时任务进行消息配置，以便生成与该定时任务对应的消息。本发明实施例中的消息可以理解为是一个消息体，可选地，该消息体中可以包含如下多个字段：

运行类型：是指定时任务对应的定时运行类型，可以划分为：按照指定时间运行、周期运行、按照指定运行次数运行这几种类型。值得说明的是，有的定时任务可能同时符合不同运行类型，此时，可以择一选择一种运行类型即可。

指定时间：是指定时任务对应的运行时间的约束。当运行类型为按照指定时间运行时，该指定时间即为用户指定的特定运行时间，比如定时任务为：在周三的上午十点和下午三点时提醒我开会，此时，指定时间即为周三上午十点以及周三下午三点，可选地，不同的指定时间可以采用分号分割开。当运行类型为周期运行或按照指定运行次数运行时，该指定时间可以以cron表达式来表示，其中，cron表达式的含义参见现有技术中的介绍，在此不赘述，本实施例中仅指出cron表达式可以包含定时任务的执行起始时间、结束时间、时间间隔等相关执行时间信息。

执行次数：是指定时任务剩余的执行次数，即还需要执行多少次才能执行完毕。

业务参数：是指定时任务处理过程中需要使用的业务信息，定时任务的处理过程中以此业务参数进行业务逻辑处理。该业务参数比如是定时任务执行过程中需要调用的某个业务系统、某个被调用的服务信息、需要访问的某个网页的链接地址等等。

创建时间：是指该消息对应的创建时间。

上一次执行时间：是指消息上一次被处理即被消息的时间，初始情况下，可以默认与创建时间一致。

下一次执行时间：是指消息下一次需要被处理的时间，可以结合前述指定时间以及上一次执行时间来确定。

时间级别：是指定时任务的执行频率所对应的时间粒度。可以划分为秒、分钟、小时、天等时间级别。一般地，针对运行类型为周期运行或按照指定运行次数运行的类型，该时间级别可以根据相邻的上一次执行时间和下一次执行时间的时间差即根据相邻两次执行定时任务的时间间隔来确定，比如每隔十分钟执行一次，则时间级别为分钟；每隔15秒执行一次，则时间级别为秒。而对于运行类型为按照指定时间运行的类型，该时间级别的确定与定时任务对应的指定时间的个数有关或者说与定时任务对应的执行次数有关。举例来说，比如定时任务为：周五上午九点提醒我。该按照指定时间运行的类型对应的指定时间为周五上午九点，执行次数为1次，此时，可以根据创建时间与该指定时间的时间差确定该定时任务所对应的时间级别。再比如，定时任务为：周三的上午十点和下午三点时提醒我开会，此时，指定时间包括周三上午十点以及周三下午三点，执行次数为2次，此时，可以根据定时任务对应的多个指定时间之间的最小时间差确定该定时任务所对应的时间级别。

也就是说，对于属于按照指定时间运行这一类型的定时任务所对应的时间级别的确定：若该定时任务对应的指定时间为1个，则根据该定时任务对应的消息的创建时间与该指定时间的时间差确定时间级别；若该定时任务对应的指定时间大于或等于2个，则根据该定时任务对应的多个指定时间的时间差确定时间级别。

另外，可选地，上述时间差与时间级别的对应关系可以是：

若时间差大于或等于25小时，则对应的时间级别为天；

若时间差大于或等于2小时而小于25小时，则对应的时间级别为小时；

若时间差大于或等于2分钟而小于60分钟，则对应的时间级别为分钟；

其余情况即若时间差小于2分钟，则对应的时间级别为秒。

在终端设备侧生成包含上述字段的消息之后，终端设备将得到的消息发送至服务端的定时任务处理系统。其中的消息存储子系统接收到该消息后，可以解析该消息以获得其中包含的时间级别，进而将该消息存入与该时间级别对应的消息队列中。

本发明实施例中，根据消息涉及到的时间级别对消息队列进行划分，使得某个时间级别的消息队列仅用于存储该时间级别的消息，从而实现对消息按照时间级别进行归类。进而，只有订阅某时间级别消息的消息消费子系统才能对该时间级别的消息进行消费，同一消息消费子系统只用于消费一个时间级别的消息。

针对任一消息消费子系统来说，当其从对应的某个消息队列中拉取到某个定时任务对应的消息之后，对该消息的消费处理过程可以包括：

首先，基于该消息的下一次执行时间与当前时间的时间差确定当前是否需要消费该消息，即当前是否满足定时任务的执行时间需要执行该定时任务。如果当前时间与下一次执行时间一致，则说明需要立即消费该消息，此时，根据该消息的业务参数消费该消息，以完成一次定时任务的处理。其中，消息消费子系统中可以被预先设置为封装有定时任务对应的业务处理逻辑，此时，消息消费子系统运行该业务处理逻辑，以业务参数作为业务处理逻辑的输入参数，执行该业务处理逻辑以完成定时任务的处理，比如该业务参数为存储有某个音频的存储地址，业务处理逻辑为读取该存储地址中的音频。在得到此次定时任务的处理结果后，将该处理结果比如读取到的音频发送至终端设备，终端设备进行播放，以实现定时播放提醒音频的定时任务。

前面提到，为了提高消息消费的处理效率，适应高并发定时任务的应用场景，本发明实施例中的消息消费子系统可以采用流式计算的架构实现。下面结合图2介绍一种消息消费子系统的组成，该消息消费子系统是基于Storm架构实现的，此时，该消息消费子系统也可以称为消费拓扑，具体包括两类节点：数据源节点(spout)以及自数据源节点流式连接的至少一层处理节点(subBolt)，比如图2中所示的第一层处理节点subBolt1、第二层处理节点subBolt2。

如图2中所示，横向看，处理节点可以被配置为多层结构，纵向看，同一层的处理节点可以设置有多个，各节点之间的连接关系可以自定义设定，节点之间若具有连接，则表明消息可以沿该连接进行流动。处理节点被预先封装有一定的业务处理逻辑，不同层的处理节点的业务处理逻辑不同，同一层处理节点的业务处理逻辑相同。

举例来说，假设某定时任务是每隔一定时间获取某数据库中某物品的购买数量。此时，消息中包含的业务参数可以包括该数据库标识、物品标识以及合并索引—用户所在列标识。此时，该消息消费子系统的工作过程为：数据源节点从对应的消息队列中拉取消息，比如按照先入先出的顺序依次拉取消息队列中的消息，假设当前拉取到的消息即为上述定时任务对应的消息，在根据当前时间与该消息的下一次执行时间之间的时间差确定当前需要消费该消息时，将该消息传递至下一层处理节点，即第一层处理节点。进而，各第一层处理节点根据自己的业务处理逻辑，结合业务参数中的数据库标识从该数据库中提取出该时间内存入的数据记录；各第二层处理节点根据自己的业务处理逻辑，结合业务参数中的物品标识，对流入自己的第一层处理节点提取结果进行数据筛选，以筛选出相应物品的数据记录，进而，将筛选出的数据记录反馈给终端设备。

值得说明的是，上述各层处理节点可以理解为是逻辑概念，相当于工作进程，并非严格限定是物理设备，从而，一个消息消费子系统可以由分布在不同物理设备中的多个工作进程组成。

本实施例中，仅就消息消费系统基于当前时间与拉取到的消息的下一次执行时间确定当前需要消费该消息的情况下，如果对消息进行消费的过程进行了说明，而如果确定当前不需要消费该消息的情况下，如果如何对该消息进行处理将在后续的方法实施例中详细介绍，此时，对该消息进行处理的主体可以是消息消费子系统中的数据源节点，也可以是第一层处理节点。

综上介绍，本发明实施例中，将重量级的定时任务转换为轻量级的消息存入消息存储子系统的某个消息队列中，进而基于消息中包含的相关参数对消息进行消费，从而将对定时任务的处理转换为对消息的处理。相比于传统的基于数据库的定时任务处理模式，本发明实施例中采用消息系统代替了数据库，将定时任务转换为消息，对消息的处理无需进行加锁、解锁，在高并发的定时任务场景中，可以提高定时任务并发处理效率。另外，消息消费子系统可以采用流式计算架构实现，从而在定时任务的任务量很大的情况下，可以动态扩展计算资源——消息消费子系统数量以及消息消费子系统中处理节点的数量，以保证定时任务的并发处理效率。

下面以消息消费子系统的角度，对本发明实施例提供的定时任务处理方法进行详细介绍。

图3为本发明实施例提供的定时任务处理方法实施例一的流程图，如图1所示，该方法包括如下步骤：

101、从第一消息队列中拉取定时任务对应的消息，消息中包括定时任务的下一次执行时间、业务参数和执行次数。

如前述实施例中所说，该消息中还包括诸如时间级别等其他相关信息。其中，上述第一消息队列可以是与该消息的时间级别对应的消息队列。

102、若根据当前时间与下一次执行时间之间的第一时间差确定当前需要消费消息，则根据业务参数消费消息。

拉取到该消息的时间即为当前时间，若当前时间与消息中当前包含的下一次执行时间一致，则确定当前需要消费该消息。

103、将消费消息得到的定时任务处理结果发送至定时任务对应的终端设备。

上述消息的获取过程以及消息消费的过程可以参见前述系统实施例中的介绍，在此不再赘述。

104、更新消息的下一次执行时间和执行次数。

针对某个消息来说，在每消费一次该消息之后，需要更新该消息，主要是指更新该消息中包含的下一次执行时间和执行次数。其中，执行次数的更新可用是执行减一运行，即每消费一次，执行次数减1。而下一次执行时间的更新可用是根据消息中的指定时间来确定的。具体来说，针对按照指定时间运行这一类型的定时任务来说，假设该定时任务对应的指定时间包括T1；T2两个时间，且假设当前消费该消息时对应的下一次执行时间为T1，则在当前消费完该消息后，下一次执行时间更新为T2。而针对周期类型或按照指定次数运行的定时任务来说，更新后的下一次执行时间即为当前的下一次执行时间叠加上cron表达式中所对应的执行时间间隔的结果。

105、若更新后的执行次数未达到执行截止条件，则将更新后的消息投递到消息队列中。

对应于上述执行次数的更新机制，该执行截止条件可以为执行次数更新为0。若更新后的执行次数达到执行截止条件即更新后的执行次数为0，意味着该消息对应的定时任务已经最终完成，则可以丢弃该消息。

相反地，如果更新后的执行次数未达到执行截止条件即更新后的执行次数不为0，则需要将更新后的消息再次投递到消息存储子系统中，以便对该消息进行下一次的消费处理。

可选地，本实施例中，在将上述更新后的消息投递回消息存储子系统中时，可以直接将该更新后的消息投递回原来的消息队列，即第一消息队列。

但是，可选地，还可以根据当前时间与更新后的下一次执行时间之间的第二时间差确定需要将该更新后的消息投递至哪个时间级别的消息队列中。

具体地，根据当前时间与更新后的下一次执行时间之间的第二时间差所对应的第二时间级别确定是否需要更换消息队列；若需要，则将更新后的消息投递到与第二时间级别对应的第三消息队列中；若不需要，则将更新后的消息投递回原来的第一消息队列中。

可选地，上述第二时间差与第二时间级别的对应关系可以是：

若第二时间差大于或等于25小时，则对应的第二时间级别为天；

若第二时间差大于或等于2小时而小于25小时，则对应的第二时间级别为小时；

若第二时间差大于或等于2分钟而小于60分钟，则对应的第二时间级别为分钟；

其余情况即若第二时间差小于2分钟，则对应的第二时间级别为秒。

本实施例中，针对某个消息来说，根据当前时间与该消息下一次执行时间的时间差，动态地调整消息归属的消息队列，以此保证消息以较低的延迟被处理，因为不同时间级别的消息队列所对应的消息消费子系统的数量是不同的，对应于更多数量的消息消费子系统的消息队列中的消息会被更及时地处理。

图4为本发明实施例提供的定时任务处理方法实施例二的流程图，如图4所示，可以包括如下步骤：

201、从第一消息队列中拉取定时任务对应的消息，消息中包括定时任务的下一次执行时间。

202、若根据当前时间与下一次执行时间之间的第一时间差确定当前不需要消费消息，则根据第一时间差所对应的第一时间级别确定是否需要更换消息队列，若需要，则执行步骤203，若不需要，则执行步骤204。

203、将消息投递到与第一时间级别对应的第二消息队列中。

204、将消息投递到第一消息队列中。

本实施例中，与第一消息队列对应的某个消息消费子系统从该第一消息队列中拉取到某个消息，如果当前时间与该消息的下一次执行时间之间的第一时间差为零，则说明当前需要消费该消息，从而根据该消息的业务参数对该消息进行消费处理。反之，如果当前时间与该消息的下一次执行时间之间的第一时间差不为零，则说明当前不需要消费该消息，此时，可选地，可以将该消息投递回该第一消息队列。

但是，可选地，此时还可以基于第一时间差对该消息进行消息队列的更换处理，是否需要更换消息队列是基于第一时间差所对应的第一时间级别是否与第一消息队列的时间级别一致确定的。若第一时间级别与第一消息队列的时间级别一致，则说明不需更换消息队列，从而将该消息投递回第一消息队列中。若第一时间级别与第一消息队列的时间级别不同，则说明需更换消息队列，从而将该消息投递回与第一时间级别对应的第二消息队列中。其中，第一时间级别与第一时间差的对应关系参考上述第二时间级别与第二时间差的对应关系。

上述第一时间差反映了还有多久就需要消费该消息，随着该时间差的变化，动态地调整该消息对应的消息队列，以保证该消息以更低的延迟被处理。

下面结合图5，以终端设备的角度，对本发明实施例提供的定时任务处理方法进行介绍。

图5为本发明实施例提供的定时任务处理方法实施例三的流程图，如图5所示，可以包括如下步骤：

301、生成与定时任务对应的消息，消息中包括定时任务的下一次执行时间和业务参数。

该消息中还可以包括诸如定时任务的运行类型、指定时间、时间级别、执行次数等信息。

可选地，实际应用中，在终端设备侧可以提供一配置界面，在该配置界面中用户可以根据自己实际需要触发的定时任务选择与该定时任务对应的运行类型。进而，响应于用户选择的运行类型，可以显示与该运行类型对应的指定时间设置界面，在该设置界面上提示用户需要输入的指定时间信息。比如，假设运行类型为按照指定时间运行，此时，该设置界面中提示用户顺次输入执行时间；假设运行类型为按照指定运行次数运行或周期运行，此时，该设置界面中提示用户顺次输入执行起始时间、执行结束时间以及时间间隔。

进而，基于用户在设置界面中输入端额指定时间信息，生成与指定时间对应的cron表达式，进而确定执行次数、下一次执行时间、时间级别。

另外，上述配置界面中还提供业务参数输入项，以供用户输入与定时任务对应的业务参数。

302、将消息发送至服务端的定时任务处理系统，以使定时任务处理系统将消息存入消息队列，并在从消息队列中拉取到消息时，根据下一次执行时间和业务参数对消息进行消费。

303、接收定时任务处理系统发送的消费消息得到的定时任务处理结果。

本实施例中未尽的描述可以参见图1所示实施例的描述，在此不赘述。

图6为本发明实施例提供的定时任务处理方法的交互图，如图6所示，可以包括如下步骤：

401、终端设备生成与定时任务对应的消息X，消息X中包括定时任务的下一次执行时间、业务参数和时间级别。

402、终端设备将生成的消息X发送至消息存储子系统。

403、消息存储子系统将消息X存入与时间级别对应的消息队列A中。

404、消息消费子系统从消息队列A中拉取消息X。

405、消息消费子系统若根据当前时间与消息X的下一次执行时间之间的第一时间差确定当前不需要消费消息X，则根据第一时间差将消息X投递到对应时间级别的消息队列中。

406、消息消费子系统若根据当前时间与消息X的下一次执行时间之间的第一时间差确定当前需要消费消息X，则根据消息的业务参数消费消息。

407、消息消费子系统将消费消息X得到的定时任务处理结果发送至定时任务对应的终端设备。

408、消息消费子系统更新消息X的下一次执行时间和执行次数。

409、若更新后的执行次数未达到执行截止条件，则消息消费子系统根据当前时间与更新后的下一次执行时间之间的第二时间差将更新后的消息X投递到对应时间级别的消息队列中。

以下将详细描述本发明的一个或多个实施例的定时任务处理装置。本领域技术人员可以理解，这些定时任务处理装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图7为本发明实施例提供的定时任务处理装置实施例一的结构示意图，如图7所示，该装置包括：获取模块11、消费模块12、发送模块13。

获取模块11，用于从第一消息队列中拉取定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数。

消费模块12，用于若根据当前时间与所述下一次执行时间之间的第一时间差确定当前需要消费所述消息，则根据所述业务参数消费所述消息。

发送模块13，用于将消费所述消息得到的定时任务处理结果发送至所述定时任务对应的终端设备。

可选地，所述消息中还包括所述定时任务的时间级别，所述消息被根据所述时间级别存入所述第一消息队列中。

可选地，不同消息队列对应的时间级别不同，所述时间级别包括：秒、分钟、小时、天。

可选地，该装置还包括：第一投递处理模块14。

第一投递处理模块14，用于若根据所述第一时间差确定当前不需要消费所述消息，则根据所述第一时间差所对应的第一时间级别确定是否需要更换消息队列；若需要，则将所述消息投递到与所述第一时间级别对应的第二消息队列中；若不需要，则将所述消息投递到所述第一消息队列中。

可选地，所述消息中还包括所述定时任务的执行次数；该装置还包括：更新模块15、第二投递处理模块16。

更新模块15，用于在根据所述业务信息消费所述消息之后，更新所述下一次执行时间和所述执行次数；

第二投递处理模块16，用于若更新后的执行次数未达到执行截止条件，则将更新后的消息投递到消息队列中；若更新后的执行次数达到所述执行截止条件，则丢弃所述消息。

可选地，所述第二投递处理模块16具体用于：

根据当前时间与更新后的下一次执行时间之间的第二时间差所对应的第二时间级别确定是否需要更换消息队列；若需要，则将所述更新后的消息投递到与所述第二时间级别对应的第三消息队列中；若不需要，则将所述更新后的消息投递到所述第一消息队列中。

图7所示装置对应于图1或图2所示的消息消费子系统，可以执行图3、图4所示实施例的方法，本实施例未详细描述的部分，可参考对图3、图4所示实施例的相关说明。该技术方案的执行过程和技术效果参见图3、图4所示实施例中的描述，在此不再赘述。

以上描述了定时任务处理装置的内部功能和结构，在一个可能的设计中，定时任务处理装置的结构可实现为一电子设备，如图8所示，该电子设备可以包括：处理器21和存储器22。其中，所述存储器22用于存储支持定时任务处理装置执行上述图1、图3所示实施例中提供的定时任务处理方法的程序，所述处理器21被配置为用于执行所述存储器22中存储的程序。

所述程序包括一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器21执行时能够实现如下步骤：

从第一消息队列中拉取定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

若根据当前时间与所述下一次执行时间之间的第一时间差确定当前需要消费所述消息，则根据所述业务参数消费所述消息；

将消费所述消息得到的定时任务处理结果发送至所述定时任务对应的终端设备。

可选地，所述处理器21还用于执行前述图3、图4所示实施例中的全部或部分步骤。

其中，所述定时任务处理装置的结构中还可以包括通信接口23，用于定时任务处理装置与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存定时任务处理装置所用的计算机软件指令，其包含用于执行上述图3、图4所示方法实施例中定时任务处理方法所涉及的程序。

图9为本发明实施例提供的定时任务处理装置实施例二的结构示意图，该装置位于终端设备中，如图9所示，该装置包括：生成模块31、发送模块32、接收模块33。

生成模块31，用于生成与定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数。

发送模块32，用于将所述消息发送至服务端的定时任务处理系统，以使所述定时任务处理系统将所述消息存入消息队列，并在从所述消息队列中拉取到所述消息时，根据所述下一次执行时间和所述业务参数对所述消息进行消费。

接收模块33，用于接收所述定时任务处理系统发送的消费所述消息得到的定时任务处理结果。

可选地，所述消息中还包括所述定时任务的时间级别，所述时间级别用于使得所述定时任务处理系统将所述消息存入与所述时间级别对应的所述消息队列中。

图9所示装置可以执行图5所示实施例的方法，本实施例未详细描述的部分，可参考对图5所示实施例的相关说明。该技术方案的执行过程和技术效果参见图5所示实施例中的描述，在此不再赘述。

以上描述了定时任务处理装置的内部功能和结构，在一个可能的设计中，定时任务处理装置的结构可实现为一电子设备，如图10所示，该电子设备可以包括：处理器41和存储器42。其中，所述存储器42用于存储支持定时任务处理装置执行上述图5所示实施例中提供的定时任务处理方法的程序，所述处理器41被配置为用于执行所述存储器42中存储的程序。

所述程序包括一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器41执行时能够实现如下步骤：

生成与定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

将所述消息发送至服务端的定时任务处理系统，以使所述定时任务处理系统将所述消息存入消息队列，并在从所述消息队列中拉取到所述消息时，根据所述下一次执行时间和所述业务参数对所述消息进行消费；

接收所述定时任务处理系统发送的消费所述消息得到的定时任务处理结果。

可选地，所述处理器41还用于执行前述图5所示实施例中的全部或部分步骤。

其中，所述定时任务处理装置的结构中还可以包括通信接口43，用于定时任务处理装置与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存定时任务处理装置所用的计算机软件指令，其包含用于执行上述图5所示方法实施例中定时任务处理方法所涉及的程序。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (14)

1.一种定时任务处理方法，其特征在于，包括：

从第一消息队列中拉取定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

若根据当前时间与所述下一次执行时间之间的第一时间差确定当前需要消费所述消息，则根据所述业务参数消费所述消息；

将消费所述消息得到的定时任务处理结果发送至所述定时任务对应的终端设备。

2.根据权利要求1所述的方法，其特征在于，所述消息中还包括所述定时任务的时间级别，所述消息被根据所述时间级别存入所述第一消息队列中。

3.根据权利要求2所述的方法，其特征在于，不同消息队列对应的时间级别不同，所述时间级别包括：秒、分钟、小时、天。

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

若根据所述第一时间差确定当前不需要消费所述消息，则根据所述第一时间差所对应的第一时间级别确定是否需要更换消息队列；

若需要，则将所述消息投递到与所述第一时间级别对应的第二消息队列中；

若不需要，则将所述消息投递到所述第一消息队列中。

5.根据权利要求2所述的方法，其特征在于，所述消息中还包括所述定时任务的执行次数；

所述根据所述业务信息消费所述消息之后，还包括：

更新所述下一次执行时间和所述执行次数；

若更新后的执行次数未达到执行截止条件，则将更新后的消息投递到消息队列中；

若更新后的执行次数达到所述执行截止条件，则丢弃所述消息。

6.根据权利要求5所述的方法，其特征在于，所述将更新后的消息投递到消息队列中，包括：

根据当前时间与更新后的下一次执行时间之间的第二时间差所对应的第二时间级别确定是否需要更换消息队列；

若需要，则将所述更新后的消息投递到与所述第二时间级别对应的第三消息队列中；

若不需要，则将所述更新后的消息投递到所述第一消息队列中。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述从第一消息队列中拉取定时任务对应的消息，包括：

通过与所述第一消息队列对应的消息消费子系统中的数据源节点从所述第一消息队列中拉取所述消息；

所述消息消费子系统中还包含自所述数据源节点流式连接的至少一层处理节点，所述至少一层处理节点被预先封装有业务处理逻辑；

所述根据所述业务参数消费所述消息，包括：

结合所述业务参数，依次通过所述至少一层处理节点的业务处理逻辑消费所述消息，所述业务参数作为所述业务处理逻辑的输入参数。

8.一种定时任务处理方法，其特征在于，包括：

生成与定时任务对应的消息，所述消息中包括所述定时任务的下一次执行时间和业务参数；

将所述消息发送至服务端的定时任务处理系统，以使所述定时任务处理系统将所述消息存入消息队列，并在从所述消息队列中拉取到所述消息时，根据所述下一次执行时间和所述业务参数对所述消息进行消费；

接收所述定时任务处理系统发送的消费所述消息得到的定时任务处理结果。

9.根据权利要求8所述的方法，其特征在于，所述消息中还包括所述定时任务的时间级别，所述时间级别用于使得所述定时任务处理系统将所述消息存入与所述时间级别对应的所述消息队列中。

10.一种定时任务处理系统，其特征在于，包括：

包括至少一个消息队列的消息存储子系统，以及与每个所述消息队列对应的至少一个消息消费子系统；

所述消息存储子系统，用于将从终端设备接收到的与定时任务对应的消息存入所述至少一个消息队列中的第一消息队列中，所述消息中包括所述定时任务的下一次执行时间和业务参数；

与所述第一消息队列对应的目标消息消费子系统，用于执行权利要求1至7中任一项所述的定时任务处理方法。

11.根据权利要求10所述的系统，其特征在于，所述目标消息消费子系统中包括：

数据源节点以及自所述数据源节点流式连接的至少一层处理节点，所述至少一层处理节点被预先封装有业务处理逻辑；

所述数据源节点，用于从所述第一消息队列中拉取所述消息，并在根据当前时间与所述下一次执行时间之间的第一时间差确定当前需要消费所述消息时，将所述消息传递至下一层处理节点；

所述至少一层处理节点，用于结合所述业务参数，依次根据各自对应的业务处理逻辑消费所述消息，所述业务参数作为所述业务处理逻辑的输入参数。

12.根据权利要求10所述的系统，其特征在于，对应于不同时间级别的消息队列各自对应的消息消费子系统的初始数量不同。

13.一种电子设备，其特征在于，包括存储器和处理器；其中，

所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现如权利要求1至7中任一项所述的定时任务处理方法。

14.一种电子设备，其特征在于，包括存储器和处理器；其中，

所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现如权利要求8至9中任一项所述的定时任务处理方法。

Images