Quartz框架(一)—Quartz的基本配置
Quartz框架(二)—jobstore数据库表字段详解
Quartz框架(三)—任务的并行/串行执行
Quartz框架(四)—misfire处理机制
Quartz框架(五)— 有状态的job和无状态job
Quartz框架(六)— Trigger状态转换
Quartz框架(七)— Quartz集群原理
Quartz框架(八)— Quartz实现异步通知
Quartz框架(九)— 动态操作Quartz定时任务
Quartz框架(十)监听
Quartz是启动定时任务的框架。
1. Quartz的核心元素
Quartz调度依靠的三大核心元素就是:Scheduler、Trigger、Job。
1. Job(任务)
作用:具体要执行的业务逻辑,比如:发送短信、发送邮件、访问数据库、同步数据等。
2. Trigger(触发器)
作用:用来定义Job(任务)触发条件、触发时间,触发间隔,终止时间等。
四大类型:SimpleTrigger、CornTrigger、DateIntervalTrigger、NthIncludedDayTrigger。
3. scheduler(调度器)
作用:Scheduler启动Trigger去执行Job。
类型:Scheduler由scheduler工厂创建:DirectSchedulerFactory 或者 StdSchedulerFactory。
第二种工厂StdSchedulerFactory使用较多,因为 DirectSchedulerFactory 使用起来不够方便,需要作许多详细的手工编码设置。
Scheduler 主要有三种:RemoteMBeanScheduler, RemoteScheduler 和 StdScheduler。
2. Quartz的准备工作
2.1. maven依赖
org.quartz-scheduler
quartz
2.2.1
org.quartz-scheduler
quartz-jobs
2.2.1
>>>>SpringBoot替换为:>>>>
org.springframework.boot
spring-boot-starter-quartz
2.2. Quartz的配置文件
在Quartz JAR文件的org.quartz包下就包含一个quartz.properties属性配置文件并提供了默认属性。如果需要调整默认配置,可以在类路径下建立一个新的quartz.properties,它将自动被Quartz加载并覆盖默认的设置。
2.2.1 文件的加载位置
需要注意的是:配置文件一般为quartz.properties文件,但是如果使用yml文件格式的配置,则quartz.properties里面的配置会失效;
【配置文件】默认:优先顺序Classpath:quartz.properties-->org/quartz/quartz.properties
【程序内指定】在StdSchedulerFactory.getScheduler()之前使用StdSchedulerFactory.initialize(xx)
2.2.2Quartz的配置信息
注:QuartzProperties
类读取的就是我们yml文件中的配置。
1. 基础配置
scheduler的配置信息
#可以为任意字符串,对于scheduler来说此值没有意义,但是可以区分同一系统中多个不同的实例,
#如果使用了集群的功能,就必须对每一个实例使用相同的名称,这样使这些实例“逻辑上”是同一个scheduler。
org.quartz.scheduler.instanceName = JobScheduler
#可以是任意字符串,但如果是集群,scheduler实例的值必须唯一,可以使用AUTO自动生成。
org.quartz.scheduler.instanceId = AUTO
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
# 默认false,若是在执行Job之前Quartz开启UserTransaction,此属性应该为true。
#Job执行完毕,JobDataMap更新完(如果是StatefulJob)事务就会提交。默认值是false,可以在job类上使用@ExecuteInJTATransaction 注解,以便在各自的job上决定是否开启JTA事务。
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false
#一个scheduler节点允许接收的trigger的最大数,默认是1,这个值越大,定时任务执行的越多,但代价是集群节点之间的不均衡。
org.quartz.scheduler.batchTriggerAcquisitionMaxCount=1
2. 调度器线程池配置
#线程池的实例类,(一般使用SimpleThreadPool即可满足几乎所有用户的需求)
org.quartz.threadPool.class= org.quartz.simpl.SimpleThreadPool
#线程数量,不会动态增加
org.quartz.threadPool.threadCount= 10
#线程优先级
org.quartz.threadPool.threadPriority= 5
#加载任务代码的ClassLoader是否从外部继承
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread= true
#是否设置调度器线程为守护线程
org.quartz.scheduler.makeSchedulerThreadDaemon: true
3. Configure JobStore 作业存储配置
3.1. RAMJobStore
将schedule相关信息保存在RAM中,轻量级,速度快,遗憾的是应用重启时相关信息都将丢失。
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
#最大能忍受的触发超时时间,如果超时则认为“失误”
org.quartz.jobStore.misfireThreshold = 60000
3.2. JDBC-JobStore
将schedule相关信息保存在RDB中,有两种实现:JobStoreTX和JobStoreCMT
前者为application自己管理事务;
后者为application server管理事务,即全局JTA;
JDBCJobStore终于把数据持久化起来了,这个也是使用最广泛的数据存储方式。在于Spring集成后都不需要自己配置一遍数据库连接了。
配置方式以及默认值:
#选择JDBC的存储方式
org.quartz.jobStore.class= org.quartz.impl.jdbcjobstore.JobStoreTX
#类似于Hibernate的dialect,用于处理DB之间的差异,StdJDBCDelegate能满足大部分的DB(授权)
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
#存储相关信息表的前缀
org.quartz.jobStore.tablePrefix = QRTZ_
#这个值必须datasource的配置信息
org.quartz.jobStore.dataSource = myDS
#JobDataMaps是否都为String类型
#(若是true的话,便可不用让更复杂的对象以序列化的形式保存到BLOB列中。以防序列化可能导致的版本号问题)
org.quartz.jobStore.useProperties = false
#最大能忍受的触发超时时间,如果超时则认为“失误”
org.quartz.jobStore.misfireThreshold = 60000
#是否是应用在集群中,当应用在集群中时必须设置为TRUE,否则会出错。
#如果有多个Quartz实例在用同一套数据库时,必须设置为true。
org.quartz.jobStore.isClustered=False
#只用于设置了isClustered为true的时候,设置一个频度(毫秒),用于实例报告给集群中的其他实例。
#这会影响到侦测失败实例的敏捷度。
org.quartz.jobStore.clusterCheckinInterval =15000
#这是JobStore能处理的错过触发的Trigger的最大数量。处理太多(2打)很快就会导致数据库表被锁定够长的时间,
#这样会妨碍别的(还未错过触发)trigger执行的性能。
org.quartz.jobStore.maxMisfiresToHandleAtATime=20
#设置这个参数为true会告诉Quartz从数据源获取连接后不要调用它的setAutoCommit(false)方法。
#在少数情况下是有用的,比如有一个驱动本来是关闭的,但是又调用这个关闭的方法。但是大部分情况下驱动都要求调用setAutoCommit(false)
org.quartz.jobStore.dontSetAutoCommitFalse=false
#这必须是一个从LOCKS表查询一行并对这行记录加锁的SQL。假设没有设置,默认值如下。
#{0}会在运行期间被前面配置的TABLE_PREFIX所代替
org.quartz.jobStore.selectWithLockSQL=SELECT * FROM {0}LOCKS WHERE LOCK_NAME = ? FOR UPDATE
#值为true时告知Quartz(当使用JobStoreTX或CMT)调用JDBC连接的setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE) 方法。这有助于某些数据库在高负载和长时间事务时锁的超时。
org.quartz.jobStore.txIsolationLevelSerializable=false
4. 数据库配置
datasource的相关信息全部定义与quartz.properties中,quartz自己创建datasource。
org.quartz.dataSource.NAME.driver
org.quartz.dataSource.NAME.URL
org.quartz.dataSource.NAME.user
org.quartz.dataSource.NAME.password
org.quartz.dataSource.NAME.maxConnections
需要注意的是,#NAME字段必须与[email protected]保持一致
但是一般我们的数据库连接池一般使用第三方连接池,那么就会导致org.quartz.jobStore.dataSource=#NAME无法配置!!可以使用quartz.job-store-type=jdbc替代。
2.2.3 SpringBoot2.x整合Quartz的配置文件
自动加载的源码:org.springframework.boot.autoconfigure.quartz.QuartzAutoConfiguration
spring:
datasource:
name: mysql_test
type: com.alibaba.druid.pool.DruidDataSource
#druid相关配置
druid:
#监控统计拦截的filters
filter: stat,config
# driver-class-name: com.mysql.cj.jdbc.Driver
#基本属性
url: jdbc:mysql://localhost:3306/mydb
username: root
password: 123456
#初始化连接数
initial-size: 10
#最小活跃连接数
min-size: 5
#最大活跃连接数
max-active: 20
#获取连接的等待时间
max-wait: 60000
#间隔多久进行一次检查,检查需要关闭的空闲连接
time-between-eviction-runs-millis: 60000
#一个连接在池中最小的生存时间(5分钟)
min-evictable-idle-time-millis: 300000
validation-query: SELECT 'X'
# 验证空闲的连接,若无法验证,则删除连接
test-while-idle: true
# 不检测池中连接的可用性(默认false)
# 导致的问题是,若项目作为服务端,数据库连接被关闭时,客户端调用就会出现大量的timeout
test-on-borrow: false
#在返回连接池之前是否验证对象
test-on-return: false
#打开PSCache,并指定每个连接上PSCache的大小。oracle设为true,mysql设为false。分库分表较多推荐设置为false
#第三发连接池在使用的时候,获取到Connection后,使用完毕,调用关闭方法,并没有将Connection关闭,只是放回到连接池中
#如果调用这个方法,而没有手动关闭PreparedStatement,就可能造成内存溢出,但是JDK1.7实现了AutoCloseable接口,就不需要关闭了
pool-prepared-statements: false
max-pool-prepared-statement-per-connection-size: 20
# connection-properties:
use-unfair-lock: true
quartz:
#相关属性配置
properties:
org:
quartz:
scheduler:
# 集群名,区分同一系统的不同实例,若使用集群功能,则每一个实例都要使用相同的名字
instanceName: clusteredScheduler
# 若是集群下,每个instanceId必须唯一
instanceId: AUTO
threadPool:
#一般使用这个便可
class: org.quartz.simpl.SimpleThreadPool
#线程数量,不会动态增加
threadCount: 10
threadPriority: 5
threadsInheritContextClassLoaderOfInitializingThread: true
jobStore:
#选择JDBC的存储方式
class: org.quartz.impl.jdbcjobstore.JobStoreTX
driverDelegateClass: org.quartz.impl.jdbcjobstore.StdJDBCDelegate
tablePrefix: QRTZ_
useProperties: false
isClustered: true
clusterCheckinInterval: 15000
job-store-type: jdbc
#是否等待任务执行完毕后,容器才会关闭
wait-for-jobs-to-complete-on-shutdown=false
#配置的job是否覆盖已经存在的JOB信息
overwrite-existing-jobs: false
1. 讲一下最后两个配置
wait-for-jobs-to-complete-on-shutdown:Quartz默认false,是否等待任务运行完毕后关闭Spring容器,若是为false的情况下,可能出现
java.lang.IllegalStateException: JobStore is shutdown - aborting retry
异常,推荐开启。overwrite-existing-jobs:这个是配置文件的job是否会覆盖数据库正在运行的job。quartz启动之后,会以数据库的为准,若该属性为false,则配置文件修改后不会起作用。
2. 线程池配置不生效问题及原因
配置线程池参数,无论怎样都不生效。经过debug得知。源码:org.quartz.impl.StdSchedulerFactory#instantiate()
,由于线程池的参数有误,导致配置的是默认值。
相关参考:
spring整合quartz并持久化
在spring quartz中,造成 misfired job 的原因有哪些
Quartz-job的quartz.properties配置文件说明
(精)Quartzs -- Quartz.properties 配置
(译)quartz_properties文件配置之主要配置