浅谈分布式定时任务之quartz

前言

最近一段时间因公司项目须要进行分布式定时任务框架选型，因为资源（人力，时间）有限，因此重点考虑采用开源的一些解决方案，其中重点比较了3款框架：quartz，elastic-job，xxl-job等。因为elastic-job 和xxl-job 实际上也是基于quartz实现的。因此颇有必要对quartz 有必定的了解。因此近期阅读了大量quartz相关的一些文档和博客，以及写了一些demo进行验证。本文主要是对近期工做的一个小结，简要的介绍一下quartz 这个分布式定时任务调度框架。

目录

• 什么是quartz?它有哪些特性?
• quartz 核心概念和元素介绍
• quartz 经常使用配置项介绍
• quartz 集群介绍

一.什么是quartz?它有哪些特性?

quartz 是一个开源的分布式调度库，它基于java实现。
> 它有着强大的调度功能，支持丰富多样的调度方式,好比简单调度，基于cron表达式的调度等等。
> 支持调度任务的多种持久化方式。好比支持内存存储，数据库存储，Terracotta server 存储。
> 支持分布式和集群能力。
> 采用JDBCJobStore方式存储时，针对事务的处理方式支持全局事务（和业务服务共享同一个事务）和局部事务（quarzt 单独管理本身的事务）
> 基于plugin机制以及listener机制支持灵活的扩展。
复制代码

二. quartz 核心概念和元素介绍:

• Job： 工做任务。它提供了一个接口，只有一个方法void execute(JobExecutionContext context)，开发者实现该接口定义运行任务，JobExecutionContext类提供了调度上下文的各类信息。Job运行时的信息保存在JobDataMap实例中.

• JobDetail：工做任务实例.Quartz在每次执行Job时，都从新建立一个Job实例，因此它不直接接受一个Job的实例，相反它接收一个Job实现类，以便运行时经过newInstance()的反射机制实例化Job。所以须要经过一个类来描述Job的实现类及其它相关的静态信息，如Job名字、描述、关联监听器等信息，JobDetail承担了这一角色.

• Trigger：触发器,用来描述触发Job执行的时间触发规则。主要有SimpleTrigger和CronTrigger这两个子类。当仅需触发一次或者以固定时间间隔周期执行，SimpleTrigger是最适合的选择；而CronTrigger则能够经过Cron表达式定义出各类复杂时间规则的调度方案：如每早晨9:00执行，周1、周3、周五下午5:00执行等.

• Calendar:日历，它表示一些特定时间点的集合.一个Trigger能够和多个Calendar关联，以便排除或包含某些时间点。假设，咱们安排每周星期一早上10:00执行任务，可是若是碰到法定的节日，任务则不执行，这时就须要在Trigger触发机制的基础上使用Calendar进行定点排除。

• Scheduler：调度器,表明一个Quartz的独立运行容器，Trigger和JobDetail能够注册到Scheduler中，二者在Scheduler中拥有各自的组及名称，组及名称是Scheduler查找定位容器中某一对象的依据，Trigger的组及名称必须惟一，JobDetail的组和名称也必须惟一（但能够和Trigger的组和名称相同，由于它们是不一样类型的）。Scheduler定义了多个接口方法，容许外部经过组及名称访问和控制容器中Trigger和JobDetail。

  Scheduler能够将Trigger绑定到某一JobDetail中，这样当Trigger触发时，对应的Job就被执行。一个Job能够对应多个Trigger，但一个Trigger只能对应一个Job。
  复制代码

三. quarz 经常使用配置项介绍

quartz 默认的配置文件是quartz.properties ,里面有不少配置项,好比调度器(schedule)相关配置,事务的配置，监听器，插件的配置，rmi 相关配置，集群相关配置等等。 详细配置信息能够参照官方文档:www.quartz-scheduler.org/documentati…

四. quratz 集群介绍

quartz 集群是依赖于数据库机制实现的。部署多个节点的quartz 数据库配置必须保持一致。quartz集群是经过数据库表来感知其余的应用的，各个节点之间并无直接的通讯。只有使用持久的JobStore才能实现Quartz集群。

quartz 默认提供了11张数据库表:

• QRTZ_CALENDARS: 存储Quartz的Calendar信息

• QRTZ_CRON_TRIGGERS:存储CronTrigger，包括Cron表达式和时区信息

• QRTZ_FIRED_TRIGGERS:存储与已触发的Trigger相关的状态信息，以及相联Job的执行信息

• QRTZ_PAUSED_TRIGGER_GRPS:存储已暂停的Trigger组的信息

• QRTZ_SCHEDULER_STATE：存储少许的有关Scheduler的状态信息，和别的Scheduler实例

• QRTZ_LOCKS：存储程序的悲观锁的信息

• QRTZ_JOB_DETAILS:存储每个已配置的Job的详细信息

• QRTZ_SIMPLE_TRIGGERS：存储简单的Trigger，包括重复次数、间隔、以及已触的次数

• QRTZ_BLOG_TRIGGERS Trigger做为Blob类型存储

• QRTZ_TRIGGERS 存储已配置的Trigger的信息

• QRTZ_SIMPROP_TRIGGERS:存储简单触发器相关。

  要注意的是quartz集群间的相互感知是经过数据库表（QRTZ_SCHEDULER_STATE）实现的。对于水平集群，存在着时间同步问题。节点用时间戳来通知其余实例它本身的最后检入时间。假如节点的时钟被设置为未来的时间，那么运行中的Scheduler将再也意识不到那个结点已经宕掉了。另外一方面，若是某个节点的时钟被设置为过去的时间，也许另外一节点就会认定那个节点已宕掉并试图接过它的Job重运行。
  复制代码

小结

本文只是对quartz 分布式定时任务作了一个简单的介绍。quartz 做为一个成熟的分布式定时任务框架，然而好像并无提供友好的运维管理界面，幸运的是不少的开源框架弥补了这个不足，好比elastic-job ，xxl-job等等，关于quartz 的更多内容，在后面不断的实践中再补充。