精通Quartz-03-Quartz数据库表分析

Quartz的集群部署方案在架构上是分布式的,没有负责集中管理的节点,各节点间不会直接通讯而是利用数据库锁的方式来实现集群环境下进行并发控制,因此Quartz集群化部署时必需要启用持久化配置。

分布式部署时须要保证各个节点的系统时间一致。mysql

Quartz默认提供了11张表,若是下载了quartz的源码,相应的sql文件所在目录为quartz/quartz-core/src/main/resources/org/quartz/impl/jdbcjobstoresql


本文使用的是tables_mysql_innodb.sql文件,它显示指定了使用innodb存储引擎,另外一个tables_mysql.sql文件没有指定具体的存储引擎;本方将对这些张表作简单介绍数据库


前面6张都是关于各类triggers的信息,后面包括job,日程表,调度节点状态,悲观锁等信息;相关表操做在类StdJDBCDelegate中,相关sql语句在StdJDBCConstants中;
架构

1.qrtz_blob_triggers  并发

用户自定义的Trigger使用Blob类型进行trigger详细信息的存储(这样设计,JobStore更容易通用),非自定义的Trigger不会存放在此表中;分布式

Quartz提供的triggers包括:CronTrigger,CalendarIntervalTrigger, DailyTimeIntervalTrigger以及SimpleTrigger,这几个trigger信息会保存在后面的几张表中; spa

 2.qrtz_cron_triggers 设计

存储CronTrigger的详细信息,这也是咱们使用最多的触发器, 包括cron表达式,时区信息等; Spring对应的封装CronTriggerFactoryBean
cdn

3.qrtz_simple_triggersblog

存储SimpleTrigger的详细信息,  包括重复次数,重复间隔时间和已经执行的次数等

Spring对应的封装SimpleTriggerFactoryBean

4.qrtz_simprop_triggers

存储CalendarIntervalTrigger和DailyTimeIntervalTrigger两种类型的触发器

Spring没有对应的封装类,可能由于这两种不经常使用,且基本上能够用CronTrigger来实现

5.qrtz_triggers

存储全部Trigger(包括自带的4种Trigger和用户自定义Trigger)的通用动态信息;随着调度的触发preFireTime,nextFireTime, triggerState等都会相应的跟着变化

6.qrtz_fired_triggers

存储即将触发或正在触发的trigger相关信息,trigger随着时间的推移状态发生变化,直到最后trigger执行完成,从表中被删除

7.qrtz_job_details

存储jobDetails信息,相关信息在定义的时候指定,后续不会发生变化

8.qrtz_calendars

 Quartz为咱们提供了日历的功能,能够本身定义多个时间段,能够控制触发器在这个时间段内不触发或者触发;实际使用中通常是用于定义多个不触发的时间段,用于排除特殊日期,节假日等

系统提供6种类型:AnnualCalendar,CronCalendar,DailyCalendar,HolidayCalendar,MonthlyCalendar,WeeklyCalendar

9.qrtz_paused_trigger_grps

存储已暂停的Trigger组的信息,批量暂停Trigger时用到,不经常使用。

10.qrtz_scheduler_state

开启集群功能时,存储Scheduler实例名称,检查周期,各节点最后活跃时间等信息;Quartz集群下的故障转移就是借助这个表来实现的

11.qrtz_locks

Quartz提供的锁表,为多个节点调度提供分布式锁,实现分布式调度,默认有2个锁:STATE_ACCESS 主要用在scheduler按期检查是否有失效节点的时候,保证只有一个节点去检查和处理;

TRIGGER_ACCESS 主要用在Trigger触发和触发完成的时候,保证只有一个节点去执行相应的逻辑, 固然也能够经过配置让Trigger在获取任务时也加锁