java定时器怎么设置时间【java 定时器时间表达式】 收藏 0

Spring Schedule定时用法详解

java开发的小伙伴们在业务开发中需要用到执行定时任务的情况下非常多，今天就介绍下使用Spring Schedule来做定时任务。

Spring Schedule是一个强大的工具，用于在Java应用程序中调度和执行定时任务。通过使用Spring Schedule，开发者可以轻松地创建和管理定时任务，而无需依赖外部的调度框架或服务。本文将详细介绍如何在Spring项目中配置和使用Scheduled任务。

首先，确保你的项目已经包含Spring Boot Starter依赖。如果还没有，请在你的pom.xml文件中添加以下内容：

在Spring Boot应用的主类上添加@EnableScheduling注解，以启用定时任务的支持。

创建一个带有@Scheduled注解的方法来定义定时任务。你可以指定多种不同的时间表达式来控制任务的执行频率。

fixedRate属性表示任务之间的固定时间间隔，单位为毫秒。无论任务执行需要多长时间，下一个任务都会在前一个任务完成后等待指定的时间间隔后开始。

fixedDelay属性表示前一个任务完成后到下一个任务开始之间的固定时间间隔，单位为毫秒。如果任务执行时间超过了指定的延迟时间，那么下一次执行将在任务完成后立即开始。

cron属性允许你使用标准的cron表达式来定义复杂的调度规则。例如：

• \”0 0 12 * * ?\”: 每天中午12点执行一次。
• \”*/5 * * * * ?\”: 每5秒执行一次。
• \”0 0/5 14 * * ?\”: 每天下午2点到2:55之间，每5分钟执行一次。

有时候，你可能需要在运行时动态地修改定时任务的执行频率或其他属性。可以通过编程方式实现这一点。

• 线程池：默认情况下，Spring使用一个简单的单线程调度器来执行定时任务。如果你的应用有多个定时任务，并且这些任务需要并发执行，建议配置一个更大的线程池。可以在application.properties或application.yml中进行配置：

• 事务管理：默认情况下，定时任务不会开启事务支持。如果需要在定时任务中使用事务，可以手动开启：

• 异常处理：确保在定时任务中妥善处理异常，以避免由于未捕获的异常导致整个应用崩溃。可以使用try-catch块来捕获并处理异常。

以下是一个简单的Spring Boot项目的结构示例，展示了如何组织定时任务相关的代码：

创作不易，如果这篇文章对你有用，欢迎点赞关注加评论哦。

飘了飘了，Java中定时任务的6种实现方式，你知道几种？

几乎在所有的项目中，定时任务的使用都是不可或缺的，如果使用不当甚至会造成资损。还记得多年前在做金融系统时，出款业务是通过定时任务对外打款，当时由于银行接口处理能力有限，外加定时任务使用不当，导致发出大量重复出款请求。还好在后面环节将交易卡在了系统内部，未发生止损。

所以，系统的学习一下定时任务，是非常有必要的。这篇文章就带大家整体梳理学习一下Java领域中常见的几种定时任务实现。

先从最原始最简单的方式来讲解。可以先创建一个thread，然后让它在while循环里一直运行着，通过sleep方法来达到定时任务的效果。

这种方式简单直接，但是能够实现的功能有限，而且需要自己来实现。

目前来看，JDK自带的Timer API算是最古老的定时任务实现方式了。Timer是一种定时器工具，用来在一个后台线程计划执行指定任务。它可以安排任务“执行一次”或者定期“执行多次”。

在实际的开发当中，经常需要一些周期性的操作，比如每5分钟执行某一操作等。对于这样的操作最方便、高效的实现方式就是使用java.util.Timer工具类。

Timer类的核心方法如下：

下面用几个示例演示一下核心方法的使用。首先定义一个通用的TimerTask类，用于定义用执行的任务。

在指定延迟时间后执行一次，这类是比较常见的场景，比如：当系统初始化某个组件之后，延迟几秒钟，然后进行定时任务的执行。

执行上述代码，延迟一秒之后执行定时任务，并打印结果。其中第二个参数单位为毫秒。

在指定的延迟时间开始执行定时任务，定时任务按照固定的间隔进行执行。比如：延迟2秒执行，固定执行间隔为1秒。

执行程序，会发现2秒之后开始每隔1秒执行一次。

在指定的延迟时间开始执行定时任务，定时任务按照固定的速率进行执行。比如：延迟2秒执行，固定速率为1秒。

执行程序，会发现2秒之后开始每隔1秒执行一次。

此时，你是否疑惑schedule与scheduleAtFixedRate效果一样，为什么提供两个方法，它们有什么区别？

在了解schedule与scheduleAtFixedRate方法的区别之前，先看看它们的相同点：

• 任务执行未超时，下次执行时间 = 上次执行开始时间 + period；
• 任务执行超时，下次执行时间 = 上次执行结束时间；

在任务执行未超时时，它们都是上次执行时间加上间隔时间，来执行下一次任务。而执行超时时，都是立马执行。

它们的不同点在于侧重点不同，schedule方法侧重保持间隔时间的稳定，而scheduleAtFixedRate方法更加侧重于保持执行频率的稳定。

schedule方法会因为前一个任务的延迟而导致其后面的定时任务延时。计算公式为scheduledExecutionTime(第n+1次) = realExecutionTime(第n次) + periodTime。

也就是说如果第n次执行task时，由于某种原因这次执行时间过长，执行完后的systemCurrentTime>= scheduledExecutionTime(第n+1次)，则此时不做时隔等待，立即执行第n+1次task。

而接下来的第n+2次task的scheduledExecutionTime(第n+2次)就随着变成了realExecutionTime(第n+1次)+periodTime。这个方法更注重保持间隔时间的稳定。

scheduleAtFixedRate在反复执行一个task的计划时，每一次执行这个task的计划执行时间在最初就被定下来了，也就是scheduledExecutionTime(第n次)=firstExecuteTime +n*periodTime。

如果第n次执行task时，由于某种原因这次执行时间过长，执行完后的systemCurrentTime>= scheduledExecutionTime(第n+1次)，则此时不做period间隔等待，立即执行第n+1次task。

接下来的第n+2次的task的scheduledExecutionTime(第n+2次)依然还是firstExecuteTime+（n+2)*periodTime这在第一次执行task就定下来了。说白了，这个方法更注重保持执行频率的稳定。

如果用一句话来描述任务执行超时之后schedule和scheduleAtFixedRate的区别就是：schedule的策略是错过了就错过了，后续按照新的节奏来走；scheduleAtFixedRate的策略是如果错过了，就努力追上原来的节奏（制定好的节奏）。

Timer计时器可以定时（指定时间执行任务）、延迟（延迟5秒执行任务）、周期性地执行任务（每隔个1秒执行任务）。但是，Timer存在一些缺陷。首先Timer对调度的支持是基于绝对时间的，而不是相对时间，所以它对系统时间的改变非常敏感。

其次Timer线程是不会捕获异常的，如果TimerTask抛出的了未检查异常则会导致Timer线程终止，同时Timer也不会重新恢复线程的执行，它会错误的认为整个Timer线程都会取消。同时，已经被安排但尚未执行的TimerTask也不会再执行了，新的任务也不能被调度。故如果TimerTask抛出未检查的异常，Timer将会产生无法预料的行为。

ScheduledExecutorService是JAVA 1.5后新增的定时任务接口，它是基于线程池设计的定时任务类，每个调度任务都会分配到线程池中的一个线程去执行。也就是说，任务是并发执行，互不影响。

需要注意：只有当执行调度任务时，ScheduledExecutorService才会真正启动一个线程，其余时间ScheduledExecutorService都是出于轮询任务的状态。

ScheduledExecutorService主要有以下4个方法：

其中scheduleAtFixedRate和scheduleWithFixedDelay在实现定时程序时比较方便，运用的也比较多。

ScheduledExecutorService中定义的这四个接口方法和Timer中对应的方法几乎一样，只不过Timer的scheduled方法需要在外部传入一个TimerTask的抽象任务。而ScheduledExecutorService封装的更加细致了，传Runnable或Callable内部都会做一层封装，封装一个类似TimerTask的抽象任务类（ScheduledFutureTask）。然后传入线程池，启动线程去执行该任务。

scheduleAtFixedRate方法，按指定频率周期执行某个任务。定义及参数说明：

参数对应含义：command为被执行的线程；initialDelay为初始化后延时执行时间；period为两次开始执行最小间隔时间；unit为计时单位。

使用实例：

上面是scheduleAtFixedRate方法的基本使用方式，但当执行程序时会发现它并不是间隔1秒执行的，而是间隔2秒执行。

这是因为，scheduleAtFixedRate是以period为间隔来执行任务的，如果任务执行时间小于period，则上次任务执行完成后会间隔period后再去执行下一次任务；但如果任务执行时间大于period，则上次任务执行完毕后会不间隔的立即开始下次任务。

scheduleWithFixedDelay方法，按指定频率间隔执行某个任务。定义及参数说明：

参数对应含义：command为被执行的线程；initialDelay为初始化后延时执行时间；period为前一次执行结束到下一次执行开始的间隔时间（间隔执行延迟时间）；unit为计时单位。

使用实例：

上面是scheduleWithFixedDelay方法的基本使用方式，但当执行程序时会发现它并不是间隔1秒执行的，而是间隔3秒。

这是因为scheduleWithFixedDelay是不管任务执行多久，都会等上一次任务执行完毕后再延迟delay后去执行下次任务。

除了JDK自带的API之外，我们还可以使用开源的框架来实现，比如Quartz。

Quartz是Job scheduling（作业调度）领域的一个开源项目，Quartz既可以单独使用也可以跟spring框架整合使用，在实际开发中一般会使用后者。使用Quartz可以开发一个或者多个定时任务，每个定时任务可以单独指定执行的时间，例如每隔1小时执行一次、每个月第一天上午10点执行一次、每个月最后一天下午5点执行一次等。

Quartz通常有三部分组成：调度器（Scheduler）、任务（JobDetail）、触发器（Trigger，包括SimpleTrigger和CronTrigger）。下面以具体的实例进行说明。

要使用Quartz，首先需要在项目的pom文件中引入相应的依赖：

定义执行任务的Job，这里要实现Quartz提供的Job接口：

创建Scheduler和Trigger，并执行定时任务：

执行程序，可以看到每1秒执行一次定时任务。

在上述代码中，其中Job为Quartz的接口，业务逻辑的实现通过实现该接口来实现。

JobDetail绑定指定的Job，每次Scheduler调度执行一个Job的时候，首先会拿到对应的Job，然后创建该Job实例，再去执行Job中的execute()的内容，任务执行结束后，关联的Job对象实例会被释放，且会被JVM GC清除。

Trigger是Quartz的触发器，用于通知Scheduler何时去执行对应Job。SimpleTrigger可以实现在一个指定时间段内执行一次作业任务或一个时间段内多次执行作业任务。

CronTrigger功能非常强大，是基于日历的作业调度，而SimpleTrigger是精准指定间隔，所以相比SimpleTrigger，CroTrigger更加常用。CroTrigger是基于Cron表达式的。

常见的Cron表达式示例如下：

可以看出，基于Quartz的CronTrigger可以实现非常丰富的定时任务场景。

从Spring 3开始，Spring自带了一套定时任务工具Spring-Task，可以把它看成是一个轻量级的Quartz，使用起来十分简单，除Spring相关的包外不需要额外的包，支持注解和配置文件两种形式。通常情况下在Spring体系内，针对简单的定时任务，可直接使用Spring提供的功能。

基于XML配置文件的形式就不再介绍了，直接看基于注解形式的实现。使用起来非常简单，直接上代码：

如果是在Spring Boot项目中，需要在启动类上添加@EnableScheduling来开启定时任务。

上述代码中，@Component用于实例化类，这个与定时任务无关。@Scheduled指定该方法是基于定时任务进行执行，具体执行的频次是由cron指定的表达式所决定。关于cron表达式上面CronTrigger所使用的表达式一致。与cron对照的，Spring还提供了fixedDelay和fixedRate两种形式的定时任务执行。

fixedDelay和fixedRate的区别于Timer中的区别很相似。

fixedRate有一个时刻表的概念，在任务启动时，T1、T2、T3就已经排好了执行的时刻，比如1分、2分、3分，当T1的执行时间大于1分钟时，就会造成T2晚点，当T1执行完时T2立即执行。

fixedDelay比较简单，表示上个任务结束，到下个任务开始的时间间隔。无论任务执行花费多少时间，两个任务间的间隔始终是一致的。

Spring Task 本身不支持持久化，也没有推出官方的分布式集群模式，只能靠开发者在业务应用中自己手动扩展实现，无法满足可视化，易配置的需求。

以上定时任务方案都是针对单机的，只能在单个JVM进程中使用。而现在基本上都是分布式场景，需要一套在分布式环境下高性能、高可用、可扩展的分布式任务调度框架。

首先，Quartz是可以用于分布式场景的，但需要基于数据库锁的形式。简单来说，quartz的分布式调度策略是以数据库为边界的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性，同时多个节点的异步运行保证了服务的可靠。

因此，Quartz的分布式方案只解决了任务高可用（减少单点故障）的问题，处理能力瓶颈在数据库，而且没有执行层面的任务分片，无法最大化效率，只能依靠shedulex调度层面做分片，但是调度层做并行分片难以结合实际的运行资源情况做最优的分片。

XXL-JOB是一个轻量级分布式任务调度平台。特点是平台化，易部署，开发迅速、学习简单、轻量级、易扩展。由调度中心和执行器功能完成定时任务的执行。调度中心负责统一调度，执行器负责接收调度并执行。

针对于中小型项目，此框架运用的比较多。

除此之外，还有Elastic-Job、Saturn、SIA-TASK等。

Elastic-Job具有高可用的特性，是一个分布式调度解决方案。

Saturn是唯品会开源的一个分布式任务调度平台，在Elastic Job的基础上进行了改造。

SIA-TASK是宜信开源的分布式任务调度平台。

通过本文梳理了6种定时任务的实现，就实践场景的运用来说，目前大多数系统已经脱离了单机模式。对于并发量并不是太高的系统，xxl-job或许是一个不错的选择。

干货！如何实现一个分布式定时器

作者：刘若愚 腾讯WXG后台开发工程师

定时器（Timer）是一种在业务开发中常用的组件，主要用在执行延时通知任务上。本文以笔者在工作中的实践作为基础，介绍如何使用平时部门最常用的组件快速实现一个业务常用的分布式定时器服务。同时介绍了过程中遇到问题的一些解决方案，希望能够给类似场景提供一些解决思路。

定时器（Timer）是一种在指定时间开始执行某一任务的工具（也有周期性反复执行某一任务的Timer，我们这里暂不讨论）。它常常与延迟队列这一概念关联。 那么在什么场景下我才需要使用定时器呢？

我们先看看以下业务场景：

• 当订单一直处于未支付状态时，如何及时地关闭订单，并退还库存？
• 如何定期检查处于退款状态的订单是否已经退款成功？
• 新创建店铺，N天内没有上传商品，系统如何知道该信息，并发送激活短信？

为了解决以上问题，最简单直接的办法就是定时去扫表。每个业务都要维护一个自己的扫表逻辑。 当业务越来越多时，我们会发现扫表部分的逻辑会非常类似。我们可以考虑将这部分逻辑从具体的业务逻辑里面抽出来，变成一个公共的部分。这个时候定时器就出场了。

一个定时器本质上是这样的一个数据结构：deadline越近的任务拥有越高优先级，提供以下几种基本操作：

1. Add 新增任务；
2. Delete 删除任务；
3. Run 执行到期的任务/到期通知对应业务处理；
4. Update 更新到期时间 (可选)。

Run通常有两种工作方式： 1.轮询 每隔一个时间片就去查找哪些任务已经到期； 2.睡眠/唤醒 不停地查找deadline最近的任务，如到期则执行；否则sleep直到其到期。 在sleep期间，如果有任务被Add或Delete，则deadline最近的任务有可能改变，线程会被唤醒并重新进行1的逻辑。

它的设计目标通常包含以下几点要求：

1. 支持任务提交（消息发布）、任务删除、任务通知（消息订阅）等基本功能。
2. 消息传输可靠性：消息进入延迟队列以后，保证至少被消费一次（到期通知保证At-least-once ，追求Exactly-once）。
3. 数据可靠性：数据需要持久化，防止丢失。
4. 高可用性：至少得支持多实例部署。挂掉一个实例后，还有后备实例继续提供服务，可横向扩展。
5. 实时性：尽最大努力准时交付信息，允许存在一定的时间误差，误差范围可控。

下面我们谈谈定时器的数据结构。定时器通常与延迟队列密不可分，延时队列是什么？顾名思义它是一种带有延迟功能的消息队列。而延迟队列底层通常可以采用以下几种数据结构之一来实现：

1. 有序链表，这个最直观，最好理解。
2. 堆，应用实例如Java JDK中的DelayQueue、Go内置的定时器等。
3. 时间轮/多级时间轮，应用实例如Linux内核定时器、Netty工具类HashedWheelTimer、Kafka内部定时器等。

这里重点介绍一下时间轮（TimeWheel）。一个时间轮是一个环形结构，可以想象成时钟，分为很多格子，一个格子代表一段时间（越短Timer精度越高），并用一个List保存在该格子上到期的所有任务，同时一个指针随着时间流逝一格一格转动，并执行对应List中所有到期的任务。任务通过取模决定应该放入哪个格子。示意图如下所示：

时间轮

如果任务的时间跨度很大，数量也多，传统的单轮时间轮会造成任务的round很大，单个格子的任务List很长，并会维持很长一段时间。这时可将Wheel按时间粒度分级（与水表的思想很像），示意图如下所示：

多级时间轮

时间轮是一种比较优雅的实现方式，且如果采用多级时间轮时其效率也是比较高的。

业界对于定时器/延时队列的工程实践，则通常基于以下几种方案来实现:

1. 基于Redis ZSet实现。
2. 采用某些自带延时选项的队列实现，如RabbitMQ、Beanstalkd、腾讯TDMQ等。
3. 基于Timing-Wheel时间轮算法实现。

介绍完定时器的背景知识，接下来看下我们系统的实现。我们先看一下需求背景。在我们组的实际业务中，有延迟任务的需求。一种典型的应用场景是：商户发起扣费请求后，立刻为用户下发扣费前通知，24小时后完成扣费；或者发券给用户，3天后通知用户券过期。基于这种需求背景，我们引出了定时器的开发需求。

我们首先调研了公司内外的定时器实现，避免重复造轮子。调研了诸如例如公司外部的Quartz、有赞的延时队列等，以及公司内部的PCG tikker、TDMQ等，以及微信支付内部包括营销、代扣、支付分等团队的一些实现方案。最后从可用性、可靠性、易用性、时效性以及代码风格、运维代价等角度考虑，我们决定参考前人的一些优秀的技术方案，并根据我们团队的技术积累和组件情况，设计和实现一套定时器方案。

首先要确定定时器的存储数据结构。这里借鉴了时间轮的思想，基于微信团队最常用的存储组件tablekv进行任务的持久化存储。使用到tablekv的原因是它天然支持按uin分表，分表数可以做到千万级别以上；其次其单表支持的记录数非常高，读写效率也很高，还可以如mysql一样按指定的条件筛选任务。

我们的目标是实现秒级时间戳精度，任务到期只需要单次通知业务方。故我们方案主要的思路是基于tablekv按任务执行时间分表，也就是使用使用方指定的start_time（时间戳）作为分表的uin，也即是时间轮bucket。为什么不使用多轮时间轮？主要是因为首先kv支持单表上亿数据， 其二kv分表数可以非常多，例如我们使用1000万个分表需要约115天的间隔才会被哈希分配到同一分表内。故暂时不需要使用到多轮时间轮。

最终我们采用的分表数为1000w，uin=时间戳mod分表数。这里有一个注意点，通过mod分表数进行Key收敛, 是为了避免时间戳递增导致的key无限扩张的问题。示例图如下所示：

kv时间轮

任务持久化存储之后，我们采用一个Daemon程序执行定期扫表任务，将到期的任务取出，最后将请求中带的业务信息（biz_data添加任务时带来，定时器透传，不关注其具体内容）回调通知业务方。这么一看流程还是很简单的。

这里扫描的流程类似上面讲的时间轮算法，会有一个指针（我们在这里不妨称之为time_pointer）不断向后移动，保证不会漏掉任何一个bucket的任务。这里我们采用的是commkv（可以简单理解为可以按照key-value形式读写的kv，其底层仍是基于tablekv实现）存储CurrentTime，也就是当前处理到的时间戳。每次轮询时Daemon都会通过GetByKey接口获取到CurrentTime，若大于当前机器时间，则sleep一段时间。若小于等于当前机器时间，则取出tablekv中以CurrentTime为uin的分表的TaskList进行处理。本次轮询结束，则CurrentTime加一，再通过SetByKey设置回commkv。这个部分的工作模式我们可以简称为Scheduler。

Scheduler拿到任务后只需要回调通知业务方即可。如果采用同步通知业务方的方式，由于业务方的超时情况是不可控的，则一个任务的投递时间可能会较长，导致拖慢这个时间点的任务整体通知进度。故而这里自然而然想到采用异步解耦的方式。即将任务发布至事件中心（微信内部的高可用、高可靠的消息平台，支持事务和非事务消息。

由于一个任务的投递到事件中心的时间仅为几十ms，理论上任务量级不大时1s内都可以处理完。此时time_pointer会紧跟当前时间戳。当大量任务需要处理时，需要采用多线程/多协程的方式并发处理，保证任务的准时交付。broker订阅事件中心的消息，接受到消息后由broker回调通知业务方，故broker也充当了Notifier的角色。整体架构图如下所示：

架构图

主要模块包括：

任务扫描Daemon：充当Scheduler的角色。扫描所有到期任务，投递到事件中心，让它通知broker，由broker的Notifier通知业务方。

定时器broker：集业务接入、Notifier两者功能于一身。

任务状态机图如下所示，只有两种状态。当任务插入kv成功时即为pending状态，当任务成功被取出并通知业务方成功时即为finish状态。

下面就上面的方案涉及的几个技术细节进行进一步的解释。

通过biz_type定义不同的业务类型，不同的biz_type可以定义不同的优先级（目前暂未支持），任务中保存biz_type信息。 业务信息（主键为biz_type）采用境外配置中心进行配置管理。方便新业务的接入和配置变更。业务接入时，需要在配置中添加诸如回调通知信息、回调重试次数限制、回调限频等参数。业务隔离的目的在于使各个接入业务不受其他业务的影响，这一点由于目前我们的定时器用于支持本团队内部业务的特点，仅采取对不同的业务执行不同业务限频规则的策略，并未做太多优化工作，就不详述了。

由于1000w分表，肯定是大部分Bucket为空，时间轮的指针推进存在低效问题。联想到在饭店排号时，常有店员来登记现场尚存的号码，就是因为可以跳过一些号码，加快叫号进度。同理，为了减少这种“空推进”，Kafka引入了DelayQueue，以bucket为单位入队，每当有bucket到期，即queue.poll能拿到结果时，才进行时间的“推进”，减少了线程空转的开销。在这里类似的，我们也可以做一个优化，维护一个有序队列，保存表不为空的时间戳。大家可以思考一下如何实现，具体方案不再详述。

由于定时器需要写kv，还需要回调通知业务方。因此需要考虑对调用下游服务做限频，保证下游服务不会雪崩。这是一个分布式限频的问题。这里使用到的是微信支付的限频组件。保证1.任务插入时不超过定时器管理员配置的频率。 2.Notifier回调通知业务方时不超过业务方申请接入时配置的频率。这里保证了1.kv和事件中心不会压力太大。2.下游业务方不会受到超过其处理能力的请求量的冲击。

出于容灾的目的，我们希望Daemon具有容灾能力。换言之若有Daemon实例异常挂起或退出，其他机器的实例进程可以继续执行任务。但同时我们又希望同一时刻只需要一个实例运行，即“分布式单实例”。所以我们完整的需求可以归纳为**“分布式单实例容灾部署”**。

实现这一目标，方式有很多种，例如：

• 接入“调度中心”，由调度中心来负责调度各个机器
• 各节点在执行任务前先分布式抢锁，只有成功占用锁资源的节点才能执行任务
• 各节点通过通信选出“master\”来执行逻辑，并通过心跳包持续通信，若“master”掉线，则备机取代成为master继续执行

主要从开发成本，运维支撑两方面来考虑，选取了基于chubby分布式锁的方案来实现单实例容灾部署。这也使得我们真正执行业务逻辑的机器具有随机性。

这是一个核心问题，如何保证任务的通知满足At-least-once的要求？

我们系统主要通过以下两种方式来保证。

1.任务达到时即存入tablekv持久化存储，任务成功通知业务方才设置过期（保留一段时间后删除），故而所有任务都是落地数据，保证事后可以对账。

2.引入可靠事件中心。在这里使用的是事件中心的普通消息，而非事务消息。实质是当做一个高可用性的消息队列。

这里引入消息队列的意义在于：

• 将任务调度和任务执行解耦（调度服务并不需要关心任务执行结果）。
• 异步化，保证调度服务的高效执行，调度服务的执行是以ms为单位。
• 借助消息队列实现任务的可靠消费。

事件中心相比普通的消息队列还具有哪些优点呢？

• 某些消息队列可能丢消息（由其实现机制决定），而事件中心本身底层的分布式架构，使得事件中心保证极高的可用性和可靠性，基本可以忽略丢消息的情况。
• 事件中心支持按照配置的不同事件梯度进行多次重试（回调时间可以配置）。
• 事件中心可以根据自定义业务ID进行消息去重。

事件中心的引入，基本保证了任务从Scheduler到Notifier的可靠性。

当然，最为完备的方式，是增加另一个异步Daemon作为兜底策略，扫出所有超时还未交付的任务进行投递。这里思路较为简单，不再详述。

若同一时间点有大量任务需要处理，如果采用串行发布至事件中心，则仍可能导致任务的回调通知不及时。这里自然而然想到采用多线程/多协程的方式并发处理。在本系统中，我们使用到了微信的BatchTask库，BatchTask是这样一个库，它把每一个需要并发执行的RPC任务封装成一个函数闭包（返回值+执行函数+参数），然后调度协程（BatchTask的底层协程为libco）去执行这些任务。对于已有的同步函数，可以很方便地通过BatchTask的Api去实现任务的批量执行。Daemon将发布事件的任务提交到BatchTask创建的线程池+协程池（线程和协程数可以根据参数调整）中，充分利用流水线和并发，可以将任务List处理的整体时延大大缩短，尽最大努力及时通知业务方。

从节省存储资源考虑，任务通知业务成功后应当删除。但删除应该是一个异步的过程，因为还需要保留一段时间方便查询日志等。这种情况，通常的实现方式是启动一个Daemon异步删除已完成的任务。我们系统中，是利用了tablekv的自动删除机制，回调通知业务完成后，除了设置任务状态为完成外，同时通过tablekv的update接口设置kv的过期时间为1个月，避免了异步Daemon扫表删除任务，简化了实现。

1.由于time_pointer的CurrentTime初始值置为首次运行的Daemon实例的机器时间，而每次轮询时都会对比当前Daemon实例的机器时间与CurrentTime的差别，故机器时间出错可能会影响任务的正常调度。这里考虑到现网机器均有时间校正脚本在跑，这个问题基本可以忽略。

2.本系统的架构对事件中心构成了强依赖。定时器的可用性和可靠性依赖于事件中心的可用性和可靠性。虽然目前事件中心的可用性和可靠性都非常高，但如果要考虑所有异常情况，则事件中心的短暂不可用、或者对于订阅者消息出队的延迟和堆积，都是需要正视的问题。一个解决方案是使用MQ做双链路的消息投递，解决对于事件中心单点依赖的问题。

这里的定时器服务目前仅用于支持境外的定时器需求，调用量级尚不大，已可满足业务基本要求。如果要支撑更高的任务量级，还需要做更多的思考和优化。随时欢迎大家和和我交流探讨。

【福利】

感谢一直支持腾讯技术工程的朋友，我们将抽2位粉丝送出 短鹅！

参与请戳，快把短鹅抱回家~

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com