1. 目标

把定时任务通过集群的方式进行管理调度，并采用分布式部署，保证系统的高可用，提高了容错。那么如何保证定时任务只在集群的某一个节点上执行，或者一个任务如何拆分为多个独立的任务项，由分布式的机器去分别执行， 众多的定时任务如何统一管理，现在有很多成熟的分布式定时任务框架，都能很好的实现上述的功能。

2. 调度框架

2.1 Quartz

介绍

Quartz集群中每个节点都是一个单独的Quartz应用，它又管理着其他的节点。这个集群需要每个节点单独的启动或停止；和我们的应用服务器集群不同，独立的Quratz节点之间是不需要 通信的。不同节点之间是通过数据库表来感知另一个应用。只有使用持久的JobStore才能完成Quartz集群。

image.png

Job

表示一个工作，要执行的具体内容。此接口中只有一个方法

void execute(JobExecutionContext context)

JobDetail

JobDetail表示一个具体的可执行的调度程序，Job是这个可执行程调度程序所要执行的内容，另外JobDetail还包含了这个任务调度的方案和策略。

Trigger代表一个调度参数的配置，什么时候去调。

Scheduler代表一个调度容器，一个调度容器中可以注册多个JobDetail和Trigger。当Trigger与JobDetail组合，就可以被Scheduler容器调度了。

image.png

上图三个节点在数据库中都拥有同一份Job定义，如果某一个节点失效，那么Job会在其他节点上执行。由于三个节点上的Job执行代码是一样的，那么怎么保证只有在一台机器上触发呢？答案是使用了数据库锁。在quartz的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁已经被占用了，就只能等待，直到这个锁被释放。之后会看trigger状态，如果已经被执行了，则不会执行了。

缺点

但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。这种情况随着节点的增加会越来越严重。quartz的分布式只是解决了高可用的问题，并没有解决任务分片的问题，还是会有单机处理的极限。

2.2 elastic-job

介绍

elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 ， 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。

elastic-job主要的设计理念是无中心化的分布式定时调度框架，思路来源于Quartz的基于数据库的高可用方案。但数据库没有分布式协调功能，所以在高可用方案的基础上增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。

分片概念：任务的分布式执行，需要将一个任务拆分为多个独立的任务项，然后由分布式的服务器分别执行某一个或几个分片项。

中心化和去中心化的区别：在实现难度上中心化非常高，只能实现一个调度中心，而且调度中心和作业执行的服务器之间要进行通信。而去中心化的话，实现难度比较低，没有一个中心，各个作业节点是自治的，不需要分布式的调度。第二个，部署难度，中心化稍微高一些，有一个调度中心，服务器还有一个注册中心。

去中心化有两种，一个是作业执行服务器，还有一个注册中心。触发时间统一控制，中心化是可以的，去中心化差一些，作业服务器执行的时间本身不一样的怎么办，有的公司没有问题，作业乱掉时用中心化，用各个服务器去分发调度。去中心化，每个中心都是根据自己的时钟进行作业，这是很难控制的。

特点

定时任务：基于成熟的定时任务作业框架Quartz cron表达式执行定时任务；

作业注册中心：基于Zookeeper实现全局作业注册控制中心。用于注册，控制和协调分布式作业执行。

作业分片：将要给任务分片成多个小任务项到多服务器上同时执行；

弹性扩容缩容：运行中的作业服务器崩溃，或新增N台作业服务器，作业框架将在下次作业执行前重新分片，不影响当前作业执行；

个任务监控和管理界面：Elastic-Job-Lite-Console。它和Elastic-Job-Lite是两个完全不关联的应用程序，使用ZooKeeper来交换数据，管理人员可以通过这个界面查看、监控和管理Elastic-Job-Lite的任务，必要的时候还能手动触发任务。

image.png

2.3 XXL-JOB

介绍

XXL-JOB是一个轻量级分布式任务调度平台,调度采用中心式设计，“调度中心”基于集群Quartz实现并支持集群部署。任务分布式执行，任务"执行器"支持集群部署。

设计思想

将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。

将任务抽象成分散的JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的

JobHandler中业务逻辑。

因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性；

系统组成

调度模块(调度中心)： 负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。调度系统

与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块； 支持可视化、简单且动

态的管理调度信息，包括任务新建，更新，删除，GLUE开发和任务报警等，所有上述操作都会实时生效，

同时支持监控调度结果以及执行日志，支持执行器Failover。

执行模块(执行器)： 负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效； 接收“调度中心”的执行请求、终止请求和日志请求等。

与quartz对比

有任务管理界面，操作人性化

调度逻辑和QuartzJobBean任务解耦，quartz是耦合在同一个项目中的，调度任务数量逐渐增多，调度任务逻辑逐渐加重的情况下，调用系统的性能将大大受限于业务。

quartz底层以“抢占式”获取DB锁并由抢占成功节点负责运行任务，会导致节点负载悬殊非常大；而XXL-JOB通过执行器实现“协同分配式”运行任务，充分发挥集群优势，负载各节点均衡。

调用中心管理界面

image.png

参考

https://www.jianshu.com/p/14f86c6efe22

http://blog.51cto.com/lavasoft/181907

https://blog.csdn.net/qq_27232757/article/details/77775538