分布式任务管理器

一、为什么要使用分布式定时任务？

1、高可用

　　单机版定时任务只能在一台机器上运行，如果异常了，会导致依赖于这个机器的业务全部瘫痪，如：下载订单，库存同步等。

2、单机处理极限

　　如果是一台机器去运行，总会有遇到瓶颈的时候，这个时候可能通过升级配置能解决，但下次又到瓶颈的时候如何解决？

二、分布式定时任务

几种主流的分布是定时任务解决方案：quartz的集群解决方案、淘宝的TBSchedule、当当网的elasticjob，xxl-job

1、quartz的集群解决方案

（1）、基于db

其实非常的简单，就是将执行任务写到数据库中，多个部署节点都基于同一个DB就行并发控制。

集群分布式并发环境中使用QUARTZ定时任务调度，会在各个节点会上报任务，存到数据库中，执行时会从数据库中取出触发器来执行，如果触发器的名称和执行时间相同，则只有一个节点去执如果此节点执行失败，则此任务则会被分派到另一节点执行，中途也会自动检查失效的定时调度，发现不成功的，其他节点立马接过来继续完成定时任务。对应的定时任务调度表比较多，有11个。

知道就好了。

（2）、基于一致性hash分片

一致性hash文章：https://blog.csdn.net/u011305680/article/details/79721030

适用于按用户分类的场景。

 

缺点：

Quartz一点都不明确你是在同一台机器上运行所有节点，还是在不同的机器上运行所有节点。当集群是放置在不同的机器上时，我们称之为水平集群。如果所有节点是跑在同一台机器的时候，我们称之为垂直集群。对于垂直集群，存在着单点故障的问题。这对高可用性的应用来说是个坏消息，因为一旦机器宕掉了，所有的节点也就被有效的终止了。而当你运行水平集群时，一个严格的要求就是我们的时钟时间必须要同步，以免出现离奇且不可预知的行为。假如时钟没能够同步，Scheduler 实例将对其他节点的状态产生混乱，造成难以估计得麻烦。

 XXL-JOB官方写的：

Quartz作为开源作业调度中的佼佼者，是作业调度的首选。但是集群环境中Quartz采用API的方式对任务进行管理，从而可以避免上述问题，但是同样存在以下问题：

• 问题一：调用API的的方式操作任务，不人性化；
• 问题二：需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。
• 问题三：调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况下，此时调度系统的性能将大大受限于业务；
• 问题四：quartz底层以“抢占式”获取DB锁并由抢占成功节点负责运行任务，会导致节点负载悬殊非常大；而XXL-JOB通过执行器实现“协同分配式”运行任务，充分发挥集群优势，负载各节点均衡。

 

2、xxl-job分布式调度平台

xxl-job的特点：

1、简单：支持通过Web页面对人物进行crud操作。简单容易上手

2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；

3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；

​4、执行器HA（分布式）：任务分布式执行，任务"执行器"支持集群部署，可保证任务执行HA；
​ 5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
​ 6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
​ 7、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等；
​ 8、故障转移：任务路由策略选择"故障转移"情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
​ 9、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；
​ 10、任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务；
​ 11、任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试；
​ 12、任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等告警方式；
​ 13、分片广播任务：执行器集群部署时，任务路由策略选择"分片广播"情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；
​ 14、动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
​ 15、事件触发：除了"Cron方式"和"任务依赖方式"触发任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发

搭建自己的xxl-job调度器

GitHub地址：https://github.com/xuxueli/xxl-job

Gitee地址：https://gitee.com/xuxueli0323/xxl-job

我的gitee地址：https://gitee.com/cloud_cutter/xxl-job-zk.git

步骤：

1、找到tables_xxl_job.sql文件，将文件中的表导入到数据库中

2、修改src\main\resources\application.properties文件下数据库地址（改成自己的地址即可）

3、启动admin项目

4、编写自己的定时任务

1. 找到xxl-job-executor-sample-springboot项目，目录com.xxl.job.executor.service.jobhandler（xxl-job自带的springboot项目）
2. 新增一个java文件，继承IJobHandler，实现方法execute

5、启动XxlJobExecutorApplication.java

6、打开任务调度中心（即上面的admin服务，测试地址：http://localhost:8080/xxl-job-admin 默认账户admn，密码123456）

7、后面添加任务什么的，百度，或者访问地址：https://blog.csdn.net/f2315895270/article/details/104714692/

 

xxl-job原理

官方文档：https://www.xuxueli.com/xxl-job/#/?id=%E4%B8%80%E3%80%81%E7%AE%80%E4%BB%8B

 

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

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

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

 

调度中心

实际就是上面的admin服务，可视化

执行器

执行器实际上是一个内嵌的Server，默认端口9999（配置项：xxl.job.executor.port）。

在项目启动时，执行器会通过“@JobHandler”识别Spring容器中“Bean模式任务”，以注解的value属性为key管理起来。

“执行器”接收到“调度中心”的调度请求时，如果任务类型为“Bean模式”，将会匹配Spring容器中的“Bean模式任务”，然后调用其execute方法，执行任务逻辑。如果任务类型为“GLUE模式”，将会加载GLue代码，实例化Java对象，注入依赖的Spring服务（注意：Glue代码中注入的Spring服务，必须存在与该“执行器”项目的Spring容器中），然后调用execute方法，执行任务逻辑。

 

分片原理：

参考类：ShardingJobHandler

 

3、elastic-job

当当网基于quartz 二次开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片。Elastic-Job是一个分布式调度的解决方案，由当当网开源，它由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成，使用Elastic-Job可以快速实现分布式任务调度。

官方文档：https://shardingsphere.apache.org/elasticjob/current/cn/overview/