什么是任务调度

我们可以先思考一下下面业务场景的解决方案：

• 某电商系统需要在每天上午10点，下午3点，晚上8点发放一批优惠券。
• 某银行系统需要在信用卡到期还款日的前三天进行短信提醒。
• 某财务系统需要在每天凌晨0:10结算前一天的财务数据，统计汇总。
• 12306会根据车次的不同，而设置某几个时间点进行分批放票。
• 某网站为了实现天气实时展示，每隔5分钟就去天气服务器获取最新的实时天气信息。

以上场景就是任务调度所需要解决的问题。

任务调度是指系统为了自动完成特定任务，在约定的特定时刻去执行任务的过程。有了任务调度即可解放更多的人力由系统自动去执行任务。

任务调度如何实现？

多线程方式实现：

学过多线程的同学，可能会想到，我们可以开启一个线程，每sleep一段时间，就去检查是否已到预期执行时间。

以下代码简单实现了任务调度的功能：

public static void main(String[] args) {    
  	//任务执行间隔时间
    final long timeInterval = 1000;
    Runnable runnable = new Runnable() {
        public void run() {
            while (true) {
                //TODO：something
                try {
                    Thread.sleep(timeInterval);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    };
    Thread thread = new Thread(runnable);
    thread.start();
}

上面的代码实现了按一定的间隔时间执行任务调度的功能。

Jdk也为我们提供了相关支持，如Timer、ScheduledExecutor，下边我们了解下。

Timer方式实现：

public static void main(String[] args){  
   	Timer timer = new Timer();  
   	timer.schedule(new TimerTask(){
        @Override  
        public void run() {  
           //TODO：something
        }  
	}, 1000, 2000);  //1秒后开始调度，每2秒执行一次
}

Timer 的优点在于简单易用，每个Timer对应一个线程，因此可以同时启动多个Timer并行执行多个任务，同一个Timer中的任务是串行执行。

ScheduledExecutor方式实现：

public static void main(String [] agrs){
    ScheduledExecutorService service = Executors.newScheduledThreadPool(10);
    service.scheduleAtFixedRate(
            new Runnable() {
                @Override
                public void run() {
                    //TODO：something
                    System.out.println("todo something");
                }
            }, 1,
            2, TimeUnit.SECONDS);
}

Java 5 推出了基于线程池设计的 ScheduledExecutor，其设计思想是，每一个被调度的任务都会由线程池中一个线程去执行，因此任务是并发执行的，相互之间不会受到干扰。

Timer 和 ScheduledExecutor 都仅能提供基于开始时间与重复间隔的任务调度，不能胜任更加复杂的调度需求。比如，设置每月第一天凌晨1点执行任务、复杂调度任务的管理、任务间传递数据等等。

Quartz 是一个功能强大的任务调度框架，它可以满足更多更复杂的调度需求，Quartz 设计的核心类包括 Scheduler, Job 以及 Trigger。其中，Job 负责定义需要执行的任务，Trigger 负责设置调度策略，Scheduler 将二者组装在一起，并触发任务开始执行。Quartz支持简单的按时间间隔调度、还支持按日历调度方式，通过设置CronTrigger表达式（包括：秒、分、时、日、月、周、年）进行任务调度。

第三方Quartz方式实现：

public static void main(String [] agrs) throws SchedulerException {
    //创建一个Scheduler
    SchedulerFactory schedulerFactory = new StdSchedulerFactory();
    Scheduler scheduler = schedulerFactory.getScheduler();
    //创建JobDetail
    JobBuilder jobDetailBuilder = JobBuilder.newJob(MyJob.class);
    jobDetailBuilder.withIdentity("jobName","jobGroupName");
    JobDetail jobDetail = jobDetailBuilder.build();
    //创建触发的CronTrigger 支持按日历调度
        CronTrigger trigger = TriggerBuilder.newTrigger()
                .withIdentity("triggerName", "triggerGroupName")
                .startNow()
                .withSchedule(CronScheduleBuilder.cronSchedule("0/2 * * * * ?"))
                .build();
        //创建触发的SimpleTrigger 简单的间隔调度
        /*SimpleTrigger trigger = TriggerBuilder.newTrigger()
                .withIdentity("triggerName","triggerGroupName")
                .startNow()
                .withSchedule(SimpleScheduleBuilder
                        .simpleSchedule()
                        .withIntervalInSeconds(2)
                        .repeatForever())
                .build();*/
    scheduler.scheduleJob(jobDetail,trigger);
    scheduler.start();
}

public class MyJob implements Job {
    @Override
    public void execute(JobExecutionContext jobExecutionContext){
        System.out.println("todo something");
    }
}

通过以上内容我们学习了什么是任务调度，任务调度所解决的问题，以及任务调度的多种实现方式。

2.什么是分布式任务调度

​ 什么是分布式？

当前软件的架构正在逐步转变为分布式架构，将单体结构分为若干服务，服务之间通过网络交互来完成用户的业务处理，如下图，电商系统为分布式架构，由订单服务、商品服务、用户服务等组成：

分布式系统具体如下基本特点：

1. 分布性：每个部分都可以独立部署，服务之间交互通过网络进行通信，比如：订单服务、商品服务。
2. 伸缩性：每个部分都可以集群方式部署，并可针对部分结点进行硬件及软件扩容，具有一定的伸缩能力。
3. 高可用：每个部分都可以集群部分，保证高可用。

什么是分布式调度？

通常任务调度的程序是集成在应用中的，比如：优惠卷服务中包括了定时发放优惠卷的的调度程序，结算服务中包括了定期生成报表的任务调度程序，由于采用分布式架构，一个服务往往会部署多个冗余实例来运行我们的业务，在这种分布式系统环境下运行任务调度，我们称之为分布式任务调度，如下图：

分布式调度要实现的目标：

不管是任务调度程序集成在应用程序中，还是单独构建的任务调度系统，如果采用分布式调度任务的方式就相当于将任务调度程序分布式构建，这样就可以具有分布式系统的特点，并且提高任务的调度处理能力：

1.并行任务调度

并行任务调度实现靠多线程，如果有大量任务需要调度，此时光靠多线程就会有瓶颈了，因为一台计算机CPU的处理能力是有限的。

如果将任务调度程序分布式部署，每个结点还可以部署为集群，这样就可以让多台计算机共同去完成任务调度，我们可以将任务分割为若干个分片，由不同的实例并行执行，来提高任务调度的处理效率。

2.高可用

若某一个实例宕机，不影响其他实例来执行任务。

3.弹性扩容

当集群中增加实例就可以提高并执行任务的处理效率。

4.任务管理与监测

对系统中存在的所有定时任务进行统一的管理及监测。让开发人员及运维人员能够时刻了解任务执行情况，从而做出快速的应急处理响应。

5.避免任务重复执行

当任务调度以集群方式部署，同一个任务调度可能会执行多次，比如在上面提到的电商系统中到点发优惠券的例子，就会发放多次优惠券，对公司造成很多损失，所以我们需要控制相同的任务在多个运行实例上只执行一次，考虑采用下边的方法：

• 分布式锁，多个实例在任务执行前首先需要获取锁，如果获取失败那么久证明有其他服务已经再运行，如果获取成功那么证明没有服务在运行定时任务，那么就可以执行。

• ZooKeeper选举，利用ZooKeeper对Leader实例执行定时任务，有其他业务已经使用了ZK，那么执行定时任务的时候判断自己是否是Leader，如果不是则不执行，如果是则执行业务逻辑，这样也能达到我们的目的。

分布式任务调度

1. 分布式集群模式下，使用集中式任务调度会带来的问题

   （1） 多台机器集群部署的定时任务如何保证不被重复执行？

   （2） 如何在不重启服务的情况下动态调整定时任务的执行时间？

   （3） 部署定时任务的机器发生故障如何实现故障转移？

   （4） 如何对定时任务实现监控？

   （5） 业务量较大，单机性能瓶颈时，如何扩展？

2. 分布式任务调度解决方案

   （1） 数据库唯一约束，避免定时任务重复执行（分布式锁）

   （2） 使用配置文件、redis、mysql作为调度开关（存储调度任务数据）

   （3） 使用分布式锁实现任务调度

   （4） 使用分布式任务调度平台 TBSchedule、Elastric-job、Saturn、XXL-JOB，Google Cron系统；

3. TBSchedule（已停止更新，推荐使用SchedulerX）

   （1） 概念介绍

   ​ TBSchedule是一个支持分布式的调度框架，能让一种批量任务或者不断变化的任务，被动态的分配到多个主机的JVM中，不同的线程组中并行执行。基于ZooKeeper的纯Java实现，由Alibaba开源。

   （2） 工作原理

   TBSchesule对分布式的支持包括调度机的分布式和执行机的分布式，其网络部署架构图如下：

   

   （3）GitHub地址

   https://github.com/nmyphp/tbschedule

4. Elastric-job

   （1） 概念介绍

   ​ Elastic-Job是一个分布式调度的解决方案，由当当网开源，它由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成，使用Elastic-Job可以快速实现分布式任务调度。

   （2） 工作原理

   

   App：应用程序，内部包含任务执行业务逻辑和Elastic-Job-Lite组件，其中执行任务需要实现ElasticJob接口完成与Elastic-Job-Lite组件的集成，并进行任务的相关配置。应用程序可启动多个实例，也就出现了多个任务执行实例。

   Elastic-Job-Lite：Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服
   务，此组件负责任务的调度，并产生日志及任务调度记录。
   无中心化，是指没有调度中心这一概念，每个运行在集群中的作业服务器都是对等的，各个作业节点是自治的、平等的、节点之间通过注册中心进行分布式协调。

   Registry：以Zookeeper作为Elastic-Job的注册中心组件，存储了执行任务的相关信息。同时，Elastic-Job利用该组件进行执行任务实例的选举。
   Console：Elastic-Job提供了运维平台，它通过读取Zookeeper数据展现任务执行状态，或更新Zookeeper数据修改全局配置。通过Elastic-Job-Lite组件产生的数据来查看任务执行历史记录。

   流程：应用程序在启动时，在其内嵌的Elastic-Job-Lite组件会向Zookeeper注册该实例的信息，并触发选举（此时可能已经启动了该应用程序的其他实例），从众多实例中选举出一个Leader，让其执行任务。当到达任务执行时间时，
   Elastic-Job-Lite组件会调用由应用程序实现的任务业务逻辑，任务执行后会产生任务执行记录。当应用程序的某一个实例宕机时，Zookeeper组件会感知到并重新触发leader选举。

5. XXL-JOB

   XXL-JOB是一个开源的，具有丰富的任务管理功能以及高性能，高可用等特点的轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展、开箱即用！！！
   系统组成：

   （1） 调度模块（调度中心）： 负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。调度系统与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块； 支持可视化、简单且动态的管理调度信息，包括任务新建，更新，删除，任务报警等，所有上述操作都会实时生效，同时支持监控调度结果以及执行日志，支持执行器Failover
   （2） 执行模块（执行器）： 负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效； 接收“调度中心”的执行请求、终止请求和日志请求等

   

什么是分布式定时任务调度

定时任务调度

在很多应用场景下我们需要定时执行一些任务，比如订单系统的超时状态判断、缓存数据的定时更新等等，最简单粗暴的方式是用while(true)+sleep的组合来空转，直到到达指定时间就执行任务，但这显然非常低效。更好的方法是使用系统提供的Timer定时器或者使用Quartz框架等等。

持久化

如果只是设置一两个固定的简单的定时任务，比如只需要定时把数据从磁盘更新到内存的缓存中，那不需要考虑太多，即使节点宕机了，重启后就会继续按原有频率继续执行定时任务，所以不需要考虑定时任务的持久化问题。

但是如果业务场景比较复杂，需要设置非常多的定时任务，比如订单系统的超时状态判断，每个用户下单后都需要设置一个30分钟的定时任务，30分钟一到就执行任务判断用户是否已经支付，如果尚未支付就自动取消订单。如果机器在此期间宕机丢失内存数据，那么重启之后将会丢失所有定时任务，一大批的超时的未支付订单都不会被取消。因此，我们往往还需要考虑将定时任务写到磁盘中将其持久化，确保任务能够得到执行。

分布式集群

在单个机器节点上做定时任务调度比较简单直白，但弊端是

• 一旦节点宕机，就无法提供定时任务调度的服务。
• 单个节点的算力有限，无法支持大量定时调度任务。

因此往往需要部署分布式集群来提供定时任务调度服务，分布式的定时任务调度系统需要考虑如何统一管理众多的定时任务

• 如何保证每个任务只被一个节点执行（避免时间点到来时同一任务被重复执行）
• 一个节点宕机时如何让其他节点接管其负责的定时任务
• 等等。。。

Quartz单点

Quartz 是一个完全由 Java 编写的开源作业调度框架。

Quartz基础

参考Quartz-任务调度

三个基础概念

• 任务：需要执行的任务。
• 触发器：触发器用于配置调度参数，设置触发条件。
• 调度器：调度器将对应的触发器和任务绑定在一起，当触发器被触发时执行对应的任务。

使用实例

创建Job

实现Job接口，并且重写execute方法，就是在这个方法里写我们要执行的任务

import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
/** 此类只是用来执行任务代码 */
public class MyJob implements Job 
{ 
   @Override 
   public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException { 
      System.out.println("这里是我们的任务代码"); 
   }
}

创建JobDetail

我们写了MyJob这个类来实现了Job接口，接着我们就要通过创建JobDetail告诉Quartz，MyJob这个类是我们准备要执行的一个任务

 //2.2.3版本 注册任务 方式 
JobDetail job = JobBuilder.newJob(MyJob.class)//设置要执行的任务是哪个类 
                          .withIdentity("helloJob", "group1")//设置任务信息 参数1任务名 参数2为组名
                          .build();//创建

创建Trigger

Quartz主要有两种触发器：

1. SimpleTrigger触发器：设置一些简单的属性，如开始时间、结束时间、重复次数、重复间隔等。
2. CronTrigger触发器：可以使用cron表达式来更灵活的控制时间，例如每年执行一次、每天几点执行、每月几号执行等。

cron格式可以参考crontab格式 & golang时间格式

//Trigger 是触发器接口，要通过TriggerBuilder来实例化一个
TriggerTrigger trigger1 = TriggerBuilder.newTrigger()
                         //withIdentity(String name, String group) 指定触发器信息 参数1触发器名 参数2触发器组,如果不创建将自动生成
                         .withIdentity("trigger1", "test")
                          //withSchedule(ScheduleBuilder schedBuilder) 设置一个实现了ScheduleBuilder接口的触发器 
                         //这里我们演示的是SimpleTrigger触发器，所以要使用SimpleScheduleBuilder.simpleSchedule()方来创建 
                          .withSchedule(SimpleScheduleBuilder.simpleSchedule() 
                         //指定触发间隔,以秒为单位 
                         .withIntervalInSeconds(5)
                          //设置执行次数  
                         .withRepeatCount(5))
                         .build();//创建

Trigger trigger2 = TriggerBuilder.newTrigger() 
                         .withIdentity("cron trigger", "test")
                         .withSchedule(
                         //这里我们演示的是CronTrigger触发器，所以要使用CronScheduleBuilder.cronSchedule()方来创建
                         //每5秒执行一次
 CronScheduleBuilder.cronSchedule("0/5 * * ? * *")).build();

创建Scheduler

通过SchedulerFactory获取Scheduler调度器，并且将一个任务和一个触发器绑定起来

SchedulerFactory schedulerFactory = new StdSchedulerFactory();
try { 
 /** 
   * Scheduler是一个调度器 
   * 一个Scheduler注册JobDetail和Trigger。一旦注册后，Scheduler 负责执行Job, 前提是Trigger的预定时间到达。
   */
   Scheduler scheduler = schedulerFactory.getScheduler();//调用getScheduler()方法来获取一个Scheduler实例
   //使用scheduleJob(JobDetail jobDetail, Trigger trigger) 方法使 任务 & 触发器 发生关联
    scheduler.scheduleJob(job, trigger2); 
   //使用start()方法开启调度 scheduler.start();
   //关闭调度//scheduler.shutdown();
} catch (SchedulerException e) 
{
   e.printStackTrace();
}

至此，一个定时任务就配置完成了。

Quartz调度原理

参考Quartz原理解密

调度线程

Quartz中Scheduler调度线程主要有两类线程：

• Regular Scheduler Thread（执行常规调度）：Regular Thread轮询所有Trigger，如果发现有将要触发的Trigger，就从任务线程池中获取一个空闲线程，然后执行与改Trigger关联的Job。
• Misfire Scheduler Thread（执行错失的任务）：Misfire Thraed轮询所有Trigger，查找有错失的任务，例如系统重启/线程占用等问题导致的任务错失，根据一定的策略进行处理。

存储

Quartz有两种方式将定时任务存储下来：

• RAMJobStore：将trigger和job存储到内存里
• JobStoreSupport：将trigger和job存储到数据库里

为了防止任务数据丢失，Quartz会将trigger和job存储到数据库里，

Quartz集群

参考分布式任务调度方案调研

定时任务的分布式调度

集群环境下防止并发的一种实现（ Spring Quartz 集群思路）

分布式调度策略

除了单机版本外，Quartz也提供了集群方案，它的集群方案是基于数据库实现的。

上图三个节点，每个节点里有许多Scheduler实例（调度器线程），每个Scheduler实例都会去争抢访问数据库中的Trigger，如何保证同一时刻每个Trigger只会被一个Scheduler实例获取并检查？答案是数据库锁（可以理解为用数据库实现了分布式锁）。Quartz集群采用了以数据库作为协调中心的方式，通过表的设计协调不同节点之间的行为：

• QRTZ_SCHEDULER_STATE表：记录Scheduler实例的状态信息
• QRTZ_LOCKS表：记录程序悲观锁的信息

关注QRTZ_LOCKS表，表里只有一个字段

CREATE TABLE QRTZ_LOCKS (
	LOCK_NAME VARCHAR2(40) NOT NULL, 
	PRIMARY KEY (LOCK_NAME）
)

这些数据是根据数据库的业务逻辑操作抽象出的系统所拥有的表的类型，QRTZ_LOCKS主要有两个行级锁

下面都以TRIGGER_ACCESS锁为例子讲解，Scheduler实例流程图：

比如一个Scheduler实例想要访问数据库来看是否有Trigger将要触发，那么它就开一个事务，并且首先获取并占用TRIGGER_ACCESS锁，然后再处理业务，比如说如果检查到有Trigger将要触发，就会去分配线程运行对应的任务。在此期间其他实例都无法访问所有与Trigger业务有关的数据表，处理完业务后commit work，结束事务，TRIGGER_ACCESS锁就被释放出来了，

抽象出来的mysql语句（方便理解）：

mysql> begin work;
mysql> select * from QRTZ_LOCKS where t.lock_name='TRIGGER_ACCESS' for update
#在这里处理业务
mysql> commit work;

如果一个Scheduler实例获取了一个TRIGGER_ACCESS锁但是还没处理完就挂掉了，会导致与Trigger业务有关的表一直处于加锁状态无法被其他Scheduler实例访问，结果所有实例都没法工作了，因此Quartz又提出了一个接管锁的机制：

• 每个Scheduler实例都在QRTZ_SCHEDULER_STATE表里有自己的唯一ID，例如以hostname+time标识；
• 每个Scheduler实例的ClusterManager线程定期往QRTZ_SCHEDULER_STATE表更新LAST_CHECKIN_TIME作为心跳
• 当某个Scheduler实例超过一定时间没有心跳更新时，其它Scheduler实例得到这个信息，会接管对应的行锁，并恢复过时的任务

总结

总的来说，Quartz的分布式调度策略是以数据库为边界资源的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性，同时多个节点的异步运行保证了服务的可靠。

但这种Quartz的分布式调度策略有很多局限：

• 集群特性对于高CPU使用率的任务效果很好，但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。这种情况随着节点的增加会越来越严重。
• 没有实现比较好的负载均衡机制，仅依靠各个节点中的Scheduler实例随机抢占，可能会导致部分节点负载重，部分节点负载轻的情况。
• 不能满足更复杂的功能，如任务分片、编排、暂停重启、失败重试等。