为什么要用分布式集群任务调度？

作为一个开发者，避免不了定时任务的问题，最粗暴和简单直接的解决方案就是crontab。当然在机器少，任务不多，定时任务之间关联少的情况下，crontab效率还是比较高和便捷的。但当机器越多、定时任务越多，各个任务联系越紧密的情况下，用crontab进行定时任务的管理配置，就会非常混乱，严重影响工作效率。

机器多、定时任务多的情况下，就会遇到以下问题：
1、每个服务器各个用户下的crontab任务管理混乱，生命周期无法统一协调管理
2、定时任务运行异常告警难以统一对接
3、任务A和任务B如果存在互斥关系，crontab很难进行互斥处理
4、随着时间增长，当定时任务达到几千上万的时候，定时任务就非常难以管理，线上跑了多个定时任务，每个定时任务什么时候运行，属于哪个应用和哪个开发负责等等问题变得很难解决。

Linux原生Crontab调度系统和Quartz对比：
1、执行粒度方面：
Crontab：进程调度
Quartz：线程调度
线程调度优势：一是更节省资源，二是可以在进程内做数据交换，做数据交换这点很重要。

2、平台依赖性：
Crontab支持Linux系统
Quartz由于是Java实现，所以支持跨平台。

3、调度操作集上：
Quartz的设置更为灵活，可以很方便的通过代码完成各种自定义需求，而且完全闭包Crontab。
但是Crontab的最小调度单元为分钟级，而Quartz可以更细，Crontab实现自定义需求比较麻烦。

4、Job监控方面：
Quartz支持Listener，对job运行情况监控很方便，并且能用JobStores进行调度信息的持久化（内存、DB均可），进而可以实现job可视化。

5、高可用：
Quartz支持分布式集群，这一点很重要，而且实现很方便。

为什么要用分布式集群任务调度？
想象一下，现在有 A 、B、 C 3 台机器同时作为集群服务器对外统一提供 SERVICE，3 台机器上各有一个 QUARTZ Job，它们会按照即定的 SCHEDULE 自动执行各自的任务。由于三台SERVER 里都有 QUARTZ ，因此会存在重复处理 TASK 的现象。一般的解决方案是只在一台服务器上装 QUARTZ ，其它两台不装，这样的话其实就是单机了，quartz会存在单点问题，一旦装有quartz的服务器宕了，服务就无法提供了。当然通过改 QUARTZ JOB 的代码也可以实现，但是这对开发人员要求比较高，而且可能会出现其他问题。然而quartz本身就提供了很好的集群方案。quartz集群需要数据库的支持（JobStore TX或者JobStoreCMT），从本质上来说，是使集群上的每一个节点通过共享同一个数据库来工作而达到高可用的。分布式集群任务调度，quartz是一个比较好的选择。简单，强大，稳定。

分布式集群时有个问题，就是所有服务器时钟应当要同步，以免出现离奇且不可预知的问题。

参考：基于spring+quartz的分布式任务调度