一种定时任务处理方法、装置及系统

技术领域

本申请属于信息处理技术领域，尤其涉及一种定时任务处理方法、定时任务处理装置及定时任务处理系统。

背景技术

当前针对定时任务，主要有两种不同的实现方式：一种是基于mysql实现，另一种是基于zookeeper实现。然而，上述这两种实现方式存在有设计复杂度较高、性能较弱和/或数据易丢失等问题。

发明内容

本申请提供了一种定时任务处理方法、定时任务处理装置及定时任务处理系统，可降低设计复杂度，提升任务处理的性能，减少数据丢失的可能性。

第一方面，本申请提供了一种定时任务处理方法，上述定时任务处理方法应用于任务管理模块，上述定时任务处理方法包括：

当存在待执行的任务时，检测上述任务是否为定时任务；

若上述任务为定时任务，则基于上述任务向redis服务器写入第一键，其中，上述第一键的过期时间为上述任务的定时执行时间，以指示在上述redis服务器基于上述第一键的过期时间产生上述第一键的过期事件时，基于发布订阅模式向能够执行上述任务的服务节点发送通知，触发上述服务节点执行上述任务。

第二方面，本申请提供了一种定时任务处理方法，上述定时任务处理方法应用于服务节点，上述定时任务处理方法包括：

基于发布订阅模式，订阅redis服务器上第一键的过期事件，其中，上述第一键为基于待执行的任务而写入上述redis服务器中的键，上述任务为定时任务；

当接收到基于上述第一键的过期事件而产生的通知时，执行上述任务。

第三方面，本申请提供了一种定时任务处理装置，上述定时任务处理装置应用于任务管理模块，上述定时任务处理装置包括：

检测单元，用于当存在待执行的任务时，检测上述任务是否为定时任务；

写入单元，用于若上述任务为定时任务，则基于上述任务向redis服务器写入第一键，其中，上述第一键的过期时间为上述任务的定时执行时间，以指示在上述redis服务器基于上述第一键的过期时间产生上述第一键的过期事件时，基于发布订阅模式向能够执行上述任务的服务节点发送通知，触发上述服务节点执行上述任务。

第四方面，本申请提供了一种定时任务处理装置，上述定时任务处理装置应用于服务节点，上述定时任务处理装置包括：

订阅单元，用于基于发布订阅模式，订阅redis服务器上第一键的过期事件，其中，上述第一键为基于待执行的任务而写入上述redis服务器中的键，上述任务为定时任务；

执行单元，用于当接收到基于上述第一键的过期事件而产生的通知时，执行上述任务。

第五方面，本申请提供了一种定时任务处理系统，上述定时任务处理系统包括任务管理模块、redis服务器及服务节点；

其中，上述任务管理模块，用于当存在待执行的任务时，检测上述任务是否为定时任务；若上述任务为定时任务，则基于上述任务向redis服务器写入第一键，其中，上述第一键的过期时间为上述任务的定时执行时间，以指示在上述redis服务器基于上述第一键的过期时间产生上述第一键的过期事件时，基于发布订阅模式向能够执行上述任务的服务节点发送通知，触发上述服务节点执行上述任务；

上述服务器节点，用于基于发布订阅模式，订阅redis服务器上上述第一键的过期事件；当接收到基于上述第一键的过期事件而产生的通知时，执行上述任务。

本申请与现有技术相比存在的有益效果是：当存在待执行的任务时，先检测该任务是否为定时任务，只有在该任务为定时任务时，才基于该任务向redis服务器写入第一键。具体地，该第一键的过期时间为该任务的定时执行时间，以指示在redis服务器基于该第一键的过期时间产生第一键的过期事件时，基于发布订阅模式向能够执行上述任务的服务节点发送通知。在服务节点接收到该通知后，即可开始执行该任务。上述过程通过redis及分布订阅模式即可实现定时任务的执行。首先，由于几乎现在任何一个web应用程序都会使用redis作为缓存来存储热点信息、令牌及权限信息等，所以基于redis来执行定时任务不会提高系统额外的复杂性及依赖；其次，redis性能非常高，所以使用redis来执行定时任务也不会存在性能问题；最后，由于redis支持哨兵模式、集群模式以及持久化，可减少数据丢失的可能性。可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

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

图1是本申请实施例提供的定时任务处理方法的实现流程示意图；

图2是本申请实施例提供的另一定时任务处理方法的实现流程示意图；

图3是本申请实施例提供的定时任务处理装置的结构框图；

图4是本申请实施例提供的另一定时任务处理装置的结构框图；

图5是本申请实施例提供的定时任务处理系统的架构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

下面对本申请实施例提供的一种定时任务处理方法进行描述，该定时任务处理方法应用于定时任务处理系统中的任务管理模块。请参阅图1，该定时任务处理方法包括：

步骤101，当存在待执行的任务时，检测上述任务是否为定时任务；

在本申请实施例中，可将用户通过客户端所发起的任务，也即待执行的任务划分为两种类型：一类是定时任务；一类是非定时任务，也即即刻执行的任务。在定时任务处理系统启动后，只要扫描到用户通过客户端上报了待执行的任务，该任务管理模块就会对该任务的类型进行检测。

步骤102，若上述任务为定时任务，则基于上述任务向redis服务器写入第一键。

在本申请实施例中，若检测发现该任务为定时任务，则任务管理模块可进入定时任务的处理流程。具体地，对于定时任务来说，有如下两种情况：

第一种情况是该任务的定时执行时间未到，也即，当前时间早于该定时执行时间。在这种情况下，可基于该任务向预设的redis服务器写入第一键key1。下面对该第一键作出说明：对于redis服务器来说，实际所写入的数据为键值(key-value)对。本方案中，仅关心所写入的键值对中的键(key)，而不关心所写入的键值对中的值(value)。考虑到同一时刻下，仅能执行单一业务下的任务，因而，该第一键key1可基于该任务所属的业务而确定。也即，该第一键key1可唯一的映射至该任务所属的业务。需要注意的是，每个业务所映射的键均为研发人员预先根据一预定的规则及配置所设定好的。并且，在基于该任务向redis服务器写入第一键key1时，还会设置该第一键key1的过期时间，该过期时间具体为该任务的定时执行时间。

对于能够执行该任务的服务节点来说，这些服务节点会预先基于发布订阅模式，订阅与该任务所属的业务相关的键的过期事件；基于此，随着时间的流逝，当达到该过期时间时，该第一键key1就会过期，从而产生该第一键key1的过期事件。由于服务节点已预先订阅了与该任务所属的业务相关的键的过期事件，因而，该第一键key1的过期事件会被通知到服务节点，以触发服务节点执行该任务。

举例来说，在T0时刻，任务管理模块扫描到了一待执行的任务Task1，且检测发现该任务Task1属于定时任务，具体的定时执行时间为T1时刻。则任务管理模块会基于该任务Task1所属的业务的类型，向redis服务器写入唯一的第一键key1(该第一键key1唯一的指示了该任务Task1)，并设置该第一键key1的过期时间为T1。当时间到了T1时刻时，该第一键key1过期，此时redis服务器会向订阅了该第一键的过期事件的服务节点发送通知，使得服务节点在接收到通知后可知现在需要去执行任务Task1。

第二种情况是该任务的定时执行时间已经过去了，也即，当前时间晚于该定时执行时间。此时，直接结束对该任务的管理。也即，无需再去执行该任务。

基于上述这两种情况可知，本步骤中，在确定待执行的任务为定时任务时，还需要进一步判断定时执行时间是否晚于当前时间，只有在定时执行时间晚于当前时间时，才会基于该任务向redis服务器写入第一键。

在一些实施例中，定时任务还可进一步细分为两种类型：一类是非周期性的定时任务(也即单次的定时任务)；另一类是周期性的定时任务。考虑到周期性的定时任务会在之后多次执行，因而，上述定时任务处理方法还包括：

在上述任务执行成功后，检测上述任务是否为周期性的定时任务；

若上述任务为周期性的定时任务，则根据上述任务的周期时间，确定上述任务新的定时执行时间；

返回执行上述步骤102，以使得上述redis服务器中所存储的上述第一键的过期时间被更新为上述新的定时执行时间。

也即，对于周期性的定时任务而言，每次因第一键key1过期而触发服务节点执行任务后，会根据该任务的周期时间，重新确定下一次执行该任务时的定时执行时间，并根据该定时执行时间再次写入第一键key1。新写入的第一键key1与前一次写入的第一键key1的唯一区别在于过期时间，具体为：新写入的第一键key1的过期时间是新的定时执行时间。

举例来说，在T0时刻，任务管理模块扫描到了一待执行的任务Task1，且检测发现该任务Task1属于定时任务，具体的定时执行时间为T1时刻。则任务管理模块会基于该任务Task1所属的业务的类型，向redis服务器写入唯一的第一键key1(该第一键key1唯一的指示了该任务Task1)，并设置该第一键key1的过期时间为T1。当时间到了T1时刻时，该第一键key1过期(过期时，第一键key1会从redis服务器中删除)，此时redis服务器会向订阅了该第一键的过期事件的服务节点发送通知，使得服务节点在接收到通知后可知现在需要去执行任务Task1。在该Task1执行成功后，又检测发现该任务Task1属于周期性的定时任务，且周期时间为T3。基于此，可确定下一次该Task1的定时执行时间(也即新的定时执行时间)为T1+T3时刻。任务管理模块再次写入唯一的第一键key1，并设置该第一键key1的过期时间为T1+T3。基于上述过程，周期性的写入第一键，即可实现周期性的因第一键的过期事件而触发服务节点执行任务，保障任务的周期性的定时执行。

在一些实施例中，当任务执行失败时，任务管理模块可以重新将第一键key1写入redis服务器中，并将该新写入的第一键key1的过期时间设置为当前时间的后几秒，方便服务器节点再次监听该第一键的过期事件，以使得服务节点能够在短时间内重新执行该任务。举例来说，服务节点在T1时刻接收到了第一键key1的过期事件的通知，开始执行任务Task1；因某种原因，该Task1执行失败，则任务管理模块会再次向redis服务器写入第一键key1，且该第一键key1的过期事件为T1时刻的后几秒，例如T1时刻的后5秒。也即，T1+5s的时刻，会再次产生该第一键key1的过期事件，以触发服务节点再次执行任务Task1，可保障该任务Task1能够最终被执行成功。

在一些实施例中，还可能出现服务节点因硬件故障等原因而发生崩溃，导致出现服务节点暂时无法提供服务的情况，这也可能导致任务无法被顺利执行。基于此，本申请还提出了备份键，具体为：

在上述服务节点执行上述任务之前，基于上述任务向redis服务器写入第二键，以作为上述第一键的备份，其中，上述第二键的过期时间基于上述任务的执行时长及预设的缓冲时长而设定，以指示在上述redis服务器基于上述第二键的过期时间产生上述第二键的过期事件时，基于发布订阅模式向上述服务节点所在的服务集群发送通知，触发上述服务集群中的任一服务节点执行上述任务；

若上述任务执行成功，则删除上述第二键。

基于上述备份键，可能存在如下几种不同的应用场景：

在第一种应用场景下，服务节点所在的服务集群实际只有这一个服务节点。则在该服务节点执行任务前，任务管理模块会基于该任务写入第二键key2，该第二键key2可被认为是第一键key1的备份；假定该服务节点因崩溃而导致执行任务失败，又在短时间内迅速重启，且重启的时间在第二键key2的过期时间之前，则该重启后的服务节点仍然可以再次接收到redis服务器基于第二键key2的过期事件而发出的通知，并触发自己再次执行该任务，防止任务丢失。

在第二种应用场景下，服务节点所在的服务集群实际可存在有两个以上服务节点，也即，当前有两个以上服务节点能够执行任务。考虑到实际执行任务的服务节点仅能有1个，因而，服务集群中的服务节点会先通过竞争获取分布式锁的方式来确定当前可以去执行任务的唯一一个服务节点。为了便于说明，可将该服务集群中当前获取到分布式锁的服务节点记作目标服务节点。也即，该目标服务节点就是接下来要去执行该任务的服务节点。在该目标服务节点正式执行该任务之前，任务管理模块为了防止因目标服务节点崩溃而导致任务执行失败的情况发生，可基于该任务向redis服务器写入第二键key2；假定该目标服务节点因崩溃而导致执行任务失败，且短时间内未能重启成功，则该服务集群中除该目标服务节点之外的其它服务节点仍然可以再次接收到redis服务器基于第二键key2的过期事件而发出的通知，并通过竞争获取分布式锁的方式触发任一其它服务节点再次执行该任务，防止任务丢失；或者，假定该目标服务节点因崩溃而导致执行任务失败，又在短时间内迅速重启，且重启的时间在第二键key2的过期时间之前，则该重启后的目标服务节点也可以与其它服务节点一起再次接收到redis服务器基于第二键key2的过期事件而发出的通知，并通过竞争获取分布式锁的方式触发该目标服务节点或任一其它服务节点再次执行该任务，防止任务丢失。

需要注意的是，与第一键key1类似，该第二键key2可基于该任务所属的业务而确定。也即，该第二键key2也可唯一的映射至该任务所属的业务。需要注意的是，每个业务所映射的键均为研发人员预先根据一定规则及配置所设定好的，也即，针对每个业务，都可预先根据规则及配置去设定好对应的第一键key1，以及作为第一键key1备份的第二键key2。并且，在基于该任务向redis服务器写入第二键key2时，还会设置该第二键key2的过期时间，该过期时间具体基于上述任务的执行时长及预设的缓冲时长而设定。

举例来说，T1时刻，第一键key1的过期事件通知到了三个服务节点，分别是s1、s2及s3。这其中，目标服务节点s1获取到了分布式锁，可以执行任务。在目标服务节点s1执行任务之前，任务管理模块基于该任务向redis写入第二键key2。假定该任务的执行时长为5秒，缓冲时长为3秒，则可设置第二键key2在以T1时刻为起点的8秒后过期；也即，第二键key2的过期时间为T1+8s这一时刻。

若目标服务节点执行该任务成功，则认为此时目标服务节点s1未崩溃，任务管理模块可以删除掉第二键key2，以避免其它服务节点(也即节点s2及s3)因产生第二键的过期事件而误以为任务未能执行成功，导致其它节点对该任务的重复执行。反之，若目标服务节点执行该任务失败，则认为此时目标服务节点s1已崩溃，任务管理模块不会在第二键key2过期前删除该第二键key2；这样一来，第二键key2过期时，会产生第二键key2的过期事件，并通知到其它服务节点(也即节点s2及s3)；这些其它节点又会去竞争获取分布式锁，并在这些其它节点中确定出新的目标服务节点，以再次执行该任务。

由上可见，在本申请实施例中，当存在待执行的任务时，先检测该任务是否为定时任务，只有在该任务为定时任务时，才基于该任务向redis服务器写入第一键。具体地，该第一键的过期时间为该任务的定时执行时间，以指示在redis服务器基于该第一键的过期时间产生第一键的过期事件时，基于发布订阅模式向能够执行上述任务的服务节点发送通知。在服务节点接收到该通知后，即可开始执行该任务。上述过程通过redis及分布订阅模式即可实现定时任务的执行。首先，由于几乎现在任何一个web应用程序都会使用redis作为缓存来存储热点信息、令牌及权限信息等，所以基于redis来执行定时任务不会提高系统额外的复杂性及依赖；其次，redis性能非常高，所以使用redis来执行定时任务也不会存在性能问题；最后，由于redis支持哨兵模式、集群模式以及持久化，可减少数据丢失的可能性。进一步地，还实现了分布式锁的功能，使得每个定时的任务在到定时执行时间时，只有一个服务节点能被允许执行该任务，避免任务的重复执行。并且，还引入了备份键，以使得服务集群中当前执行任务的服务节点崩溃后，可基于该备份键来触发该服务集群中运行正常的服务节点再次执行该任务，保障任务的顺利执行。

下面对本申请实施例提供的一种定时任务处理方法进行描述，该定时任务处理方法应用于定时任务处理系统中的服务节点。请参阅图2，该定时任务处理方法包括：

步骤201，基于发布订阅模式，订阅redis服务器上第一键的过期事件；

在本申请实施例中，服务节点会先基于发布订阅模式，去订阅redis服务器上的第一键的过期事件，其中，该第一键为基于待执行的任务而写入上述redis服务器中的键，该任务为定时任务，且服务节点能够执行该定时任务；也即，服务节点具备为该任务所属的业务提供服务的能力。

举例来说，服务节点s1能够执行任务A，不能执行任务B；则服务节点s1只会订阅redis服务器上基于定时的任务A而写入的第一键的过期事件，不会订阅redis服务器上基于定时的任务B而写入的第一键的过期事件。

在一些实施例中，在引入备份机制的情况下，服务器节点还会订阅redis服务器上第二键(也即第一键的备份键)的过期事件。需要注意的是，每个业务所映射的键均为研发人员预先根据一定规则及配置所设定好的，也即，针对每个业务，都可预先根据规则及配置去设定好对应的第一键，以及作为第一键备份的第二键。则服务节点可预先基于自身对各个业务的支持情况，去订阅自身支持的业务所映射的第一键及第二键。

步骤202，当接收到基于上述第一键的过期事件而产生的通知时，执行上述任务。

在本申请实施例中，当接收到基于所订阅的第一键的过期事件而产生的通知时，即可知道待执行的任务已经到了定时执行时间；此时，服务节点即可去执行该任务。

举例来说，当前有一服务节点s1，订阅了基于任务A所写入redis服务器的第一键的过期事件。在T1时刻，该服务节点接收到了该第一键的过期事件的通知，则该服务节点可知此时已经到了任务A的任务执行时间，服务节点s1由此可开始执行任务A。

在一些实施例中，可能出现多个服务节点均订阅了基于某一任务所写入redis服务器的第一键的过期事件的情况；也即，这种情况下，这多个服务节点构成了服务集群。考虑到在该服务集群中，最终只需要一个服务节点来执行该任务，因而，可通过分布式锁来选定该服务集群中最终执行该任务的目标服务节点，以避免该任务的重复执行。这种情况下，上述步骤202可具体表现为：

当接收到基于上述第一键的过期事件而产生的通知时，尝试向上述redis服务器获取分布式锁；

若向上述redis服务器获取分布式锁成功，则执行上述任务。

其中，服务器节点可通过执行setnx()方法来尝试获取分布式锁；若setnx()的返回值为1，则表示获取分布式锁成功；若setnx()的返回值为0，则表示获取分布式锁失败。上述执行setnx()方法来尝试获取分布式锁的原理是：通过执行setnx()方法，尝试往redis服务器中写入一预设的第三键key3；若能够向redis服务器写入该第三键key3，则可知此前redis服务器中还不存在该第三键key3，此时setnx()的返回值为1；若无法向redis服务器写入第三键，则可知当前redis服务器中已存在该第三键key3，也即，已有其它服务节点通过写入第三键key3而获取到了分布式锁，此时setnx()的返回值为0。

需要注意的是，只有获取到分布式锁的服务节点(也即目标服务节点)才会去执行对应的任务；而未获取到分布式锁的服务节点将不会做任何处理。

在一些实施例中，在引入备份机制的情况下；也即，在服务器节点还订阅了redis服务器上第二键(也即第一键的备份键)的过期事件的情况下，该服务器节点不管是接收到基于该第一键的过期事件而产生的通知，还是接收到基于该第二键的过期事件而产生的通知，都会去尝试获取分布式锁，并只在获取到分布式锁的情况下才会去执行该第一键(或第二键)所对应的任务。

由上可见，在本申请实施例中，服务节点通过redis及分布订阅模式即可实现定时任务的执行。首先，由于几乎现在任何一个web应用程序都会使用redis作为缓存来存储热点信息、令牌及权限信息等，所以基于redis来执行定时任务不会提高系统额外的复杂性及依赖；其次，redis性能非常高，所以使用redis来执行定时任务也不会存在性能问题；最后，由于redis支持哨兵模式、集群模式以及持久化，可减少数据丢失的可能性。进一步地，还实现了分布式锁的功能，使得每个定时的任务在到定时执行时间时，只有一个服务节点能被允许执行该任务，避免任务的重复执行。并且，还引入了备份键，以使得服务集群中当前执行任务的服务节点崩溃后，可基于该备份键来触发该服务集群中运行正常的服务节点再次执行该任务，保障任务的顺利执行。

基于前文应用于任务管理模块的定时任务处理方法，本申请实施例还提出一种应用于任务管理模块的定时任务处理装置。请参阅图3，该定时任务处理装置300，包括：

检测单元301，用于当存在待执行的任务时，检测上述任务是否为定时任务；

写入单元302，用于若上述任务为定时任务，则基于上述任务向redis服务器写入第一键，其中，上述第一键的过期时间为上述任务的定时执行时间，以指示在上述redis服务器基于上述第一键的过期时间产生上述第一键的过期事件时，基于发布订阅模式向能够执行上述任务的服务节点发送通知，触发上述服务节点执行上述任务。

可选地，上述写入单元302，包括：

时间判断子单元，用于若上述任务为定时任务，判断上述定时执行时间是否晚于当前时间；

第一键写入子单元，用于若上述定时执行时间晚于上述当前时间，则基于上述任务向redis服务器写入第一键。

可选地，上述定时任务处理装置300还包括：

周期性检测单元，用于在上述任务执行成功后，检测上述任务是否为周期性的定时任务；

定时执行时间确定单元，用于若上述任务为周期性的定时任务，则根据上述任务的周期时间，确定上述任务新的定时执行时间；

上述写入单元302在上述定时执行时间确定单元执行完毕后被再次触发，以使得上述redis服务器中所存储的上述第一键的过期时间被更新为上述新的定时执行时间。

可选地，若存在两个以上能够执行上述任务的服务节点，则上述写入单元302还包括：

第二键写入子单元，用于在上述服务节点执行上述任务之前，基于上述任务向redis服务器写入第二键，以作为上述第一键的备份，其中，上述第二键的过期时间基于上述任务的执行时长及预设的缓冲时长而设定，以指示在上述redis服务器基于上述第二键的过期时间产生上述第二键的过期事件时，基于发布订阅模式向上述服务节点所在的服务集群发送通知，触发所述服务集群中的任一服务节点执行上述任务；

第二键删除子单元，用于若上述任务执行成功，则删除上述第二键。

由上可见，在本申请实施例中，当存在待执行的任务时，定时任务处理装置会先检测该任务是否为定时任务，只有在该任务为定时任务时，才基于该任务向redis服务器写入第一键。具体地，该第一键的过期时间为该任务的定时执行时间，以指示在redis服务器基于该第一键的过期时间产生第一键的过期事件时，基于发布订阅模式向能够执行上述任务的服务节点发送通知。在服务节点接收到该通知后，即可开始执行该任务。上述过程通过redis及分布订阅模式即可实现定时任务的执行。首先，由于几乎现在任何一个web应用程序都会使用redis作为缓存来存储热点信息、令牌及权限信息等，所以基于redis来执行定时任务不会提高系统额外的复杂性及依赖；其次，redis性能非常高，所以使用redis来执行定时任务也不会存在性能问题；最后，由于redis支持哨兵模式、集群模式以及持久化，可减少数据丢失的可能性。进一步地，还实现了分布式锁的功能，使得每个定时的任务在到定时执行时间时，只有一个服务节点能被允许执行该任务，避免任务的重复执行。并且，还引入了备份键，以使得服务集群中当前执行任务的服务节点崩溃后，可基于该备份键来触发该服务集群中运行正常的服务节点再次执行该任务，保障任务的顺利执行。

基于前文应用于服务节点的定时任务处理方法，本申请实施例还提出一种应用于服务节点的定时任务处理装置。请参阅图4，该定时任务处理装置400，包括：

订阅单元401，用于基于发布订阅模式，订阅redis服务器上第一键的过期事件，其中，上述第一键为基于待执行的任务而写入上述redis服务器中的键，上述任务为定时任务；

执行单元402，用于当接收到基于上述第一键的过期事件而产生的通知时，执行上述任务。

可选地，上述执行单元402，包括：

分布式锁获取子单元，用于当接收到基于上述第一键的过期事件而产生的通知时，尝试向上述redis服务器获取分布式锁；

任务执行子单元，用于若向上述redis服务器获取分布式锁成功，则执行上述任务。

可选地，上述分布式锁获取子单元，包括：

第三键尝试写入子单元，用于尝试向上述redis服务器写入预设的第三键；

获取结果确定子单元，用于若能够向上述redis服务器写入上述第三键，则确定向上述redis服务器获取分布式锁成功，若无法向上述redis服务器写入上述第三键，则确定向上述redis服务器获取分布式锁失败。

由上可见，在本申请实施例中，定时任务处理装置通过redis及分布订阅模式即可实现定时任务的执行。首先，由于几乎现在任何一个web应用程序都会使用redis作为缓存来存储热点信息、令牌及权限信息等，所以基于redis来执行定时任务不会提高系统额外的复杂性及依赖；其次，redis性能非常高，所以使用redis来执行定时任务也不会存在性能问题；最后，由于redis支持哨兵模式、集群模式以及持久化，可减少数据丢失的可能性。进一步地，还实现了分布式锁的功能，使得每个定时的任务在到定时执行时间时，只有一个服务节点能被允许执行该任务，避免任务的重复执行。并且，还引入了备份键，以使得服务集群中当前执行任务的服务节点崩溃后，可基于该备份键来触发该服务集群中运行正常的服务节点再次执行该任务，保障任务的顺利执行。

请参阅图5，本申请实施例还提出了一定时任务处理系统5，该定时任务处理系统包括任务管理模块51、redis服务器52及至少一个服务节点53(图5中仅示出一个)；其中，任务管理模块51可实现上文所提出的应用于任务管理模块的定时任务处理方法，服务节点53可实现上文提出的应用于服务节点的定时任务处理方法，此处不再赘述。该定时任务处理系统依赖于redis及分布订阅模式来实现定时任务的执行。首先，由于几乎现在任何一个web应用程序都会使用redis作为缓存来存储热点信息、令牌及权限信息等，所以基于redis来执行定时任务不会提高系统额外的复杂性及依赖；其次，redis性能非常高，所以使用redis来执行定时任务也不会存在性能问题；最后，由于redis支持哨兵模式、集群模式以及持久化，可减少数据丢失的可能性。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将上述系统的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，上述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，模块或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

上述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，上述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，上述计算机程序包括计算机程序代码，上述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。上述计算机可读介质可以包括：能够携带上述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，上述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括是电载波信号和电信信号。

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