CN106874079A - 一种任务执行的方法及装置 - Google Patents

Abstract

本申请公开了一种任务执行的方法及装置，该方法中服务器在接收到用户发送的业务请求后，可生成对应该业务请求的定时任务，服务器在执行该定时任务后可根据该定时任务的属性，确定出该业务请求对应的下一个定时任务，直至该业务请求对应的各定时任务全部执行为止。服务器在确定各定时任务的执行时间时，不是按照固定的时间间隔决定各定时任务的执行时间，而是根据定时任务的属性，确定出各定时任务的执行时间，这样就给用户在业务处理时带来了方便，并且，服务器不是将对应业务请求的各定时任务一次性全部生成出来的，而是先生成一个定时任务，当执行完该定时任务后，再去生成该业务请求对应的下一个定时任务，这样，就节省了服务器的存储空间。

Description

一种任务执行的方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种任务执行的方法及装置。

背景技术

随着计算机技术的不断发展，各种业务相继融入到人们的生活中，这些业务使得人们在日常生活中可以独自处理个人事务，提升了人们自行解决问题的能力，为人们的日常生活带来了极大的方便。

服务器在对业务进行执行时通常都是通过任务的驱动来完成的，即，服务器在对该业务进行执行时，实际上是对该业务对应的任务进行了执行，进而完成了该业务的执行，其中，这里提到的任务是服务器针对该业务而生成的，换句话说，服务器完成了该任务的执行后，实际上就完成了该业务的执行。而在实际应用中，由于业务上的需求，服务器在对一些业务进行执行之前，需要针对该业务生成若干个任务，并为每个任务都设置一个执行时间，因此，这些任务则相应的变成了各定时任务，继而服务器在对该业务进行执行时，可以根据每个定时任务的执行时间，依次对各个定时任务进行执行，进而完成该业务的执行。

例如，假设服务器接收到用户发送的业务请求后，根据该业务请求，确定出了待执行的业务A，而后，服务器可针对该业务A一次性的生成4个定时任务R1、R2、R3、R4，同时为这4个定时任务分别设置了执行时间T1、T2、T3、T4(T1到T4在时间上是依次增大的)，并将这4个定时任务以及各定时任务所对应的执行时间进行存储。随后，服务器可按照一定的时间间隔对存储的各定时任务进行扫描，当扫描出任务R1的执行时间T1到达了当前服务器的系统时间时，则可调取该任务R1进行执行，同理，当服务器的当前系统时间分别到达定时任务R2、R3、R4的执行时间时，服务器可依次调取出这三个定时任务进行执行，并当依次执行完这4个定时任务后，相应的完成了业务A的执行。

然而，在实际应用中，服务器在对一个业务对应的各定时任务分别设置执行时间时，通常都是按照固定时间间隔设置的。继续沿用上例，服务器对定时任务R1、R2、R3、R4依次设置的执行时间的时间间隔都是相同的，这样一来，若服务器设置的时间间隔较短，服务器则会相对频繁的执行这4个定时任务，若设置的时间间隔较长，服务器在对这4个定时任务进行执行时，过程则会相对缓慢，而实际应用中，用户有时希望服务器能够根据业务以及用户的需要来依次执行各定时任务，例如，假设用户登录到购票网站来进行购票，服务器相应的可根据用户的操作，生成一个针对该用户此次操作的购票业务，并针对该购票业务生成了4个定时任务，而由于用户在购票网站上进行购票时，通常在购票初期都较为着急，因此，用户通常希望服务器在对这4个定时任务进行执行时，能够对前几个定时任务执行的稍快些(或用户购票后期较为着急，则希望服务器能够对这4个定时任务的后几个定时任务执行的稍快些)。但是，服务器针对该购票业务而生成的这4个定时任务在时间间隔上却都是相同的，倘若，这些时间间隔与用户的期望相比都较长，则服务器在对这4个定时任务进行执行时，前几个定时任务较用户的期望相比也将执行的稍慢一些，这样一来，服务器则将不能达成用户的期望，从而给用户在进行业务处理时带来不便。不仅如此，在实际应用中，服务器在对业务进行执行时，需要将针对该业务生成的若干定时任务依次执行完，才算完成该业务的执行，然而，服务器在执行完该业务对应的某一定时任务后，实际上可能已经完成了该业务的执行，例如，就上述示例而言，服务器在完成第2个定时任务的执行后，实际上已经完成了购票业务的执行，但是，服务器却依然需要将该购票业务对应的后2个定时任务依次执行一遍后，才认定该购票业务执行完成，进而才会向用户返回该购票业务的执行结果，这就极大了浪费了服务器的资源，并且，由于服务器在对业务进行执行时，通常都需要将该业务对应的定时任务一次性的全部生成出来，并存储这些定时任务，这就极大的占用了服务器的存储空间，从而给服务器的运行造成了负担。

发明内容

本申请实施例提供一种任务执行的方法，用于解决现有技术中服务器在对业务进行执行时会给用户带来不便，并浪费资源、占用存储空间的问题。

本申请实施例提供一种任务执行的装置，用于解决现有技术中服务器在对业务进行执行时会给用户带来不便，并浪费资源、占用存储空间的问题。

本申请实施例采用下述技术方案：

本申请实施例提供一种任务执行的方法，包括：

接收用户发送的业务请求；

根据所述业务请求，生成所述业务请求对应的定时任务并存储；

当所述定时任务的执行时间到达时，执行所述定时任务；

根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，直至所述业务请求对应的各定时任务全部执行为止，其中，所述业务请求对应多个相同的定时任务。

本申请实施例提供一种任务执行的装置，包括：

接收模块，接收用户发送的业务请求；

生成模块，根据所述业务请求，生成所述业务请求对应的定时任务并存储；

执行模块，当所述定时任务的执行时间到达时，执行所述定时任务；

确定模块，根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，直至所述业务请求对应的各定时任务全部执行为止，其中，所述业务请求对应多个相同的定时任务。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

由于本申请实施例中，服务器在接收到用户发送的业务请求后，可根据该业务请求，生成相应的定时任务并存储，并当监测该定时任务的到达执行时间时，执行该定时任务，与此同时，服务器可根据该定时任务的属性，确定出该业务请求对应的下一个定时任务的执行时间，进而根据确定出的执行时间，生成与该定时任务相同的下一个定时任务，直到该业务请求对应的各定时任务全部执行为止。从上述方法可以看出，由于服务器生成该业务请求对应的各定时任务时并不是按照固定的时间间隔依次确定各定时任务的执行时间，而是在生成对应该业务请求的一个定时任务后，根据该定时任务的属性来决定该业务请求对应的下一个定时任务的执行时间的，其中，定时任务的属性可以反映该业务以及用户的需要，这样一来，服务器将不再按照固定的时间间隔来确定各定时任务的执行时间，而是可根据具体的业务需要以及用户需要来确定各定时任务的执行时间，从而给用户在进行业务处理时带来了方便。不仅如此，由于服务器并不是将该业务请求对应的定时任务一次性全部生成出来的，而是执行一个定时任务，生成一个定时任务，这样就极大的节省了服务器的存储空间，提高了服务器的运行效率，并且，服务器在对该业务请求进行执行时，不再需要等到该业务请求对应的各定时任务全部执行完后才完成该业务请求的执行，而是可根据定时任务的执行结果，来确定该业务请求是否完成，并当确定该业务请求已经完成时及时停止后续定时任务的生成，这样就极大的避免了服务器在对该业务请求进行执行时，资源浪费的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的任务执行的过程；

图2为本申请实施例提供的任务执行的整个系统示意图；

图3为本申请实施例提供的一种任务执行的装置示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请实施例提供的任务执行的过程，具体包括以下步骤：

S101：接收用户发送的业务请求。

用户由于日常生活中的自身需要，通常都需要使用所持有的终端来进行业务处理，因此，在本申请实施例中，用户可在所持有的终端上完成指定的操作，而终端则可根据用户所执行的指定操作，生成相应的业务请求，进而将该业务请求发送给能够执行该业务请求的服务器，其中，这里提到的终端可以是电脑、智能手机等终端设备。当然，用户也可在用户终端中的客户端上完成指定的操作，并由客户端将根据用户操作而生成的业务请求发送给该客户端对应的服务器。

S102：根据所述业务请求，生成所述业务请求对应的定时任务并存储。

在实际应用中，服务器在对用户发送的业务请求进行执行时，通常都是通过任务的驱动来完成的，即，服务器执行该业务请求时，实际上是对该业务请求对应的定时任务进行了执行，相应的，服务器在完成了该定时任务的执行后，实际上也就完成了该业务请求的执行。而通常情况下，一个业务请求通常都会对应多个定时任务，换句话说，服务器通常都会针对一个业务请求而生成多个定时任务，并且，这些定时任务往往都是相同的。这样一来，服务器后续在对该业务请求进行执行时，可以按照各定时任务的执行时间依次执行各个任务，进而完成该业务请求的执行。

然而，在现有技术中，服务器通常都是一次性的将该业务请求对应的各定时任务全部生成出来的，而由于服务器需要将生成的这些定时任务都进行存储，并当各定时任务的执行时间依次到达时，才会依次执行各定时任务，因此，若服务器将该业务请求对应的各定时任务一次性的全部生成出来并存储，则将极大的占用了服务器的存储空间，给服务器的运行带来了负担。所以，为了避免这一情况的发生，在本申请实施例中，服务器在接收到用户发送的业务请求后，可根据该业务请求，生成该业务请求对应的一个定时任务并存储，即，服务器可通过解析该业务请求的方式，生成与该业务请求对应的一个定时任务并存储。由于服务器在接收到用户发送的业务请求后，并不是将该业务请求对应的各定时任务全部生成出来的，而是先生成对应该业务请求的一个定时任务并存储，这样就极大的节省了服务器的存储空间，降低了服务器的运行负担。

需要说明的是，服务器在生成对应上述业务请求的定时任务时，可根据服务器当前的系统时间来确定该定时任务的执行时间，也可根据服务器中存储的其他定时任务的执行时间来确定该定时任务的执行时间，具体的确定方式在此不做进一步的限定。

S103：当所述定时任务的执行时间到达时，执行所述定时任务。

在实际应用中，服务器针对接收到的业务请求而生成定时任务相当于将该业务请求也进行了定时，因此，在本申请实施例中，服务器可按照一定的时间间隔，扫描服务器中存储的各定时任务，并当扫描到某一定时任务的执行时间到达时，则可捞取该定时任务并将其进行执行，换句话来说，服务器扫描存储的各定时任务发现，服务器当前的系统时间已经到达或超过了某一定时任务的执行时间，则服务器可确定出后续(立即)需要执行该定时任务，进而捞取该定时任务并执行。

需要说明的是，服务器通常都会接收到各个用户发送的业务请求，相应的，服务器也将生成对应各业务请求的定时任务并存储，也就是说，服务器通常都会存储大量的定时任务，而在这些定时任务中，有些定时任务是已经执行过的，而有些定时任务则是没有进行执行的，其中，服务器存储执行过的定时任务的目的在于，服务器在完成一个业务请求的执行后，通常都会将该业务请求对应的各定时任务保留一段时间，以防后续该业务请求的执行结果出现异常时，能够通过保留的该业务请求对应的各定时任务校验该执行结果。

而服务器通常都是按照一定的时间间隔来扫描各定时任务的，所以也就无法避免有些定时任务的执行时间恰巧出现在每次扫描的间隔中，这样，服务器也就无法准时的执行这些定时任务。相应的，当服务器后续扫描到这些定时任务时，发现这些定时任务的执行时间以及小于了服务器当前的系统时间，则服务器可确定出这些定时任务属于已经超时的定时任务，进而捞取这些定时任务并执行。但是，由于服务器中还会存储一些执行过的定时任务，因此，这些执行过的定时任务的执行时间也应当是小于服务器当前的系统时间的，所以，若服务器不对各定时任务的执行状态进行区分，则可能会重新捞取已经执行过的定时任务，进而使得服务器在对业务请求进行执行时，极大的浪费资源。

为了避免上述情况的发生，在本申请实施例中，服务器在生成对应上述业务请求的定时任务后，可对该定时任务的执行状态进行标记，即，可将该定时任务的执行状态标记为第一执行状态，而服务器后续在完成该定时任务的执行后，可将该定时任务的执行状态更新为第二执行状态、这样一来，服务器即可有效的区分出存储的各定时任务中，哪些是已经执行过的定时任务，哪些是还未执行的定时任务，进而使得服务器当扫描到执行状态为第一执行状态、且到达执行时间的定时任务时，捞取该定时任务并执行，其中，这里提到的第一执行状态可以是诸如未完成、未执行、未启动等状态，而第二执行状态可以是已完成、已执行、启动过、关闭等状态。

例如，假设服务器在接收到用户发送的业务请求后，可通过解析该业务请求，来生成对应该业务请求的一个定时任务并存储，其中，服务器在生成该定时任务的过程中，监测到服务器当前的系统时间为2016/5/11/08/23/46(即2016年5月11日8点23分46秒)，因此，服务器可将该定时任务的执行时间定为2016/5/11/14/23/46，与此同时，服务器可将该定时任务的执行状态标记为未启动状态(即第一执行状态)。而后，服务器按照一定的时间间隔扫描存储的各定时任务发现，执行状态为未启动的该定时任务的执行时间已经小于(早于)服务器当前的系统时间2016/5/11/14/24/16，即，服务器在2016/5/11/14/24/16时扫描到执行状态为未启动状态的该定时任务时发现，服务器当前的系统时间已经超过了该定时任务的执行时间，则服务器可确定该定时任务为一个超时的任务，进而捞取该定时任务并执行。

需要说明的是，在现有技术中，服务器通常需要将针对上述业务请求而生成的各定时任务都全部执行过后，才认定该业务请求完成执行，然而，在实际应用中，服务器可能在执行完该业务请求的某一个定时任务后，实际上已经完成了该业务请求的执行，但是由于服务器规定需要将该业务请求对应的各定时任务全部执行一遍后，才算完成该业务请求的执行，因此，服务器依然还会对该业务请求剩余的定时任务进行执行，进而浪费了服务器的资源。

为了避免上述问题的发生，在本申请实施例中，服务器在执行完一个定时任务后，可根据该定时任务的执行结果，来对上述业务请求(即该定时任务对应的业务请求)的执行状态进行更新，即，当服务器执行该定时任务后得到的执行结果为成功执行时，则可将预先记录的该业务请求的执行状态更新为已完成状态。而当服务器执行该定时任务后得到的执行结果为失败时，则可将预先记录的该业务请求的执行状态更新为未完成状态。相应的，服务器在执行该业务请求的下一个定时任务时，可在执行之前根据该业务请求的执行状态，判断该业务请求是否已经完成了执行，进而根据判断结果来决定是否需要继续执行该业务请求对应的定时任务，其中，当服务器根据该业务请求的执行状态，判断出该业务请求未完成时，则可对该定时任务进行执行，而当服务器判断出该业务请求已经完成时，则可不再执行该定时任务，并且，不再生成与该定时任务相同的、对应该业务请求的定时任务。当然，上述业务请求的未完成状态也可是由其他的情况造成的，如未启动该业务请求、执行该业务请求出错等。

例如，假设服务器在接收到用户发送的业务请求后，发现该业务请求是一个新的业务请求(即，之前没有接收到过与这一业务请求相同的业务请求)，因此，服务器可将该业务请求的执行状态标记为未完成状态，同时，服务器可根据该业务请求，生成对应该业务请求的一个定时任务并存储。而后，服务器在执行该定时任务之前发现，该定时任务对应的业务请求是一个未完成的业务请求(即，该业务请求的执行状态为未完成状态)，因此，服务器可对该定时任务进行执行，并根据该定时任务的执行结果，来对该业务请求的执行状态进行更新，其中，当该定时任务的执行结果为失败时，服务器则可将该业务请求的执行状态更新为未完成，或直接不对该业务请求的执行状态进行更新，相应的，服务器在后续过程中，可根据该定时任务的属性，确定出该业务请求对应的下一个定时任务的执行时间并存储，进而生成一个与该定时任务相同的定时任务；而当该定时任务的执行结果为成功时，则服务器可确定该业务请求已经完成了执行，进而将该业务请求的执行状态更新为已完成状态，同时不再生成对应该业务请求的定时任务。其中，这里提到的相同的定时任务是指内容相同，但执行时间不同的定时任务。

S104：根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，直至所述业务请求对应的各定时任务全部执行为止，其中，所述业务请求对应多个相同的定时任务。

由于本申请实施例意在使服务器可以根据业务的实际情况以及用户的需求来确定各定时任务的执行时间，即，不再按照固定的时间间隔来生成对应上述业务请求的各定时任务，因此，在本申请实施例中，服务器在执行完该业务请求对应的定时任务后，可根据该定时任务的属性，来确定出该业务请求对应的下一个定时任务的执行时间并存储，其中，这里提到的定时任务的属性是指：在实际应用中，用户在进行业务处理时，可能希望服务器能够在特定的时间段内能够尽快的向用户返回该业务的执行结果，或是希望服务器在接收到该业务请求的初期，能够快速的对该业务请求进行执行，并将该业务请求的执行结果返回给用户，相应的，为了满足该业务以及用户的需求，服务器在确定各定时任务的执行时间时，需要对这些因素加以考虑，继而将各定时任务的执行时间确定的更为合理一些(即，将各定时任务的时间间隔确定的更为合理一些)，因此，服务器在生成该业务请求对应的定时任务之前，可预先统计用户针对这类业务的需求情况，以及用户希望服务器能够怎样处理这类的业务，进而根据统计出的数据，来确定出这一类业务对应的定时任务的属性。这样一来，服务器后续在生成对应该业务请求的定时任务后，可根据该定时任务的属性，确定出该业务请求对应的下一个定时任务的执行时间并存储。

具体的，服务器在对该定时任务进行执行之前，可先根据该定时任务对应的业务请求的执行状态，判断该业务请求是否已经完成执行，其中，当服务器判断该业务请求未完成执行时，则可对该定时任务进行执行，并根据该定时任务的执行结果，更新该业务请求对应的执行状态。而服务器在执行该定时任务后发现，该定时任务对应的业务请求没有相应的完成，则服务器可确定出需要生成对应该业务请求的下一个定时任务，以使得服务器通过执行该下一个定时任务，来继续执行该业务请求。其中，服务器在生成对应该业务请求的下一个定时任务时，可先确定出该业务请求的业务类型，进而根据确定出的业务类型，确定该业务请求对应的下一个定时任务的执行时间并存储，此举的目的在于，对于不同的业务来说，用户对其的需求状况往往也是不同的，例如，对于业务A来说，用户希望服务器能够在每天8点到10点这段时间内快速完成该业务，而其他时间段则不太着急，而对于业务B来说，用户希望服务器能够在每天的19点到20点这段时间内快速完成该业务，而其他时间段则不太着急，因此，服务器在对业务请求对应的定时任务进行执行时，需要根据该业务请求的业务类型，来确定如何制定该定时任务的执行时间，换句话说，服务器需要根据该业务请求的业务类型，确定该如何设置各定时任务的时间间隔。

服务器在确定出上述业务请求的业务类型后，可根据该业务类型，确定与该业务类型相匹配的，系统时间与时间间隔的对应关系，进而根据确定出的系统时间与时间间隔的对应关系，以及服务器当前的系统时间，确定出该业务请求对应的下一个定时任务的执行时间并存储，其中，这里提到的系统时间与时间间隔的对应关系可以是服务器预先通过统计各用户针对该类业务的需求状况而确定出的，也可以是服务器通过该类业务的实际执行状况来确定的，如表1所示。

系统时间	时间间隔(s)
		00:00:00-03:00:00	50s
03:00:00-06:00:00	40s
		06:00:00-09:00:00	20s
09:00:00-12:00:00	25s
		12:00:00-15:00:00	30s
15:00:00-18:00:00	25s
		18:00:00-21:00:00	5s
21:00:00-00:00:00	15s

表1

从表1中可以看出，各时间段对应的时间间隔都是不同的，也就是说，服务器根据如表1所示的系统时间与时间间隔的对应关系而确定出的对应一个业务请求的各定时任务的时间间隔也将不会是完全相同的，从表1中可以进一步的看出，当服务器认为在18:00:00-21:00:00这段时间内需要快速执行用户发送的业务请求时，则可将该业务请求对应的各定时任务的时间间隔设置的小一些，换句话来说，服务器认为在18:00:00-21:00:00这段时间内用户希望服务器能够快速的完成该业务请求的执行并返回相应的执行结果，则服务器可在这一段时间内，将该业务请求对应的各定时任务的时间间隔设置的小一些，而服务器认为在00:00:00-03:00:00这段时间内用户并不要求服务器能够快速的返回该业务请求的执行结果，则在这段时间内，服务器可将该业务请求对应的各定时任务的时间间隔设置的稍大一些。

当然，服务器也可根据该业务的类型，来确定出系统时间与时间间隔的对应关系，例如，假设服务器发现某一业务在晚间的7点到9点这段时间内，业务请求的数据是最多的，则服务器可认定大多数的用户需要在这段时间内完成该业务的处理工作，因此，为了满足用户的需求，服务器可将这段时间内的各定时任务的时间间隔设置的小一些，相应的，服务器可根据这种方法，依次确定出各时间段内各定时任务的时间间隔，进而得出该系统时间与时间间隔的对应关系。

需要说明的是，服务器除了可以根据系统时间与时间间隔的对应关系，来确定所述业务请求对应的下一个定时任务的执行时间外，还可以根据定时任务生成次数与时间间隔的对应关系，确定出该业务请求对应的下一个定时任务的执行时间并存储。具体的，在实际应用中，用户在向服务器发送业务请求时，有时希望服务器能够快速的执行该业务请求对应的前几个定时任务，而不要求服务器能够快速的执行该业务请求对应的后几个定时任务，因此，可根据用户的需求，来确定出该定时任务生成次数与时间间隔的对应关系，如表2所示。

定时任务生成次数	时间间隔(s)
		第一次	2s
第二次	2s
		第三次	4s
第四次	5s

表2

从表2中可以看出，针对一个业务请求来说，该业务请求对应的各定时任务的执行时间是与该定时任务是针对该业务请求的第几次定时任务有密切关系的，服务器根据用户的需求发现，用户在对这类业务进行处理时，通常希望服务器能够快速的执行该业务请求对应的前两个定时任务，而不要求服务器能够快速的执行该业务请求对应的后几个定时任务，因此，服务器在接收到用户发送的业务请求后，可先确定出需要5个定时任务来完成该业务请求的执行，而服务器在生成对应该业务请求的定时任务时，可先生成对应该业务请求的一个定时任务，并根据该定时任务的属性，确定出该业务请求对应的下一个定时任务对应的执行时间并存储，其中，服务器在确定该业务请求对应的下一个定时任务时，可根据该业务请求的业务类型，确定出与该业务类型相匹配的，定时任务生成次数与时间间隔的对应关系，并根据该对应关系、服务器当前的系统时间以及该下一个定时任务的生成次数，确定出该业务请求对应的下一个定时任务的执行时间，根据表2可知，服务器在确定出该定时任务为针对该业务请求第一次生成的定时任务时，则认定用户希望服务器在完成该定时任务的执行后，能够快速的完成下一个定时任务(即服务器针对该业务请求第二次生成的定时任务)的执行，相应的，服务器可根据定时任务生成次数与时间间隔的对应关系(即表2)，确定出针对该业务请求第二次生成的定时任务与第一次生成的定时任务之间的时间间隔为2s，同理，服务器可根据该对应关系，依次确定出各定时任务之间的时间间隔，进而确定出各定时任务的执行时间。

除此之外，服务器还可以根据该业务请求的内容，确定出该业务请求对应的各定时任务与时间间隔的对应关系，进而根据该对应关系、以及服务器当前的系统时间，确定出该业务请求对应的下一个定时任务的执行之间并存储。具体的，用户向服务器发送的业务请求中所包含的内容，在一定程度上能够反映出用户对该业务请求的需要状况，例如，假设用户向服务器发送了一个充值12元(即将账号余额中的12元转入到与该账号绑定的银行卡中)的业务请求后，服务器可通过对该业务请求的分析得出，该用户可能急于将这12元钱转入至该用户账号所绑定的指定银行卡中，以便能够从该银行卡中取出整百数目的金额，因此，服务器可进一步的确定出该用户可能希望服务器能够尽快的完成该业务请求的执行，并将执行结果返回给用户。所以，服务器在接收到该业务请求后，将针对该业务请求生成一个定时任务，后续过程中，若服务器确定该定时任务未执行成功时，则可根据该业务请求所包含的内容，以及预设的算法，计算出一个对应该内容的数值，而后，服务器可根据该业务请求对应的业务类型，确定出与该业务请求相匹配的，数值与时间间隔的对应关系，继而，服务器可根据该对应关系、确定出的数值以及服务器当前的系统时间，确定出该业务请求对应的下一个定时任务的执行时间并存储。其中，这里提到的预设算法可以是服务器预先根据大量的数据，通过预设的训练模型得出的，而不同的业务类型可针对不同的预设算法。

例如，假设用户向服务器发送了一个充值12元的业务请求(即，将账号余额中的12元钱转入到与该账号绑定的指定银行卡中)后，服务器可根据该业务请求，生成对应该业务请求的一个定时任务并存储，随后，服务器在执行该定时任务时，并没有成功的完成该定时任务的执行，进而也就没有成功的完成该业务请求的执行。为了能够进一步的完成该业务请求的执行，服务器可针对该业务请求而生成对应该业务请求的下一个定时任务并存储，其中，服务器在生成对应该业务请求的下一个定时任务时，可先确定出该业务请求对应的业务类型，进而选取出与该业务类型相匹配的预设算法，而后，服务器可根据该业务请求所包含的内容以及选取的预设算法，计算出对应该内容的一个数值，而后，服务器可再根据确定出的业务类型，确定出数值与时间间隔的对应关系，如表3所示。

数值范围	时间间隔
		0～20	5s、4s、7s、8s、20s
20～40	4s、5s、6s、7s、10s
		40～60	3s、2s、3s、5s、8s
60～80	2s、3s、2s、4s、5s
		80～100	2s、1s、1s、2s、3s

表3

表3即为数值与时间间隔的对应关系表，从表3中可以看出，服务器根据上述业务请求的内容计算出对应该内容的数值88后，可在表3中找到与数值88相匹配的时间间隔，进而根据该时间间隔，生成该业务请求对应的下一个定时任务并存储。

当然，服务器在计算上述数值的过程中，也可将该业务请求当前对应的定时任务的生成次数作为一个计算因子而加入到数值的计算过程中，这样一来，服务器根据该业务请求的内容，以及该业务请求当前定时任务的生成次数而计算出的表征该业务请求内容的数值，能够更加合理的反映出用户对于该业务请求的需要程度，进而根据预设的数值与时间间隔的对应关系，合理的确定出该业务请求对应的下一个定时任务的执行时间并存储，其中，该数值与时间间隔的对应关系如表4所示。

表4

从表4中可以看出，不同的数值均对应一个不同的时间间隔，这样一来，由于服务器每次根据该业务请求内容以及该业务请求当前定时任务对应的生成次数而计算出的数值都是不同的，换句话说，由于定时任务的生成次数不同，则服务器计算出的对应各定时任务的数值也就不同，因此，服务器可根据数值与时间间隔的对应关系，确定出该业务请求对应的各定时任务的时间间隔，从而能够更加合理完成该业务请求的执行。

需要说明的是，上述提到的表1～表4只是为了清楚的说明各种对应关系，而并不对本申请中提到的各种对应关系进行限定，上述提到的能够确定出定时任务执行时间的各种对应关系可以基于表1～表4进行相应的修改，在此不做进一步的限定。同时，上述说明的能够确定业务请求对应的下一个定时任务执行时间的方式并不仅仅包含上述的几种方式，能够确定出该业务请求对应的下一个定时任务执行时间而得到时间间隔不同的各定时任务的方式应均包含在本申请实施例所保护的范围内，而对于其他方式，在此就不进行详细说明了。

从上述方法中可以看出，由于服务器在确定各定时任务的执行时间时，并不是按照固定的时间间隔依次决定各定时任务的执行时间的，而是根据定时任务的属性，来确定出各定时任务的执行时间的，其中，各定时任务的时间间隔可以是不固定的。由于定时任务的属性能够在一定程度上反映出用户以及业务上的需求，因此，通过定时任务的属性而确定出的各定时任务的执行时间能够在一定程度上满足用户以及业务的需求，给用户进行业务处理时带来了方便。不仅如此，由于服务器并不是将对应业务请求的各定时任务一次性全部生成出来的，而是先生成对应该业务请求的一个定时任务，并当执行完该定时任务后，再去生成该业务请求对应的下一个定时任务，这样，就极大的节省了服务器的存储空间，降低了服务器的运行负担。并且，由于服务器可根据该业务请求的执行状态，来确定是否对该业务请求后续的定时任务进行执行，因此，当服务器确定该业务请求进行完成执行时，则不再生成并执行该业务请求对应的定时任务，相比与现有技术来说，可有效的节省服务器的资源，提高服务器业务执行的效率。

需要说明的是，上述方法中的执行定时任务和存储定时任务的执行主体可以分别由两个系统来完成，即，业务系统可负责定时任务的执行，而调度系统可负责定时任务的存储以及调度工作，具体过程如图2所示。

图2为本申请实施例提供的任务执行的整个系统示意图。

在图2中，业务系统可接收用户发送的业务请求，并根据该业务请求，生成对应该业务请求的一个定时任务，其中，业务系统在生成该定时任务时，可以根据业务系统的当前系统时间，为该定时任务确定出一个期望的执行时间。而后，业务系统可通知调度系统为其生成的定时任务分配存储空间，进而将该定时任务录入到调度系统中进行存储。与此同时，业务系统可对该业务请求的执行状态进行标记，例如，当业务系统首次接收该业务请求时，则可将该业务请求的执行状态标记为未执行、未完成等状态。

调度系统在接收到该定时任务后，可对该定时任务的执行状态进行标记，例如，调度系统首次接收该定时任务时，则可将该定时任务的执行状态标记为未执行、未完成等状态。而后，调度系统可按照固定的时间间隔扫描其存储的各定时任务，当扫描到执行状态为未执行、未完成等状态、且执行时间不大于调度系统当前系统时间的定时任务时，则捞取该定时任务，同时通过发送消息的方式通知业务系统调度该定时任务，其中，调度系统向业务系统发送的消息中包含有该定时任务的任务标识(如任务编号等)，这样，业务系统在接收到调度系统发送的消息后，可根据该消息中包含的任务标识，从调度系统中调度该定时任务。

业务系统调度该定时任务后，可根据预先标记的该业务请求的执行状态，判断该业务请求是否已经完成执行，若是，则不再执行该定时任务，同时通知调度系统更新该定时任务的执行状态，使得后续调度系统扫描到该定时任务时，不再捞取该定时任务，若业务系统判断出该业务请求没有完成执行时，则可进一步的判断该定时任务的调度次数是否已经到达预设的次数，若是，则直接执行该定时任务，进而完成该业务请求的执行，若否，则在执行完该定时任务后，根据该定时任务的属性，确定出该业务请求对应的下一个定时任务的执行时间，并相应的生成该下一个定时任务，与此同时，业务系统可通知调度系统存储该下一个定时任务，使得调度系统在接收到业务系统发送的通知后，存储该下一个定时任务。业务系统在执行完该定时任务后，可将该定时任务对应的业务请求的执行状态进行更新，并相应的通知调度系统将该定时任务的执行状态进行更新，进而完成一次调度任务的执行工作。同理，业务系统和调度系统可通过相同的方式完成该业务请求对应的其他定时任务的执行工作，完成整个业务请求的执行工作。

还需说明的是，本申请实施例可适用于大多数的任务调度的场景中，其中，对于掉单的场景尤为的适用，具体的任务执行过程上面已经详细介绍过来，在此就不进行详细赘述了。

以上为本申请实施例提供的任务执行的方法，基于同样的思路，本申请实施例还提供了任务执行的装置，如图3所示。

图3为本申请实施例提供的一种任务执行的装置示意图，具体包括：

接收模块301，接收用户发送的业务请求；

生成模块302，根据所述业务请求，生成所述业务请求对应的定时任务并存储；

执行模块303，当所述定时任务的执行时间到达时，执行所述定时任务；

确定模块304，根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，直至所述业务请求对应的各定时任务全部执行为止，其中，所述业务请求对应多个相同的定时任务。

当所述执行模块303执行所述定时任务之前，所述生成模块302，将生成的所述定时任务的执行状态标记为第一执行状态；

所述执行模块303，扫描预先存储的各定时任务；当扫描到执行状态为第一执行状态、且到达执行时间的定时任务时，捞取所述定时任务并执行。

所述装置还包括：

更新模块305，根据所述定时任务的执行结果，更新所述业务请求的执行状态。

所述执行模块303执行所述定时任务之前，根据所述业务请求对应的执行状态，确定所述业务请求未完成。

当所述执行模块303确定所述业务请求已完成时，则不再执行所述定时任务，且不再生成所述定时任务。

所述确定模块304，确定所述业务请求的业务类型；根据确定出的业务类型，确定系统时间与时间间隔的对应关系，其中，所述对应关系是与所述业务类型相匹配的；根据所述系统时间与时间间隔的对应关系以及当前的系统时间，确定所述业务请求对应的下一个定时任务的执行时间并存储。

所述确定模块304，确定所述业务请求的业务类型；根据确定出的业务类型，确定定时任务生成次数与时间间隔的对应关系，其中，所述对应关系是与所述业务类型相匹配的；根据所述定时任务生成次数与时间间隔的对应关系、当前的系统时间以及所述下一个定时任务的生成次数，确定所述业务请求对应的下一个定时任务的执行时间并存储。

本申请实施例提供一种任务执行的方法及装置，该方法中服务器在接收到用户发送的业务请求后，可根据该业务请求，生成对应该业务请求的一个定时任务并存储，当该定时任务的执行时间到达时，执行该定时任务，而后，服务器可根据该定时任务的属性，确定出该业务请求对应的下一个定时任务并存储，直至该业务请求对应的各定时任务全部执行为止。由于服务器在确定各定时任务的执行时间时，并不是按照固定的时间间隔依次决定各定时任务的执行时间的，而是根据定时任务的属性，来确定出各定时任务的执行时间的，其中，各定时任务的时间间隔可以是不固定的。由于定时任务的属性能够在一定程度上反映出用户以及业务上的需求，因此，通过定时任务的属性而确定出的各定时任务的执行时间能够在一定程度上满足用户以及业务的需求，给用户进行业务处理时带来了方便。不仅如此，由于服务器并不是将对应业务请求的各定时任务一次性全部生成出来的，而是先生成对应该业务请求的一个定时任务，并当执行完该定时任务后，再去生成该业务请求对应的下一个定时任务，这样，就极大的节省了服务器的存储空间，降低了服务器的运行负担。并且，由于服务器可根据该业务请求的执行状态，来确定是否对该业务请求后续的定时任务进行执行，因此，当服务器确定该业务请求进行完成执行时，则不再生成并执行该业务请求对应的定时任务，相比与现有技术来说，可有效的节省服务器的资源，提高服务器业务执行的效率。

需要说明的是，实施例1所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤S101和步骤S102的执行主体可以为第一服务器，步骤103的执行主体可以为第二服务器；又比如，步骤101的执行主体可以为第一服务器，步骤102和步骤103的执行主体可以为第二服务器；等等。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

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

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

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

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

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

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种任务执行的方法，其特征在于，包括：

接收用户发送的业务请求；

根据所述业务请求，生成所述业务请求对应的定时任务并存储；

当所述定时任务的执行时间到达时，执行所述定时任务；

根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，直至所述业务请求对应的各定时任务全部执行为止，其中，所述业务请求对应多个相同的定时任务。

2.如权利要求1所述的方法，其特征在于，执行所述定时任务之前，所述方法还包括：

将生成的所述定时任务的执行状态标记为第一执行状态；

当所述定时任务的执行时间到达时，执行所述定时任务，具体包括：

扫描预先存储的各定时任务；

当扫描到执行状态为第一执行状态、且到达执行时间的定时任务时，捞取所述定时任务并执行。

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

根据所述定时任务的执行结果，更新所述业务请求的执行状态。

4.如权利要求3所述的方法，其特征在于，执行所述定时任务之前，所述方法还包括：

根据所述业务请求对应的执行状态，确定所述业务请求未完成。

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

当确定所述业务请求已完成时，则不再执行所述定时任务，且不再生成所述定时任务。

6.如权利要求1所述的方法，其特征在于，根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，具体包括：

确定所述业务请求的业务类型；

根据确定出的业务类型，确定系统时间与时间间隔的对应关系，其中，所述对应关系是与所述业务类型相匹配的；

根据所述系统时间与时间间隔的对应关系以及当前的系统时间，确定所述业务请求对应的下一个定时任务的执行时间并存储。

7.如权利要求1所述的方法，其特征在于，根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，具体包括：

确定所述业务请求的业务类型；

根据确定出的业务类型，确定定时任务生成次数与时间间隔的对应关系，其中，所述对应关系是与所述业务类型相匹配的；

根据所述定时任务生成次数与时间间隔的对应关系、当前的系统时间以及所述下一个定时任务的生成次数，确定所述业务请求对应的下一个定时任务的执行时间并存储。

8.一种任务执行的装置，其特征在于，包括：

接收模块，接收用户发送的业务请求；

生成模块，根据所述业务请求，生成所述业务请求对应的定时任务并存储；

执行模块，当所述定时任务的执行时间到达时，执行所述定时任务；

确定模块，根据所述定时任务的属性，确定所述业务请求对应的下一个定时任务的执行时间并存储，直至所述业务请求对应的各定时任务全部执行为止，其中，所述业务请求对应多个相同的定时任务。

9.如权利要求8所述的装置，其特征在于，当所述执行模块执行所述定时任务之前，所述生成模块，将生成的所述定时任务的执行状态标记为第一执行状态；

所述执行模块，扫描预先存储的各定时任务；当扫描到执行状态为第一执行状态、且到达执行时间的定时任务时，捞取所述定时任务并执行。

10.如权利要求8所述的装置，其特征在于，所述装置还包括：

更新模块，根据所述定时任务的执行结果，更新所述业务请求的执行状态。

11.如权利要求10所述的装置，其特征在于，所述执行模块执行所述定时任务之前，根据所述业务请求对应的执行状态，确定所述业务请求未完成。

12.如权利要求11所述的装置，其特征在于，当所述执行模块确定所述业务请求已完成时，则不再执行所述定时任务，且不再生成所述定时任务。

13.如权利要求8所述的装置，其特征在于，所述确定模块，确定所述业务请求的业务类型；根据确定出的业务类型，确定系统时间与时间间隔的对应关系，其中，所述对应关系是与所述业务类型相匹配的；根据所述系统时间与时间间隔的对应关系以及当前的系统时间，确定所述业务请求对应的下一个定时任务的执行时间并存储。

14.如权利要求8所述的装置，其特征在于，所述确定模块，确定所述业务请求的业务类型；根据确定出的业务类型，确定定时任务生成次数与时间间隔的对应关系，其中，所述对应关系是与所述业务类型相匹配的；根据所述定时任务生成次数与时间间隔的对应关系、当前的系统时间以及所述下一个定时任务的生成次数，确定所述业务请求对应的下一个定时任务的执行时间并存储。