CN112286655A - 分布式延时调度方法、装置及系统 - Google Patents

Abstract

本申请公开了一种分布式延时调度方法、装置及系统。该申请的方法包括第二服务端接收多个第一服务端推送的延时任务；将所有的延时任务存入延时队列的延时桶中；通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供与延时任务对应的第三服务端获取并执行。本申请利用Redis集群来支持高并发和高可用，进行持久化存储，实现统一的延时任务调度，让研发人员只专注于业务本身开发，降低了维护开发成本，并且提高实时性。

Description

分布式延时调度方法、装置及系统

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种分布式延时调度方法、装置及系统。

背景技术

延迟调度，是一种带有延迟功能的调度任务。在实际的应用场景中，比如超时未确认的订单需要即时关闭并退还库存，长时间不支付的订单需要即时关闭，生成订单60秒后，给用户发短信等。其中的即时关闭并退还库存、即时关闭、以及给用户发短信都属于延时任务。延时任务都需要在一个指定的时间点去执行一次，来使业务流程达到闭环。延迟调度关键点在于其根据业务场景调度时间的不确定性，且一般为单个任务，只会执行一次。

为了解决以上问题，最简单直接的办法就是定时去扫描。每个业务都维护一个自己的扫描逻辑。但是发明人发现，每个业务的扫描逻辑是非常类似的，当业务越来越多时，会增加维护的成本。

发明内容

本申请的主要目的在于提供一种分布式延时调度方法、装置及系统，以解决现有延时任务调度的方式维护成本高的问题。

为了实现上述目的，根据本申请的第一方面，提供了一种分布式延时调度方法。

根据本申请的分布式延时调度方法包括：

第二服务端接收多个第一服务端推送的延时任务；

将所有的延时任务存入延时队列的延时桶中；

通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供与延时任务对应的第三服务端获取并执行。

可选的，所述将所有的延时任务存入延时队列的延时桶中包括：

获取延时任务的标识信息和类型；

将所有的延时任务的标识信息存入对应的延时桶中，不同类型的延时任务对应不同的延时桶。

可选的，所述通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中包括：

通过定时任务轮询各个延时桶，判断延时桶中的延时任务对应的延时时间是否大于等于当前时间；

若大于等于当前时间，则将大于等于当前时间的延时任务的标识信息放入到准备执行链表中。

可选的，在则将大于等于当前时间的延时任务的标识信息放入到准备执行列表中之前，所述方法还包括：

获取大于等于当前时间的延时任务的状态信息；

若状态信息为非完成或者非删除，则执行将大于等于当前时间的延时任务的标识信息放入到准备执行链表中；

若状态信息为完成或者删除，则继续轮询。

可选的，所述方法还包括：

接收第三服务端返回的延时任务执行结果；

根据执行结果修改延时任务的状态信息以及将执行完成或者删除的延时任务从延时队列中移除。

可选的，所述方法还包括：

对于已经被第三服务端读取的延时任务，判断是否在执行时间内完成执行；

若否，则将已经读取的延时任务返回到延时桶中。

可选的，所述定时任务为多个定时任务，所述通过定时任务扫描延时桶包括：

通过每个延时桶对应的定时任务扫描延时桶，不同类型的延时桶对应不同的定时任务。

为了实现上述目的，根据本申请的第二方面，提供了一种分布式延时调度装置。

根据本申请的分布式延时调度装置包括：

第一接收单元，用于第二服务端接收多个第一服务端推送的延时任务；

存入单元，用于将所有的延时任务存入延时队列的延时桶中；

扫描单元，用于通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供第三服务端获取并执行。

可选的，所述存入单元包括：

获取模块，用于获取延时任务的标识信息和类型；

存入模块，用于将所有的延时任务的标识信息存入对应的延时桶中，不同类型的延时任务对应不同的延时桶。

可选的，所述扫描单元包括：

判断模块，用于通过定时任务轮询各个延时桶，判断延时桶中的延时任务对应的延时时间是否大于等于当前时间；

放入模块，用于若大于等于当前时间，则将大于等于当前时间的延时任务的标识信息放入到准备执行链表中。

可选的，所述装置还包括：

获取单元，用于在则将大于等于当前时间的延时任务的标识信息放入到准备执行列表中之前，获取大于等于当前时间的延时任务的状态信息；

执行单元，用于若状态信息为非完成或者非删除，则执行将大于等于当前时间的延时任务的标识信息放入到准备执行链表中；

轮询单元，用于若状态信息为完成或者删除，则继续轮询。

可选的，所述装置还包括：

第二接收单元，用于接收第三服务端返回的延时任务执行结果；

移除单元，用于根据执行结果修改延时任务的状态信息以及将执行完成或者删除的延时任务从延时队列中移除。

可选的，所述装置还包括：

判断单元，用于对于已经被第三服务端读取的延时任务，判断是否在执行时间内完成执行；

返回单元，用于若否，则将已经读取的延时任务返回到延时桶中。

可选的，所述定时任务为多个定时任务，所述扫描单元还用于：

通过每个延时桶对应的定时任务扫描延时桶，不同类型的延时桶对应不同的定时任务。

为了实现上述目的，根据本申请的第三方面，提供了一种分布式延时调度系统，第一服务端、第二服务端、第三服务端：

所述第一服务端，用于生成延时任务，并将其发送给所述第二服务端；

所述第二服务端，用于执行上述权利要求1-7中任一项所述分布式延时调度的方法；

所述第三服务端，用于从所述第二服务端中的准备执行链表中获取延时任务并执行。

为了实现上述目的，根据本申请的第四方面，提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述第一方面中任一项所述的分布式延时调度方法。

在本申请实施例中，分布式延时调度方法、装置及系统中，第二服务端接收多个第一服务端推送的延时任务；将所有的延时任务存入延时队列的延时桶中；通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供第三服务端获取并执行。可以看到，本申请将所有第一服务端的延时任务统一放到第二服务端中一个延时队列进行维护，具体的通过延时队列中的定时任务进行扫描延时桶，当到达或超过延时间的延时任务放入准备执行链表中，以使对应的第三服务端进行延时任务的消费。不需要每个服务端分别对延时任务进行维护，降低了维护的成本。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例提供的一种分布式延时调度方法流程图；

图2是根据本申请实施例提供的一种延时任务的结构图；

图3是根据本申请实施例提供的一种延时队列的结构图；

图4是根据本申请实施例提供的一种延时任务的生命周期图；

图5是根据本申请实施例提供的一种分布式延时调度装置的组成框图；

图6是根据本申请实施例提供的另一种分布式延时调度装置的组成框图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

根据本申请实施例，提供了一种分布式延时调度方法，如图1所示，该方法应用与第一智能合约接口侧，该方法包括如下的步骤：

S101.第二服务端接收多个第一服务端推送的延时任务。

第一服务端为某种业务对应的服务端，延时任务时在执行业务流程时对应延时任务。比如，当用户对商品下单后，第一服务端进入待支付环节，需要生成一个关闭任务(延时任务)，以使长时间未支付时就可以执行关闭任务。本申请是通过第二服务端进行延时任务维护的，因此第一服务端会将延时任务推给第二服务端，因此第二服务端可以接收到延时任务。在实际的应用中，不同的业务可能对应不同的第一服务端，不同的服务端需要将延时任务都发送给第二服务端进行统一的维护。

需要说明的，延时任务可以包括类型、唯一标识、需要延迟的时间、执行超时时间、延时任务的内容。具体的延时任务的结构如图2所示，其中，

Topic：为延时任务(记作Job)类型。可以理解成具体的业务名称。

Id：为Job的唯一标识。用来检索和删除指定的Job信息，全局唯一性。Time：Job需要延迟的时间。单位：秒。(服务端会将其转换为绝对时间)

MTTL(max_time_to_live)：Job执行超时时间。单位：秒。

Data：Job的内容，供消费者做具体的业务处理，以json格式存储。

S102.将所有的延时任务存入延时队列的延时桶中。

延时队列的结构如图3所示，包括任务池(Job pool)、延时桶(Delay Bucket)、定时任务(Timer)、准备执行链表(Ready Topic)。具体的：

Job Pool：用来存放所有延时任务Job的元信息。

Delay Bucket：是一组以时间为维度的有序队列，用来存放延时任务的唯一标识ID。对于已经被预约(reserve)或者被读取的延时任务但是没有按时执行的延时任务的ID也会存放在其中。

Timer：负责根据扫描周期扫描各个Delay Bucket，并将到达或超过延时间的延时任务放入准备执行链表Ready Topic中。

Ready Topic：存放处于Ready状态的Job(这里只存放Job Id)，以供第三方服务端获取执行任务并执行。

结合上述延迟队列的结构，进行本步骤以及后续步骤的说明：

第二服务端在接收到延时任务后，将延时任务的元信息放入Job Pool中；根据延时任务的Time获取需要延时的时间并计算绝对时间；获取延时任务的标识信息(ID)，并以轮询(round-robbin)的方式将延时任务的ID放入某个Delaybucket中，需要说明的是，本实施例中设置了多个Delaybucket，不同的Delaybucket对应不同的业务类型，根据延时任务的Topic可以获取类型，因此可以将延时任务的ID放入业务类型对应的Delaybucket中。

进一步的，延迟队列的存储方式为Redis实现，具体表现为：延时任务Job采用基本的key/value模式，ID为key；Delay Bucket是一个有序队列，数据结构就是redis的zset，将其分为多个bucket是为了提高扫描速度，降低消息延迟；Ready topic是一个普通list。

S103.通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供与延时任务对应的第三服务端获取并执行。

定时任务有扫描周期，按照扫描周期以轮询的方式对各个Delaybucket进行扫描，判断延时桶中的延时任务对应的延时时间是否大于等于当前时间；若大于等于当前时间，则将大于等于当前时间的延时任务的标识信息放入到准备执行链表中；之后会将延时桶中对应的标识信息移除。第三服务端可以通过轮询的方式获取准备执行链表中对应的延时任务执行。

需要说明的是，准备执行链表中按照业务类型进行分类，如图3所示，可以看到有Topic1、Topic2、Topic3、Topic4分别对应不同类型。第一服务端和第三服务端可以为相同的服务端可以为不同的服务端。本实施例中的分布式延时调度方法支持多实例部署，即多个服务器部署，挂掉一个实例后，还有后备实例继续提供服务。

从以上的描述中，可以看出，本申请实施例中分布式延时调度方法中，第二服务端接收多个第一服务端推送的延时任务；将所有的延时任务存入延时队列的延时桶中；通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供第三服务端获取并执行。可以看到，本申请将所有第一服务端的延时任务统一放到第二服务端中一个延时队列进行维护，具体的通过延时队列中的定时任务进行扫描延时桶，当到达或超过延时间的延时任务放入准备执行链表中，以使对应的第三服务端进行延时任务的消费。不需要每个服务端分别对延时任务进行维护，降低了维护的成本。

进一步的，在实际的应用场景中，有可能存在延时任务已经执行完成或删除即状态为delete或者finish，但是延时任务对应的ID以及元信息还存在延时队列的延时桶、任务池中，这种情况下，定时任务从Delay bucket中获取延时任务的状态信息后，就会发生延时任务不需要执行但是还会被放入Ready Topic中。为避免这种情况的发生，在定时任务判断延时桶中的延时任务对应的延时时间是否大于等于当前时间之后，还需要获取大于等于当前时间的延时任务的状态信息，若状态信息为非完成或者非删除，则执行将大于等于当前时间的延时任务的标识信息放入到准备执行链表中；若状态信息为完成或者删除，则继续轮询。需要说明的是，延时任务的状态信息在延时任务的data中可以获取到。延时任务的状态包括如下几种：

delay：不可执行状态，等待时钟周期。

ready：可执行状态，等待第三服务端消费。

reserved：已被消费者(第三服务端)读取，但还未得到消费者的响应(delete、finish)。

death：已被消费完成或者已被删除。

每个延时任务只能处于一个状态，前述的状态信息为完成或者删除对应death；非完成或者非删除包括delay、ready、reserved三种情况。延时任务的生命周期图如图4所示。延时任务被放入到延时桶中是delay状态，之后通过定时任务扫描后可以放入到ReadyTopic中，此时为Ready状态；之后被第三服务端获取，此时为reserved状态；之后如果被执行完或删除后变成death状态，如果没有在设定的时间内执行完成，则会重新回到延时桶中，又变为delay状态。

进一步的，第二服务端还需要接收第三服务端返回的延时任务执行结果；根据执行结果修改延时任务的状态信息以及将执行完成或者删除的延时任务从延时队列中移除。如果执行结果为完成或者删除，则需要将状态信息从reserved修改为death，如果没有按时执行完成则需要将状态信息从reserved改为delay。另外，需要说明的是，在延时任务完成或删除后，不会立即将延时任务的元信息或者延时桶中的ID删除。

进一步的，为了提高扫描的速度，降低消息的延迟，设置多个定时任务，每个延时桶或者每种业务类型对应的延时桶对应一个定时任务。

进一步的，当第三服务端获取到延时任务后，需要根据MTTL计算绝对的执行超时时间，当超过绝对的执行超时时间后，如果没有执行，为了保证每个延时任务都会消费一次，可以将其对应的ID再放回延时桶中。

进一步的，以实际的示例对本实施例中的分布式延时调度的方法进行说明:

1.用户对商品下单，进入到待支付环节，第一服务端同时往延迟队列里put一个job。job结构为：

{"topic":"payclose","id":"paycloseXXX","time":1800,"MTTL":60,"body":"XXXX XXX"}其中的body与前述延时任务结构中的data对应；

2.延迟队列(位于第二服务端)收到该job后，先往job pool中存入job元信息，然后根据延迟时间Time计算出绝对执行时间，并以轮询(round-robbin)的方式将job id放入某个bucket。

3.timer轮询各个bucket，当1800秒过后，检查到上面的job的执行时间到了，取得job id从job pool中获取元信息。如果这时该job处于删除或完成状态，则pass，继续做轮询；如果job处于非完成或非删除状态，则根据topic将job id放入对应的ready topic中，之后从bucket中移除；

4.消费端(第三服务端)轮询对应的topic的ready topic，获取job后做自己的业务逻辑(即执行延时任务)。与此同时，第二服务端将已经被消费端获取的job按照其设定的MTTL，计算绝对的执行超时时间，如果超过执行超时时间没有按时执行，则将其返回放入延时桶中。

5.消费端处理完业务后向第二服务端响应结果，第二服务端修改延时任务的状态信息，并在一定时间之后根据job id删除对应的元信息。

对本申请的分布式延时调度进行有益效果的总结：

利用Redis集群来支持高并发和高可用，进行持久化存储，开发成本小，实时性高。实现统一的延时调度过程，让研发人员只专注于业务本身开发。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本申请实施例，还提供了一种用于实施上述图1所述方法的分布式延时调度装置，如图5所示，该装置包括：

第一接收单元21，用于第二服务端接收多个第一服务端推送的延时任务；

存入单元22，用于将所有的延时任务存入延时队列的延时桶中；

扫描单元23，用于通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供第三服务端获取并执行。

具体的，本申请实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述，此处不再赘述。

从以上的描述中，可以看出，本申请实施例中分布式延时调度装置中，第二服务端接收多个第一服务端推送的延时任务；将所有的延时任务存入延时队列的延时桶中；通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供第三服务端获取并执行。可以看到，本申请将所有第一服务端的延时任务统一放到第二服务端中一个延时队列进行维护，具体的通过延时队列中的定时任务进行扫描延时桶，当到达或超过延时间的延时任务放入准备执行链表中，以使对应的第三服务端进行延时任务的消费。不需要每个服务端分别对延时任务进行维护，降低了维护的成本。

进一步的，如图6所示，所述存入单元22包括：

获取模块221，用于获取延时任务的标识信息和类型；

存入模块222，用于将所有的延时任务的标识信息存入对应的延时桶中，不同类型的延时任务对应不同的延时桶。

进一步的，如图6所示，所述扫描单元23包括：

判断模块231，用于通过定时任务轮询各个延时桶，判断延时桶中的延时任务对应的延时时间是否大于等于当前时间；

放入模块232，用于若大于等于当前时间，则将大于等于当前时间的延时任务的标识信息放入到准备执行链表中。

进一步的，如图6所示，所述装置还包括：

获取单元24，用于在则将大于等于当前时间的延时任务的标识信息放入到准备执行列表中之前，获取大于等于当前时间的延时任务的状态信息；

执行单元25，用于若状态信息为非完成或者非删除，则执行将大于等于当前时间的延时任务的标识信息放入到准备执行链表中；

轮询单元26，用于若状态信息为完成或者删除，则继续轮询。

进一步的，如图6所示，所述装置还包括：

第二接收单元27，用于接收第三服务端返回的延时任务执行结果；

移除单元28，用于根据执行结果修改延时任务的状态信息以及将执行完成或者删除的延时任务从延时队列中移除。

进一步的，如图6所示，所述装置还包括：

判断单元29，用于对于已经被第三服务端读取的延时任务，判断是否在执行时间内完成执行；

返回单元210，用于若否，则将已经读取的延时任务返回到延时桶中。

进一步的，所述定时任务为多个定时任务，所述扫描单元23还用于：

通过每个延时桶对应的定时任务扫描延时桶，不同类型的延时桶对应不同的定时任务。

具体的，本申请实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述，此处不再赘述。

根据本申请实施例，还提供了一种分布式延时调度系统，该系统包括第一服务端、第二服务端、第三服务端：

所述第一服务端，用于生成延时任务，并将其发送给所述第二服务端；

所述第二服务端，用于执行上述方法实施例中分布式延时调度的方法；

所述第三服务端，用于从所述第二服务端中的准备执行链表中获取延时任务并执行。

具体的，本申请实施例的中各功能实现的具体过程可参见方法实施例中的相关描述，此处不再赘述。

从以上的描述中，可以看出，本申请实施例中分布式延时调度系统中，第二服务端接收多个第一服务端推送的延时任务；将所有的延时任务存入延时队列的延时桶中；通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供第三服务端获取并执行。可以看到，本申请将所有第一服务端的延时任务统一放到第二服务端中一个延时队列进行维护，具体的通过延时队列中的定时任务进行扫描延时桶，当到达或超过延时间的延时任务放入准备执行链表中，以使对应的第三服务端进行延时任务的消费。不需要每个服务端分别对延时任务进行维护，降低了维护的成本。

根据本申请实施例，还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行图1所述的分布式延时调度方法。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

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

Claims (10)

1.一种分布式延时调度方法，其特征在于，所述方法包括：

第二服务端接收多个第一服务端推送的延时任务；

将所有的延时任务存入延时队列的延时桶中；

通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供与延时任务对应的第三服务端获取并执行。

2.根据权利要求1所述的分布式延时调度方法，其特征在于，所述将所有的延时任务存入延时队列的延时桶中包括：

获取延时任务的标识信息和类型；

将所有的延时任务的标识信息存入对应的延时桶中，不同类型的延时任务对应不同的延时桶。

3.根据权利要求2所述的分布式延时调度方法，其特征在于，所述通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中包括：

通过定时任务轮询各个延时桶，判断延时桶中的延时任务对应的延时时间是否大于等于当前时间；

若大于等于当前时间，则将大于等于当前时间的延时任务的标识信息放入到准备执行链表中。

4.根据权利要求3所述的分布式延时调度方法，其特征在于，在则将大于等于当前时间的延时任务的标识信息放入到准备执行列表中之前，所述方法还包括：

获取大于等于当前时间的延时任务的状态信息；

若状态信息为非完成或者非删除，则执行将大于等于当前时间的延时任务的标识信息放入到准备执行链表中；

若状态信息为完成或者删除，则继续轮询。

5.根据权利要求1所述的分布式延时调度方法，其特征在于，所述方法还包括：

接收第三服务端返回的延时任务执行结果；

根据执行结果修改延时任务的状态信息以及将执行完成或者删除的延时任务从延时队列中移除。

6.根据权利要求1所述的分布式延时调度方法，其特征在于，所述方法还包括：

对于已经被第三服务端读取的延时任务，判断是否在执行时间内完成执行；

若否，则将已经读取的延时任务返回到延时桶中。

7.根据权利要求1所述的分布式延时调度方法，其特征在于，所述定时任务为多个定时任务，所述通过定时任务扫描延时桶包括：

通过每个延时桶对应的定时任务扫描延时桶，不同类型的延时桶对应不同的定时任务。

8.一种分布式延时调度装置，其特征在于，所述装置包括：

第一接收单元，用于第二服务端接收多个第一服务端推送的延时任务；

存入单元，用于将所有的延时任务存入延时队列的延时桶中；

扫描单元，用于通过定时任务扫描延时桶，定时将到达或超过延时间的延时任务放入准备执行链表中，以供第三服务端获取并执行。

9.一种分布式延时调度系统，所述系统包括第一服务端、第二服务端、第三服务端：

所述第一服务端，用于生成延时任务，并将其发送给所述第二服务端；

所述第二服务端，用于执行上述权利要求1-7中任一项所述分布式延时调度的方法；

所述第三服务端，用于从所述第二服务端中的准备执行链表中获取延时任务并执行。

10.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行权利要求1至权利要求7中任一项所述的分布式延时调度方法。

Images