quartz 分布式_后端必备分布式技术之-调度系统Quartz设计原理

最新推荐文章于 2023-08-06 22:41:07 发布

weixin_39527911

最新推荐文章于 2023-08-06 22:41:07 发布

阅读量491

点赞数

文章标签： quartz 分布式 quartz获取开始结束时间

调度系统作为分布式系统技术中重要的一环，了解其技术原理必不可少，不同系统内部采用的调度系统叫法不一样，但大致功能都类似，而Quartz作为经典的开源企业级调度系统，怎么能不研究一下呢？

为什么要学习quartz源码？

调度系统很重要而且很常见，quartz又是业内知名产品，在企业中得到了广泛的应用
学习好的系统设计可以提升自己的系统设计能力，后续涉及到任务调度相关功能，做起来更轻松和更稳定

概念

Job代表一个任务实例。 Job由Jobdetail配置的实例信息生成。
JobDetail代表一个任务配置详情。
Trigger代表调度参数的配置，什么时候发起调用，时间策略的调度。
Scheduler：调度容器，一个Scheduler可以注册多个JobDetail和Trigger。只有JobDetail和Trigger组合到一起，才能被Scheduler调度。
JobStore：保存和读取JobDetail与Trigger的地方，可以存储在内存或者数据库中。

Demo

来一段代码实际感受下Quartz的使用方式，有助于了解其概念：

1 假如mvn依赖，mysql和HikariCP用于持久化任务配置。

        org.quartz-scheduler            quartz            2.3.0org.quartz-scheduler            quartz-jobs            2.2.1mysql            mysql-connector-java            5.1.35com.zaxxer            HikariCP            2.2.5复制代码

2 准备Demo代码

//创建一个简单的Job接口类public class HelloJob implements Job {    @Override    public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException {        System.out.println("hello quartz!");    }}// 1. 通过工厂的方式创建Scheduler// 2. JobDetail指定Job为HelloJob// 3. Trigger执行策略为每个10s重复执行一次调度作业public class SchedulerTest {    private static SchedulerFactory factory = new StdSchedulerFactory();    public static void main(String[] args) throws SchedulerException {        Scheduler scheduler = factory.getScheduler();        scheduler.start();        // JobDetail        JobDetail job = JobBuilder.newJob(HelloJob.class)            .withIdentity("myJob", "group")            .build();        // Trigger        Trigger trigger = TriggerBuilder.newTrigger()            .withIdentity("myTrigger", "group")            .startNow()            .withSchedule(simpleSchedule()                .withIntervalInSeconds(10)                .repeatForever())            .build();        // 调度        scheduler.scheduleJob(job,trigger);    }}复制代码

3 默认情况下JobDetail和Trigger是存储在内存中的，如果想要持久化到数据库中，可以新增quartz.properties，修改配置准备数据库脚本。

数据库脚本：数据表脚本：raw.githubusercontent.com/quartznet/q…
Quartz配置：

# quartz数据库的表前缀org.quartz.jobStore.tablePrefix = QRTZ_# 持久化使用的类，JobStoreTX支持事物的提交和回滚org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTXorg.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate# 数据源的标记，配置之后quartz会根据值作为前缀获取数据库的配置# 在StdSchedulerFactory类中搜索 String[] dsNames = cfg.getPropertyGroups(PROP_DATASOURCE_PREFIX); 查看这部分代码org.quartz.jobStore.dataSource = myDS# 配置数据库org.quartz.dataSource.myDS.driver = com.mysql.jdbc.Driverorg.quartz.dataSource.myDS.URL = jdbc:mysql://localhost:3306/quartz-test?characterEncoding=utf-8org.quartz.dataSource.myDS.user = rootorg.quartz.dataSource.myDS.password =org.quartz.dataSource.myDS.maxConnections = 5#org.quartz.dataSource.myDS.connectionProvider.class=org.quartz.utils.HikariCpPoolingConnectionProviderorg.quartz.dataSource.myDS.provider=hikaricp# 其余采用默认的quartz配置org.quartz.scheduler.instanceName: DefaultQuartzSchedulerorg.quartz.scheduler.rmi.export: falseorg.quartz.scheduler.rmi.proxy: falseorg.quartz.scheduler.wrapJobExecutionInUserTransaction: falseorg.quartz.threadPool.class: org.quartz.simpl.SimpleThreadPoolorg.quartz.threadPool.threadCount: 10org.quartz.threadPool.threadPriority: 5org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread: trueorg.quartz.jobStore.misfireThreshold: 60000复制代码

运行结果：

数据表解释：

原理设计

UML类图

两个主要线程：QuartzSchdulerThread与MisfireHandler 调度任务的核心执行逻辑在QuartzSchdulerThread中 MisfireHandler用于解决任务未触发问题。
JobStore对Job和Trigger的增删改查，JobRunShell将框架与我们自定义的业务Job进行关联起来处理

Quartz主要启动过程

通过时序图，了解Quartz大部分核心类的创建时机。

1 首先创建调度工厂类，一般使用StdSchedulerFactory，通过工厂类创建Scheduler。Scheduler的属性可通过quartz.properties配置

2 以Scheduler的标准实现StdScheduler为例，其为QuartzScheduler的代理类，主要行为通过QuartzScheduler来实现。

3 QuartzScheduler实例化的时候也是在StdSchedulerFactory中，它主要使用两个对象。

QuartzSchedulerResources 实例化与StdSchedulerFactory中，包含Scheduler创建和运行过程的主要资源，如JobStore和ThreadExecutor。
QuartzSchedulerThread 负责触发Trigger，通过SchedulerSignaler进行交互

Quartz任务调度过程

我们创建的任务是怎么被调度的？主要在调度线程QuartzSchedulerThread中实现，其大致逻辑

1 先获取线程池中可以使用的线程数量，如果没有可以用的线程会阻塞到有可用的线程。配置：org.quartz.threadPool.xxx

2 通过JobStore获取接下来30秒钟内要执行的trigger。org.quartz.spi.JobStore#acquireNextTriggers

3 循环与waiting到任务配置的触发时间

4 进行触发，通过JobStore.triggerFired获取TriggerFiredResult

5 针对每个要执行的TriggerFiredResult，创建JobRunShell，并放入线程池执行

JobRunShell调用初始化方法，创建本次要执行Job和JobExecutionContext。 Job = JobDetail.getJobClass().newInstance()， JobExecutionContext包含了本次Job运行的JobDetail和Trigger等信息。
将JobRunnerShell丢到线程池中，从线程池中选一个可用的WorkerThread运行。
运行JobRunnerShell的run方法。job.execute(jec); 执行Job实例代码，执行前后可以通过listner做一些监听。

Quartz任务Misfire过程

Quartz调度器正常情况下获取将来一段时间内要触发的任务，然后循环等待到指定时刻进行执行，但是可能在指定的时间点未执行到配置的任务。出现这种情况的原因：

系统重启，重启的这段时间中，一些任务被misfire
trigger被暂停(suspendXXX)的一段时间中，一些任务被misfire
线程池资源不足，任务无法被执行
有些任务在触发时间时，上次正在执行的任务目前还没有结束。

那么Misfire机制的处理原理是什么呢？

假设在0时刻有一个任务需要执行，但是到了当前时刻即图中的80，任务还没有被执行，如果当前时刻与0时刻要执行的任务大于misfireThreshold，那么0时刻的任务被看做是misfire任务。
然后0时刻的任务会被MisfireHandler检测到，再将其next_trigger_time设置为90(设置为当前时刻之后)。
由于任务的next_trigger_time设置为了当前时刻之后，调度线程会重新检测到这个任务，然后进行触发。

内部run方法的执行流程：

1 扫描在misfireThreshold到此刻时间范围内没有被执行的Trigger。首先进行计数：countMisfiredTriggersInState(conn, STATE_WAITING, getMisfireTime())

2 如果count大于0的话，获取锁，防止并发访问。然后获取需要被触发的Misfire trigger。

3 根据配置的misfireInstruction更新trigger的next_fire_time。主要方法位于：SimpleTriggerImpl#updateAfterMisfire

4 提交connection

5 如果还有更多的misfire任务，休息最短暂的50ms。如果没有则sleep时间为misfireThreshold

Trigger状态

在网上看到一个有关Trigger状态流转的图，参考下：

一些问题

预估在使用Quartz中可能会存在的问题：

1 数据表结构固定，必须要按照官方给的表结构来吗？

可以自己实现JobStore，参考JobStoreSupport类，自定义表结构

2 Quartz默认使用数据库作为分布式锁，性能太差，如何优化？

自定义LockHandler类，使用Redis实现分布式锁
使用Trigger批处理方式
改变任务执行的顺序
减少上下文的切换

参考：tech.ebayinc.com/engineering…

最后

本人才疏学浅，过程如有不当，希望大佬能指出错误，如有想关于其设计原理讨论的，也欢迎来撩。

会持续更新...