一、前言：
虽然单个Quartz实例能给予我们很好的任务job调度能力，但它不能满足典型的企业需求，如可伸缩性、高可靠性满足。假如你需要故障转移的能力并能运行日益增多的 Job，Quartz集群势必成为你应用的一部分了。使用 Quartz 的集群能力可以更好的支持你的业务需求，并且即使是其中一台机器在最糟的时间挂掉了也能确保所有的 Job 得到执行。
二、Quartz集群框架效果图：
一个 Quartz 集群中的每个节点是一个独立的 Quartz 应用，它又管理着其他的节点。也就是你必须对每个节点分别启动或停止。不像许多应用服务器的集群，独立的Quartz 节点并不与另一其的节点或是管理节点通信。Quartz 应用是通过数据库表来感知到另一应用的。
spring中quartz.properties配置quartz集群功能：
三、Quartz集群的好处优势：
1、Quartz能完成较为复杂的定时任务
2、 Quartz的集群功能保证了任务可靠、高效的正常执行，当集群中其中的一个节点出问题时，另外的节点接手任务，继续工作。确保所有的job的到执行。
3、 Quartz功能强大但配置较为简单
4、 无环境依赖性，Java的普通应用均能使用
四、Quartz集群的缺点：
Quartz一点都不明确你是在同一台机器上运行所有节点，还是在不同的机器上运行所有节点。当集群是放置在不同的机器上时，我们称之为水平集群。如果所有节点是跑在同一台机器的时候，我们称之为垂直集群。对于垂直集群，存在着单点故障的问题。这对高可用性的应用来说是个坏消息，因为一旦机器宕掉了，所有的节点也就被有效的终止了。而当你运行水平集群时，一个严格的要求就是我们的时钟时间必须要同步，以免出现离奇且不可预知的行为。假如时钟没能够同步，Scheduler 实例将对其他节点的状态产生混乱，造成难以估计得麻烦。
怎么解决这个问题呢？
俗话说，不能把所有的鸡蛋放在一个篮子里。在能满足业务或者性能要求的条件下，尽量使用水平集群。我们有很多方法可以来保证时间的同步。其中最简单额就是把时间抽出来，单独使用一个internet时间服务器(Internet Time Server ITS)来做标准时间，所有的节点都已这上面的时间为准，时间就统一了。
Trigger配置文件更改时当数据库qrtz_cron_triggers中cron_expression未更改，则触发器的运行触发规则未改变。
所以quartz集群缺陷总结以下几点：
1、时间规则更改不方便，需同步更改数据库时间规则描述
2、Quartz集群当所有节点跑在同一台服务器上，当服务器崩溃时所有节点将终止，定时任务将不能正常执行
3、Quartz集群当节点不在同一台服务器上时，因时钟的可能不同步导致节点对其他节点状态的产生影响。
而我们的解决方案，参考本博客内容选用。慎用！
