定时任务框架，基于数据库的高可用方案。
概念了解
Job
表示一个工作，要执行的具体内容。此接口中只有一个方法
void execute(JobExecutionContext context)
JobDetail
JobDetail表示一个具体的可执行的调度程序，Job是这个可执行程调度程序所要执行的内容，另外JobDetail还包含了这个任务调度的方案和策略。
Trigger代表一个调度参数的配置，什么时候去调。
Scheduler代表一个调度容器，一个调度容器中可以注册多个JobDetail和Trigger。当Trigger与JobDetail组合，就可以被Scheduler容器调度了。
比如项目多机部署，同一个定时任务，在不允许重复执行的场景，使用Quartz实现，而Quartz基于数据库的锁实现。
在quartz的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁已经被占用了，就只能等待，直到这个锁被释放。之后会看trigger状态，如果已经被执行了，则不会执行了。
缺点：
但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。
关于Quartz在实际项目中的使用，可以关注若依官网，下载若依基本框架，了解定时任务的实现，本人也是在学习若依框架的过程中，使用到定时任务，
基本流程是：
1 首先页面支持定时任务的创建和执行和失效等，
2 后台ScheduleUtils基于是否并发调用不同的类，但其实，点下去对比可以看到，实际上QuartzJobExecution.class 和 QuartzDisallowConcurrentExecution.class 调用的是同一个方法method.invoke(bean)，内部参数处理也并不涉及Job的concurrent属性，为什么这么写还没理解，
3 最后是基于数据库，创建数据库的定时任务的数据，通过java后台读取定时任务执行的类和方法.
经常阅读代码，学习别人的设计思路。
学习是最公平的事！