框架设计

整体设计

功能说明

1>有一个集中管理的定时任务中心，所有的定时任务信息都在这里创建、保存并被运行，但是没有具体的业务，所有的业务都在具体的项目中，这样它的资源是非常省的。

2>当定时任务到了运行的时间，它的职责就是连接消息中心，通过消息中心向外发布一个的消息，可以带上运行的任务信息等参数，至于谁来消费这个消息执行业务它就不关心了。

3>当项目有定时任务的需求时，只需关注它本身的业务逻辑而不必去写定时任务的代码，只需要向消息中心订阅相应的消息，在接收到消息后执行业务代码即可。

4>这样定时任务和具体的项目基本就解耦了，当有新项目加入进来时只需要订阅一个消息就能实现定时任务。

5>在集群环境下，可以根据需要(一台或多台执行)设置消息的消费模式，像metaQ就支持集群中的某一台消费消息，当然，稳妥起见前面说的幂等性还是必不可少的。这里用redis来实现分布式锁。

实现细节

Quartz集群部署

Quartz集群中的每个节点是一个独立的Quartz应用，它又管理着其他的节点。该集群需要分别对每个节点分别启动或停止，不像应用服务器的集群，独 立的Quartz节点并不与另一个节点或是管理节点通信。Quartz应用是通过数据库表来感知到另一应用。只有使用持久的JobStore才能完成 Quartz集群。

org.quartz.impl.jdbcjobstore.JobStoreTX

将任务持久化到数据中。因为集群中节点依赖于数据库来传播Scheduler实例的状态，你只能在使用JDBC JobStore时应用Quartz集群。

org.quartz.jobStore.isClustered

true

通知Scheduler实例要它参与到一个集群当中。

org.quartz.jobStore.clusterCheckinInterval

15000

属性定义了Scheduler实例检入到数据库中的频率(单位：毫秒)。Scheduler检查是否其他的实例到了它们应当检入的时候未检入；这能指出一个失败的Scheduler实例，且当前 Scheduler会以此来接管任何执行失败并可恢复的Job。通过检入操作，Scheduler 也会更新自身的状态记录。clusterChedkinInterval越小，Scheduler节点检查失败的Scheduler实例就越频繁。默认值是 15000 (即15 秒)。

Quartz监控

trigger各状态说明：

1>None：Trigger已经完成，且不会在执行，或者找不到该触发器，或者Trigger已经被删除

2>NORMAL:正常状态

3>PAUSED：暂停状态

4>COMPLETE：触发器完成，但是任务可能还正在执行中

5>BLOCKED：线程阻塞状态

6>ERROR：出现错误

Quartz集群数据库表

Quartz 核心元素关系图

Redis设置分布式锁

遗留问题

1>监控中心对接

2>调度中心日志备份

3>Redis集群连接池扩展

4>MySQL恢复wait_timeout为默认值（set global wait_timeout=28800）处理数据源超时链接断开问题。

5>集群环境（quartz集群，web应用集群）并发测试