Quartz分布式任务调度原理

Quartz分布式任务调度原理,第1张

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

在很多应用场景下我们需要定时执行一些任务,比如订单系统的超时状态判断、缓存数据的定时更新等等,最简单粗暴的方式是用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 = 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主要有两个行级锁

lock_namedescSTATE_ACCESS状态访问锁TRIGGER_ACCESS触发器访问锁

下面都以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实例随机抢占,可能会导致部分节点负载重,部分节点负载轻的情况。
  • 不能满足更复杂的功能,如任务分片、编排、暂停重启、失败重试等。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5693617.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存