关于定时任务原理

今天来聊一下工作中经常使用的定时任务的底层实现原理

计算机是怎么计时的

计算机内部使用多种方式来计时，主要依赖于硬件时钟（如实时时钟 RTC）和操作系统中的软件时钟机制

1，硬件时钟（Real-Time Clock，RTC）：这是一个位于主板上的芯片，即使在计算机关闭或断电的情况下也能保持时间信息。RTC 通常由一个小电池供电，确保它能够在没有外部电源的情况下继续运行。当计算机启动时，操作系统会读取 RTC 的时间设置，并将其用作系统时间的基础。
2，系统时钟（System Clock）：这是操作系统内核维护的一个计数器，用于跟踪自某个固定点（通常是系统的启动时间）以来经过的时间。系统时钟的精度取决于系统的时钟中断频率，常见的频率有100Hz、1024Hz等，这意味着每秒发生100次或1024次中断。每次中断时，操作系统都会更新其内部的时间记录
3，时间戳（Timestamps）：应用程序经常需要知道当前的时间或者记录事件发生的具体时间。这个在工作中用的很多就不过多赘述
4，网络时间协议（NTP）：为了确保不同设备之间的时间同步，许多计算机通过网络时间协议（NTP）与时间服务器同步时间。NTP 允许计算机从互联网上的时间服务器获取准确的时间信息，并根据这些信息调整自己的时钟，从而实现全球范围内的时钟同步

通过上述机制的结合，计算机能够准确地记录和显示时间，支持各种需要精确时间的应用程序和服务

关于本地定时任务实现

知道了计算机如何计时后，我们就可以开始考虑计算机是如何实现定时任务了。比如我们想让计算机在 x 分钟后执行某种任务，我们可以会起一个线程，每分钟去判断一次当前时间和目标时间是否一致，如果一致就执行任务。但是这么做会占用一个线程资源，很多个任务就会占用很多线程资源，我们应该将这些资源用一个线程来管理

怎么做呢，我们首先会想到用一些数据结构来维护这些资源，然后每隔 x 毫秒判断一下数据结构中的这些资源是否需要执行了，这里的数据结构可以使用比如小根堆、时间轮之类的

小根堆实现

它可以让每次写入的定时任务都按照执行时间进行排序，保证在堆顶的任务执行时间是最小的

这样在需要执行任务时，每次只需要取出堆顶的任务运行即可，所以它取出任务的效率很高

下图是 Timer 小根堆的实现，对于会将写入的任务从队列的中部通过执行时间与前一个任务做比对，一直不断的向前比较，这段逻辑在下图中的 add 方法中

这里我们需要额外考量一些业务上的问题：

后台调度定时任务的线程只有一个，我们应该使用一个线程池来执行实际业务代码，这样某个任务出错也不会影响其他任务执行，并且其他的任务也不需要依赖前置任务执行完毕后才能执行了

时间轮实现

时间轮这个数据结构大家可能不太熟悉，简单介绍一下：

时间轮（Time Wheel）是一种用于高效管理和调度定时任务的数据结构。它特别适用于需要处理大量定时任务的场景，时间轮的设计理念是通过将时间划分成多个槽（Slot），每个槽代表一个固定的时间间隔

当需要添加一个定时任务时，计算该任务的到期时间相对于当前时间的位置。根据到期时间，将任务插入到相应的槽中

指针每经过一个时间间隔（例如1秒）向前移动一个槽。当指针移动到某个槽时，检查该槽中的任务，并执行这些任务

有些同学可能要问，那如果我需要设置的时间离现在太远了，一轮根本装不下，怎么办，我总不能生成一个无限长度的轮子吧。好问题，我们可以用很多个轮子来存放资源，像时针分针秒针一样，任务资源会存放多个轮子的数据，只有所有数据都达标的时候，任务才会执行

时间轮通常用于实现 XX 时间后的延时任务（如定时任务、延迟 MQ 等），或周期性任务

关于分布式任务的实现

给大家介绍一个非常有名的 java 任务调度框架 Quartz，以此为例子来讲解一下分布式任务的实现

在 quartz 的集群解决方案里有张表 QRTZ_LOCKS（因为是分布式的所以不能只将信息存放在内存中），quartz 采用了悲观锁的方式对 triggers 表进行行加锁，以保证任务同步的正确性。一旦某一个节点上面的线程获取了该锁，那么这个 Job 就会在这台机器上被执行，同时这个锁就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁已经被占用了，就只能等待，直到这个锁被释放

quartz 的分布式调度策略是以数据库为边界资源的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性。quartz 用这种方式处理了最简单的分布式调度。下面再额外补充一下 quartz 的核心组件，了解了组件基本上就知道原理了

基础配置讲解

quartz 有几个核心的类：

1，调度器（scheduler）：负责协调任务和触发器，控制任务的启动、暂停、恢复和终止
2，触发器（Trigger）：保存 corn 等时间信息，保存了什么时候应该调用什么任务的信息
3，jobDetail：用来描述 Job 实现类及其它相关的静态信息，如 Job 名字、关联监听器等信息
4，Job：是一个接口，只有一个方法 void execute(JobExecutionContext context)，开发者实现该接口定义运行任务

原理就是 quartz 保存任务详细信息，和触发器。我们还将他们的关联关系保存到了表中，触发器会没隔一段时间就检测是否要执行任务了，以及执行什么任务

步骤1：用户首先需要生成一个调度器工厂 SchedulerFactory，可以用下面的方式实现自己的定制化：

Properties properties=new Properties();    
properties.put("org.quartz.threadPool.class","org.quartz.simpl.SimpleThreadPool");
properties.put("org.quartz.threadPool.threadCount","10");
SchedulerFactory sf=new StdSchedulerFactory(properties);

步骤2：然后通过 getScheduler 方法从调度器工厂里得到调度器实例，首先查找有没有这样的调度器，没有的话，就生成一个，有的话直接返回。所以得到的一般是单例，即默认的调度器

步骤3：Scheduler 有一个 QuartzSchedulerThread（Thread 的子类）属性，在 scheduler 实例化的时候，实例化了一个对象，并用 ThreadExecutor 启动该线程对象。该线程就是调度线程，主要任务就是不停的获取即将被触发的触发器（默认30s调度一次）

步骤4：接下来是任务调度的部分：

Scheduler scheduler=sf.getScheduler();
scheduler.addJobListener(new TaskListener());
scheduler.scheduleJob(jobDetail, simpleTrigger);
scheduler.start();

client 通过 scheduleJob 方法将任务和触发器存储在 JobStore 中，通过 start 方法将 QuartzSchedulerThread 的 pause 状态设为 false，通知调度线程执行任务，此后调度线程不停的从 JobStore 中去取即将触发的任务

底层原理讲解

Quartz 的调度机制是使用了一个叫做 JobStore 的组件来存储任务和触发器

Quartz 默认使用的是 RAMJobStore，也就是内存存储，而持久化的话会用 JDBCJobStore。Quartz 的工作方式，是调度线程会定期检查触发器，判断哪些需要触发，这里有一个 nextFireTime 就保存的是下一次触发时间。这个过程可能基于优先级队列或者类似的结构，当然用时间轮也可以。当触发器触发后，会根据其调度规则（如 Cron 表达式、重复间隔等）重新计算 nextFireTime，并重新插入队列

Quartz 的集群模式是通过数据库持久化来实现的。也就是说，多个 Quartz 实例共享同一个数据库，通过数据库中的表来协调任务的状态和锁。这样，当一个节点失效时，其他节点可以接管任务，确保同一时间只有一个节点执行某个任务

如何管理触发器所记录的时间

当您定义一个使用 Cron 表达式的触发器时，Quartz 会首先解析这个表达式。Quartz 会根据当前时间和 Cron 表达式计算出下一个任务应该执行的具体时间点。这个时间点是一个具体的日期和时间，可以转换成时间戳，插入到优先队列中

当时一个 Cron 表达式会向优先队列中插入很多数据，难道我初始化一个任务，就向优先队列中插入十万条数据了吗？当然不会这样，Quartz 的处理方案是当指针移动到包含任务的时间槽时，任务会被执行。在任务执行时，Quartz 会再次计算下一个执行时间点，并将新的时间点插入到优先队列中

我之前接触的业务中也有类似的业务问题，当时是使用每天0点跑一次定时任务生成隔天的全部数据这种方式处理。但是上线后发现每天0点生成的任务是会有漏的情况，因此补充了一个每隔一分钟生成一次明天当前时间应该执行的任务，现在看来这种处理方案确实比不上 Quartz 的处理方式