虽然单个Quartz实例能给予我们很好的任务job调度能力，但它不能满足典型的企业需求，如可伸缩性、高可靠性满足。假如你需要故障转移的能力并能运行日益增多的 Job，Quartz集群势必成为你应用的一部分了。使用 Quartz 的集群能力可以更好的支持你的业务需求，并且即使是其中一台机器在最糟的时间挂掉了也能确保所有的 Job 得到执行。一个 Quartz 集群中的每个节点是一个独立的 Quartz 应用，它又管理着其他的节点。也就是你必须对每个节点分别启动或停止。不像许多应用服务器的集群，独立的Quartz 节点并不与另一其的节点或是管理节点通信。Quartz 应用是通过数据库表来感知到另一应用的。
Quartz集群配置很简单，本篇配置基于我的上一篇文章https://www.cnblogs.com/hhhshct/p/9707710.html，只需要更改下quartz.properties即可，如下：
org.quartz.scheduler.instanceName = schedulerFactoryBean #调度器编号自动生成，集群中编号不可以重复，所以最好设成auto org.quartz.scheduler.instanceId = AUTO org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate org.quartz.jobStore.tablePrefix = QRTZ_ #开启分布式部署 org.quartz.jobStore.isClustered = true #分布式节点有效性检查时间间隔，单位：毫秒 org.quartz.jobStore.clusterCheckinInterval = 10000 org.quartz.jobStore.useProperties = false org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool org.quartz.threadPool.threadCount = 10 org.quartz.threadPool.threadPriority = 5 #配置是否启动自动加载数据库内的定时任务，默认true org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true
启动项目，端口号8081，作为第一个实例，可以看到之前我们加入的定时任务开始执行，修改端口号为8082，再启动项目，作为第二个实例，可以看到没有定时任务执行，然后我们手动down掉第一个实例，可以发现定时任务漂移到了我们的第二个实例，这样就避免了单点故障而造成定时任务不执行的问题。
Quartz一点都不明确你是在同一台机器上运行所有节点，还是在不同的机器上运行所有节点。当集群是放置在不同的机器上时，我们称之为水平集群。如果所有节点是跑在同一台机器的时候，我们称之为垂直集群。对于垂直集群，存在着单点故障的问题。这对高可用性的应用来说是个坏消息，因为一旦机器宕掉了，所有的节点也就被有效的终止了。而当你运行水平集群时，一个严格的要求就是我们的时钟时间必须要同步，以免出现离奇且不可预知的行为。假如时钟没能够同步，Scheduler 实例将对其他节点的状态产生混乱，造成难以估计得麻烦。至于如何解决这个问题，后续遇到再做研究了。