CN103197969B

CN103197969B - 一种分布式定时任务控制装置及方法

Info

Publication number: CN103197969B
Application number: CN201310102698.3A
Authority: CN
Inventors: 安海雄; 高巍; 邬晶
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2013-03-27
Filing date: 2013-03-27
Publication date: 2017-02-08
Anticipated expiration: 2033-03-27
Also published as: CN103197969A

Abstract

本发明提出了一种分布式定时任务控制装置，包括：接收模块，用于接收定时任务Cron的指令；数据库模块，用于保存Cron记录，其中，每个所述Cron记录具有对应的当前状态信息；多个调度模块，用于分别根据调度时间表对数据库模块中的Cron记录进行调度，当Cron记录满足调度时间表之后，根据所述Cron记录对应的当前状态信息将Cron记录放置到执行队列中；执行模块，用于执行执行队列之中的Cron记录。本发明可以处理高并发的Cron任务，只与用户相关，使用者可以使用应用程序之外的URL作为定时任务的地址，更加灵活方便。本发明还提出了一种分布式定时任务控制方法。

Description

一种分布式定时任务控制装置及方法

技术领域

本发明涉及云开发技术领域，特别涉及一种分布式定时任务控制装置及方法。

背景技术

Cron，计划任务，是任务在约定的时间执行已经计划好的工作。例如，可以在配置文件中约定每天早上4点将httpd服务器重新启动，每天晚上10点钟给某个邮箱发一封信，都是计划任务。

在Linux系统中，计划任务一般是由cron承担，cron可以根据配置文件约定的时间来执行特定的任务。将cron设置为开机时自动启动。cron启动后，它会读取它的所有配置文件，如全局性配置文件/etc/crontab，以及每个用户的计划任务配置文件，然后cron会根据命令和执行时间来按时来调用度工作任务。

cron可以在无需人工干预的情况下运行作业，但是缺点在于不提供任何形式的API，只能通过应用的配置文件来配置Cron任务，局限于应用内部使用，缺少了灵活性。

发明内容

本发明旨在至少在一定程度上解决上述技术问题之一或至少提供一种有用的商业选择。

为此，本发明的第一个目的在于提出一种分布式定时任务控制装置，可以提供一种分布式的Cron处理系统，可以处理高并发的Cron任务，只与用户相关，使用者可以使用应用程序之外的URL作为定时任务的地址，更加灵活方便。

本发明的第二个目的在于提出一种分布式定时任务控制方法。

为达到上述目的，本发明第一方面的实施例提出了一种分布式定时任务控制装置，包括：接收模块，用于接收定时任务Cron的指令；数据库模块，用于保存Cron记录，其中，每个所述Cron记录具有对应的当前状态信息；多个调度模块，用于分别根据调度时间表对所述数据库模块中的Cron记录进行调度，当Cron记录满足所述调度时间表之后，根据所述Cron记录对应的当前状态信息将所述Cron记录放置到执行队列中；执行模块，用于执行所述执行队列之中的Cron记录。

根据本发明实施例的分布式定时任务控制装置，提供了一种分布式的Cron装置，可以处理高并发的Cron任务，用户可以同时创建并运行多个Cron，提供了友好的SDK和HTTP接口，只与用户相关，不依赖于应用，使用者可以使用应用程序之外的URL作为定时任务的地址，更加灵活方便。

在本发明的一个实施例中，每个所述Cron记录还具有对应的执行状态信息，所述执行模块根据所述执行状态信息执行所述执行队列之中的Cron记录。

在本发明的一个实施例中，所述当前状态信息包括活跃状态、结束状态、删除状态、暂停状态和配额超限状态中的一种或多种。

在本发明的一个实施例中，所述多个调度模块对处于活跃状态的Cron记录进行调度。

在本发明的一个实施例中，其特征在于，所述执行状态信息包括就绪状态、调度状态和运行状态。

在本发明的一个实施例中，当所述调度模块将Cron记录放置到所述执行队列中之后，将所述Cron记录的执行状态信息修改为调度状态。

在本发明的一个实施例中，当所述Cron记录的执行状态信息为调度状态或运行状态时，所述执行模块不执行所述Cron记录。

在本发明的一个实施例中，所述调度模块还用于在Cron记录超时之后，将所述Cron记录丢弃。

在本发明的一个实施例中，所述数据库包括多个子数据库，且每个子数据库包括多个数据列表。

本发明第二方面实施例提出了一种分布式定时任务控制方法，包括以下步骤：接收定时任务Cron的指令并保存，其中每个所述Cron记录具有对应的当前状态信息；根据调度时间表对数据库模块中的Cron记录进行调度；当所述Cron记录满足所述调度时间表时，根据所述Cron记录对应的当前状态信息将所述Cron记录放置到执行队列中；执行所述执行队列之中的Cron记录。

根据本发明实施例的分布式定时任务控制方法提供了一种分布式的Cron实现方案，可以处理高并发的Cron任务，用户可以同时创建并运行多个Cron，提供了友好的SDK和HTTP接口，只与用户相关，不依赖于应用，使用者可以使用应用程序之外的URL作为定时任务的地址，更加灵活方便。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明所述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本发明一个实施例的分布式定时任务控制装置的结构示意图；

图2a为根据本发明一个实施例的调度模块的抓取的示意图；

图2b为根据本发明一个实施例的调度模块发送任务至执行队列的示意图；

图3为根据本发明一个实施例的调度模块的内部结构示意图；

图4为根据本发明一个实施例的恢复Cron记录的流程图；

图5为根据本发明一个实施例的正常调度Cron记录的流程图；

图6为根据本发明一个实施例的调度超时Cron记录的流程图；

图7为根据本发明一个实施例的调度超时到下一执行时刻Cron记录的流程图；

图8为根据本发明一个实施例的处理运行超时Cron记录的流程图；

图9为根据本发明一个实施例的执行执行队列中Cron记录的流程图；和

图10为根据本发明一个实施例的分布式定时任务控制方法的流程图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

如图1所示，本发明第一方面实施例提出的分布式定时任务控制装置包括接收模块110、数据库模块120、多个调度模块130和执行模块140。

其中，接收模块110用于接收定时任务Cron的指令；数据库模块120用于保存Cron记录，其中，每个Cron记录具有对应的当前状态信息；多个调度模块130用于分别根据调度时间表对数据库模块120中的Cron记录进行调度，当Cron记录满足调度时间表之后，根据Cron记录对应的当前状态信息将Cron记录放置到执行队列中；执行模块140用于执行执行队列之中的Cron记录。

其中，当前状态信息包括活跃状态、结束状态、删除状态、暂停状态和配额超限状态中的一种或多种。执行状态信息包括就绪状态、调度状态和运行状态。根据执行状态信息执行执行队列之中的Cron记录。调度状态，如task_status＝DISPATCH，表示Cron记录已经被推送至执行队列，但是还没有被执行。运行状态，如task_status＝RUNNING，表示Cron记录已经被从执行队列取走并开始执行。其中，只有处于活跃状态下的当前状态信息是可被调度的。数据库包括多个子数据库，且每个子数据库包括多个数据列表。

在本发明的一个实施例中，多个调度模块130对处于活跃状态的Cron记录进行调度。当调度模块130将Cron记录放置到执行队列中之后，将Cron记录的执行状态信息修改为调度状态。当Cron记录的执行状态信息为调度状态或运行状态时，执行模块140不执行Cron记录。调度模块130还用于在Cron记录超时之后，将Cron记录丢弃。

每个Cron记录还具有对应的执行状态信息，执行模块140根据执行状态信息执行执行队列之中的Cron记录。

下面以一个具体的实施例对根据本发明实施例的分布式定时任务控制装置进行说明，可以理解的是，下述说明仅出于示例目的，本发明的实施例不限于此。

接收模块110属于对外接口，多个调度模块130和执行模块140属于调度部分。调度部分为本装置的核心模块，负责对用户提交的Cron任务按照时间表进行调度；对外接口提供的功能包括：创建，删除，修改，暂停，重启，查询，显示所有Cron，查询历史等。调度部分和对外接口通过数据库进行交互。接口模块将Cron数据写入数据库。调度模块130根据这些数据调度Cron记录。其中，数据库包括多个子数据库，且每个子数据库包括多个数据列表。

本装置有如下规则：一次任务是指Cron记录的某一次执行。任务过时未被调度，则直接放弃调度。调度的过程是指任务在执行队列上等待线程去调度。

接收模块110接收定时任务Cron的指令，指令包括创建，删除，修改，暂停，重启，查询，显示Cron记录。数据库模块120保存Cron记录，其中每个Cron记录具有对应的当前状态信息。

多个调度模块130根据调度时间表对数据库模块120中的Cron记录进行调度。

进一步地，多个调度模块130从数据库抓取符合要求的cron记录，其中，符合要求包括抓取处于就绪状态、调度超时状态、运行超时状态、休息状态的Cron记录。一个Cron记录可以被多个调度模块130抓取。如图2a所示，T_cron*表为cron记录表，有调度模块1、2、3抓取cron1。但是多个调度模块130同时调度一个Cron记录会造成资源的浪费。因此可以通过一次抓取只赋予一个调度模块130调度权利来避免资源浪费。这可以通过数据库的行锁进行保证：调度模块130抓取完成后会将当前cron记录的超时时间和状态(Dispatch)更新到数据库。因此，更新失败的调度模块130将放弃本次调度。这样，一次只有一个调度模块130可以真正执行任务，抢占执行权的方法可以参考任务调度，通过数据库行锁来保证。如图2b中的调度模块3获得了调度权限。采用异步事件处理模型，当Cron记录被调度模块130抓取后经过处理，发送至执行队列中等待，等待的时间就是调度时间。如图2b中调度模块3将Cron1发送至执行队列。当执行模块140中的执行线程都在执行任务时，该cron记录就需要等待。当cron记录开始被调度时，将会写入一个超时时间到数据库，当超过这个时间却还处于调度状态时，该cron记录会被调度模块130抓起放入自己的调度队列。此时，该cron记录有多个调度模块130。由于是定时服务，所以将过时的Cron记录丢掉。常用的另外一种做法是将过时的Cron记录向后推一个执行时间，但是这将导致以后每次任务的执行时间都不准确。

其中，如图3所示，调度模块130包括抓取子模块131、恢复子模块132、调度超时子模块133、下一刻执行子模块134和运行超时子模块135。调度模块130调用子模块进行处理，并将cron记录发送至执行队列。

多个调度模块130对符合要求的cron记录分类处理：

(1)、抓取子模块131处理对需要恢复的Cron记录，将其放回数据库。

如图4，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：将READY状态和next_exec_time同时写入数据库。

(2)、恢复子模块132处理正常调度的Cron记录，将其放入调度队列。放入调度队列的之前需要修改数据库状态为DISPATCH，多个Jobs进程同时做这个动作。只有一个成功。即抢夺调度权。

如图5，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：计算超时时间dispatch_timeout。

步骤S3：将DISPATCH状态和next_exec_time、dispatch_timeout更新到数据库。

步骤S4：判断更新是否成功。

步骤S5：如果更新成功，将Cron记录加入执行队列。

步骤S6：如果更新不成功，进入下一步。

步骤S7：结束处理。

(3)、调度超时子模块133处理调度超时的Cron记录，将其放入调度队列。

如图6，具体步骤包括：

步骤S1：计算超时时间dispatch_time_out。

步骤S2：将dispatch_time_out更新到数据库中。

步骤S3：判断更新是否成功。

步骤S4：如果更新成功，将Cron记录加入执行队列。

步骤S5：如果更新不成功，进入下一步。

步骤S6：结束处理。

(4)、下一刻执行子模块134处理调度超时到下一执行时刻的Cron记录，将其放入调度队列。

如图7，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：将next_exec_time更新到数据库。

步骤S3：计算超时时间。

步骤S4：将超时时间更新到数据库。

步骤S5：判断更新是否成功。

步骤S6：如果更新成功，将Cron记录加入执行队列。

步骤S7：如果更新不成功，进入下一步。

步骤S8：结束处理。

(5)、运行超时子模块135处理运行超时的Cron记录，将其放入数据库。

如图8，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：将next_exec_time更新到数据库。

当Cron记录满足调度时间表时，调度模块130根据Cron记录对应的当前状态信息将Cron记录放置到执行队列中。

当Cron记录到达执行之间时，并不是在本线程里执行，而是被调度模块130放置在执行队列中，由执行进程从执行队列中取出Cron记录并执行，保证不会因为任务堆积造成任务遗漏。

调度模块130具体执行过程包括：

步骤S1：执行事前修改任务状态为RUNNING。这里存在多个执行线程抢占执行权的问题，解决方案可以为先写数据库成功的线程分配执行权。

步骤S2：执行任务。

步骤S3：修改Cron记录状态为READY，以便其他线程进行抓取。

执行模块140执行执行队列之中的Cron记录。具体执行模块140执行步骤如图9所示。

步骤S1：将RUNNING状态更新到数据库。

步骤S2：进行配额校验。

步骤S3：如果校验成功。

步骤S31：将任务推送至执行队列中。继续执行步骤S41。

步骤S32：计算下次执行时间next_exec_time。

步骤S33：设置cront_status_tmp为LIVING状态。

步骤S4：如果校验失败。

步骤S41：计算下次执行时间next_exec_time。

步骤S42：将Cron_status_tmp设为超限。

步骤S5：检查exec_count＞＝times。

步骤S6：如果exec_count＞＝times，将cron_status＝FINISH，start_deal_time更新到数据库。

步骤S7：否则将cron_status＝cron_status_tmp，start_deal_time next_exec_time更新到数据库。

当Cron记录数量巨大时，一个数据库一张表将无法处理，此时需要分库分表。分库分表具体算法为：假设有M个库，每个库有N张表，则共有M*N张表。取uid的数字签名signint(uid)，用户uid对应的分库为(M*N％signint(uid))/N，用户对应的分表为(M*N％signint(uid))％N。将调度模块130分成若干组，一组调度模块130对应一组表。调度模块130组中的每个调度模块130和对应表组中的每个表一一对应。这样每张表就会由多个调度模块130负责，如果一个调度模块130有问题，其他调度模块130还可以正常运行，不会对整个系统造成影响，从而避免单点问题。

根据本发明实施例的分布式定时任务控制装置，通过接收模块接受用户指令，调度模块调度任务，并由执行模块执行，其中，接收模块和调度模块、执行模块之间的交互由数据库模块完成。该装置可以处理高并发的Cron任务，用户可以同时创建并运行多个Cron，提供了友好的SDK和HTTP接口，只与用户相关，不依赖于应用，使用者可以使用应用程序之外的URL作为定时任务的地址，更加灵活方便。

如图10所示，根据本发明实施例的分布式定时任务控制方法，包括以下步骤：

步骤S110：接收定时任务Cron的指令并保存，其中每个Cron记录具有对应的当前状态信息。

步骤S120：根据调度时间表对数据库模块中的Cron记录进行调度。

步骤S130：当Cron记录满足调度时间表时，根据Cron记录对应的当前状态信息将Cron记录放置到执行队列中。

步骤S140：执行执行队列之中的Cron记录。

其中，Cron记录为数据库中的一条记录，具有对应的当前状态信息和对应的执行状态信息。

当前状态信息包括五种状态，分别为活跃状态、结束状态、删除状态、暂停状态和配额超限状态。活跃状态表示任务Cron正在运行；结束状态表示任务Cron已经执行完毕；删除状态表示用户请求删除该任务Cron。但由于该任务Cron还有一次任务正在执行，所以未被删除。暂停状态表示用户请求暂停任务Cron。配额超限状态表示该任务Cron的配额超限，被禁止运行。

执行状态为一个任务Cron的一次执行，一条Cron记录可以表示一个执行状态，不同执行状态对应的执行时间不同。执行状态信息包括就绪状态READY、调度状态DISPATCH和运行状态RUNNING，根据执行状态信息执行执行队列之中的Cron记录。调度状态，如task_status＝DISPATCH，表示Cron记录已经被推送至执行队列，但是还没有被执行。运行状态，如task_status＝RUNNING，表示Cron记录已经被从执行队列取走并开始执行。其中，只有处于活跃状态下的当前状态信息是可被调度的。当Cron记录放置到执行队列中之后，将Cron记录的执行状态信息修改为调度状态。当Cron记录的执行状态信息为调度状态或运行状态时，不执行Cron记录；如果Cron记录超时，将Cron记录丢弃。

其中，数据库包括多个子数据库，且每个子数据库包括多个数据列表。

任务过时未被调度，则直接放弃调度。一次任务是指Cron记录的某一次执行。调度的过程是指任务在执行队列上等待线程去调度。

接收定时任务Cron的指令并保存，其中每个Cron记录具有对应的当前状态信息。

用户通过接口可以使创建，删除，修改，暂停，重启，查询，显示所有Cron记录。

根据调度时间表对数据库模块中的Cron记录进行调度。

进一步地，从数据库抓取符合要求的cron记录，其中，符合要求包括抓取处于就绪状态、调度超时状态、运行超时状态、休息状态的Cron记录。一个Cron记录可以被多次抓取。采用异步事件处理模型，当cron记录被抓取后经过处理，被发送执行队列中等待，等待的时间就是调度时间。当执行线程都在执行任务时，该cron记录就需要等待。当cron记录开始被调度时，将会写入一个超时时间到数据库，当超过这个时间却还处于调度状态时，该cron记录会被抓起放入自己的调度队列。此时，该cron记录有多个调度。但是多个同时调度一个Cron记录会造成资源的浪费。因此可以通过一次抓取只有一个获得调度权利来避免资源浪费。这可以通过数据库的行锁进行保证：抓取完成后会将当前cron记录的超时时间和状态(Dispatch)更新到数据库。这样，更新失败的Job将放弃本次调度。因此，一次只有一个任务可以真正被执行，抢占执行权的方法可以参考任务调度，通过数据库行锁来保证。由于是定时服务，所以将过时的Cron记录丢掉。常用的另外一种做法是将过时的Cron记录向后推一个执行时间，但是这将导致以后每次任务的执行时间都不准确。

对符合要求的cron记录分类处理：

(1)、对需要恢复的Cron记录，将其放回数据库。

如图4，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：将READY状态和next_exec_time同时写入数据库。

(2)、对正常调度的Cron记录，将其放入调度队列。放入调度队列的之前需要修改数据库状态为DISPATCH，多个Jobs进程同时做这个动作。只有一个成功。即抢夺调度权。

如图5，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：计算超时时间dispatch_timeout。

步骤S4：判断更新是否成功。

步骤S5：如果更新成功，将Cron记录加入执行队列。

步骤S6：如果更新不成功，进入下一步。

步骤S7：结束处理。

(3)、处理调度超时的Cron记录，将其放入调度队列。

如图6，具体步骤包括：

步骤S1：计算超时时间dispatch_time_out。

步骤S2：将dispatch_time_out更新到数据库中。

步骤S3：判断更新是否成功。

步骤S4：如果更新成功，将Cron记录加入执行队列。

步骤S5：如果更新不成功，进入下一步。

步骤S6：结束处理。

(4)、处理调度超时到下一执行时刻的Cron记录，将其放入调度队列。

如图7，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：将next_exec_time更新到数据库。

步骤S3：计算超时时间。

步骤S4：将超时时间更新到数据库。

步骤S5：判断更新是否成功。

步骤S6：如果更新成功，将Cron记录加入执行队列。

步骤S7：如果更新不成功，进入下一步。

步骤S8：结束处理。

(5)、处理运行超时的Cron记录，将其放入数据库。

如图8，具体步骤包括：

步骤S1：计算下次执行时间next_exec_time。

步骤S2：将next_exec_time更新到数据库。

当Cron记录到达执行之间时，并不是在本线程里执行，而是被放置在执行队列中，由执行进程从执行队列中取出Cron记录并执行，保证不会因为任务堆积造成任务遗漏。

具体执行过程包括：

步骤S2：执行任务。

步骤S3：修改Cron记录状态为READY，以便其他线程进行抓取。

步骤S140：执行执行队列之中的Cron记录。

具体的执行步骤如图9所示，包括如下步骤：

步骤S1：将RUNNING状态更新到数据库。

步骤S2：进行配额校验。

步骤S3：如果校验成功。

步骤S31：将任务推送至执行队列中。继续执行步骤S41。

步骤S32：计算下次执行时间next_exec_time。

步骤S33：设置cront_status_tmp为LIVING状态。

步骤S4：如果校验失败。

步骤S41：计算下次执行时间next_exec_time。

步骤S42：将Cron_status_tmp设为超限。

步骤S5：检查exec_count＞＝times。

当Cron记录数量巨大时，一个数据库一张表将无法处理，此时需要分库分表。分库分表具体算法为：假设有M个库，每个库有N张表，则共有M*N张表。取uid的数字签名signint(uid)，用户uid对应的分库为(M*N％signint(uid))/N，用户对应的分表为(M*N％signint(uid))％N。将负责调度的模块分成若干组，一组负责调度的模块对应一组表。负责调度的模块组中的每个负责调度的模块和对应表组中的每个表一一对应。这样每张表就会由多个负责调度的模块负责，如果一个负责调度的模块有问题，其他负责调度的模块还可以正常运行，不会对整个系统造成影响，从而避免单点问题。

根据本发明实施例的分布式定时任务控制方法，通过对外接口接受用户指令，通过数据库存储按照数据库所存储的时间表进行调度，可以处理高并发的Cron任务，用户可以同时创建并运行多个Cron，提供了友好的SDK和HTTP接口，只与用户相关，不依赖于应用，使用者可以使用应用程序之外的URL作为定时任务的地址，更加灵活方便。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对所述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同限定。

Claims

1.一种分布式定时任务控制装置，其特征在于，包括：

接收模块，用于接收定时任务Cron的指令；

数据库模块，用于保存Cron记录，其中，每个所述Cron记录具有对应的当前状态信息；

多个调度模块，用于分别根据调度时间表对所述数据库模块中的Cron记录进行调度，当Cron记录满足所述调度时间表之后，根据所述Cron记录对应的当前状态信息将所述Cron记录放置到执行队列中；以及

执行模块，用于执行所述执行队列之中的Cron记录。

2.如权利要求1所述的分布式定时任务控制装置，其特征在于，每个所述Cron记录还具有对应的执行状态信息，所述执行模块根据所述执行状态信息执行所述执行队列之中的Cron记录。

3.如权利要求1或2所述的分布式定时任务控制装置，其特征在于，所述当前状态信息包括活跃状态、结束状态、删除状态、暂停状态和配额超限状态中的一种或多种。

4.如权利要求3所述的分布式定时任务控制装置，其特征在于，所述多个调度模块对处于活跃状态的Cron记录进行调度。

5.如权利要求2所述的分布式定时任务控制装置，其特征在于，所述执行状态信息包括就绪状态、调度状态和运行状态。

6.如权利要求5所述的分布式定时任务控制装置，其特征在于，当所述调度模块将Cron记录放置到所述执行队列中之后，将所述Cron记录的执行状态信息修改为调度状态。

7.如权利要求6所述的分布式定时任务控制装置，其特征在于，当所述Cron记录的执行状态信息为调度状态或运行状态时，所述执行模块不执行所述Cron记录。

8.如权利要求1所述的分布式定时任务控制装置，其特征在于，所述调度模块还用于在Cron记录超时之后，将所述Cron记录丢弃。

9.如权利要求1所述的分布式定时任务控制装置，其特征在于，所述数据库包括多个子数据库，且每个子数据库包括多个数据列表。

10.一种分布式定时任务控制方法，其特征在于，包括以下步骤：

接收定时任务Cron的指令并保存，其中每个Cron记录具有对应的当前状态信息；

根据调度时间表对数据库模块中的Cron记录进行调度；

当所述Cron记录满足所述调度时间表时，根据所述Cron记录对应的当前状态信息将所述Cron记录放置到执行队列中；以及

执行所述执行队列之中的Cron记录。

11.如权利要求10所述的分布式定时任务控制方法，其特征在于，每个所述Cron记录还具有对应的执行状态信息，执行模块根据所述执行状态信息执行所述执行队列之中的Cron记录。

12.如权利要求10所述的分布式定时任务控制方法，其特征在于，所述当前状态信息包括活跃状态、结束状态、删除状态、暂停状态和配额超限状态中的一种或多种。

13.如权利要求10所述的分布式定时任务控制方法，其特征在于，对处于活跃状态的Cron记录进行调度。

14.如权利要求11所述的分布式定时任务控制方法，其特征在于，所述执行状态信息包括就绪状态、调度状态和运行状态。

15.如权利要求10所述的分布式定时任务控制方法，其特征在于，所述Cron记录放置到所述执行队列中之后，将所述Cron记录的执行状态信息修改为调度状态。

16.如权利要求15所述的分布式定时任务控制方法，其特征在于，当所述Cron记录的执行状态信息为调度状态或运行状态时，不执行所述Cron记录。

17.如权利要求10所述的分布式定时任务控制方法，其特征在于，如果Cron记录超时，将所述Cron记录丢弃。

18.如权利要求10所述的分布式定时任务控制方法，其特征在于，所述数据库包括多个子数据库，且每个子数据库包括多个数据列表。