任务调度

Quartz

http://www.quartz-scheduler.org/

体系结构

• Job - 你想要调度器执行的任务组件需要实现的接口,一个 job 就是一个实现了 Job 接口的类，该接口只有一个方法execute
• JobDetail - 用于定义作业的实例。。
• Trigger（即触发器） - 定义执行给定作业的计划的组件。job的一个 trigger 被触发后，execute() 方法会被 scheduler 的一个工作线程调用。最常用SimpleTrigger 和 CronTrigger
• JobBuilder - 用于定义/构建 JobDetail 实例，用于定义作业的实例。使用 JobBuilder 包装成 JobDetail，它可以携带 KV 的数据
• TriggerBuilder - 用于定义/构建触发器实例。
• Scheduler-调度器，是 Quartz 的指挥官，由 StdSchedulerFactory 产生。它是单例的。Scheduler 的生命期，从 SchedulerFactory 创建它时开始，到 Scheduler 调用shutdown() 方法时结束；Scheduler 被创建后，可以增加、删除和列举 Job 和 Trigger，以及执行其它与调度相关的操作（如暂停 Trigger）。但是，Scheduler 只有在调用 start() 方法后，才会真正地触发 trigger（即执行 job）
• Listener- Quartz 中提供了三种 Listener，监听 Scheduler 的，监听 Trigger 的，监听 Job 的
• JobStore-  用来存储任务和触发器相关的信息，例如所有任务的名称、数量、状态等 等。Quartz 中有两种存储任务的方式，一种在在内存，一种是在数据库

集成到spring

Service 类注入到 Job 中

Quartz 集成到 Spring 中，用到 SchedulerFactoryBean，其实现了 InitializingBean 方法，在唯一的方法 afterPropertiesSet()在 Bean 的属性初始化后调用。 调度器用 AdaptableJobFactory 对 Job 对象进行实例化。所以，如果我们可以把这 个 JobFactory 指定为我们自定义的工厂的话，就可以在 Job 实例化完成之后，把 Job 纳入到 Spring 容器中管理。

1、定义一个 AdaptableJobFactory，实现 JobFactory 接口，实现接口定义的 newJob 方法，在这里面返回 Job 实例

2、定义一个 MyJobFactory，继承 AdaptableJobFactory。 使用 Spring 的 AutowireCapableBeanFactory，把 Job 实例注入到容器中。

 @Component
    public class MyJobFactory extends AdaptableJobFactory {
        @Autowired
        private AutowireCapableBeanFactory capableBeanFactory;
        protected Object createJobInstance(TriggerFiredBundle bundle) throws Exception {
            Object jobInstance = super.createJobInstance(bundle);
            capableBeanFactory.autowireBean(jobInstance);
            return jobInstance;
        }
    }

3、指定 Scheduler 的 JobFactory 为自定义的 JobFactory。 com.demo.config.InitStartSchedule 中：

scheduler.setJobFactory(myJobFactory);

Quartz 集群部署

防止单点故障，减轻负载压力。防止任务重跑和漏跑。

源码分析

常见问题

什么情况下错过触发？错过触发怎么办？

1、 没有可用线程 2、 Trigger 被暂停 3、 系统重启 4、 禁止并发执行的任务在到达触发时间时，上次执行还没有结束

ElasticJob

https://shardingsphere.apache.org/elasticjob/current/cn/features/elastic/

定位为轻量级无中心化解决方案，使用 jar 的形式提供分布式任务的协调服务

任务类型有三种：

SimpleJob

DataFlowJob：用于处理数据流，必须实现 fetchData()和 processData()的方法，一个用来获取数据，一个用来处理获取到的数据

ScriptJob：Script 类型作业意为脚本类型作业，支持 shell，python，perl 等所有类型 脚本

e-job配置

1、ZK 注册中心配置 

2、作业配置（从底层往上层：Core——Type——Lite）

配置级别	配置类	配置内容
Core	JobCoreConfiguration	用于提供作业核心配置信息，如：作业名称、CRON 表达式、分片总数等
type	JobTypeConfiguration	有 3 个子类分别对应 SIMPLE, DATAFLOW 和 SCRIPT 类型作业，提供 3 种作 业需要的不同配置，如：DATAFLOW 类型是否流式处理或 SCRIPT 类型的命 令行等。Simple 和 DataFlow 需要指定任务类的路径。
lite	JobRootConfiguration	有 2 个子类分别对应 Lite 和 Cloud 部署类型，提供不同部署类型所需的配 置，如：Lite 类型的是否需要覆盖本地配置或 Cloud 占用 CPU 或 Memory 数量等。 可以定义分片策略

 

ZK 注册中心数据结构

一个任务一个二级节点.修改了任务重新运行任务不生效，是因为 ZK 的信息不会更新, 除非把 overwrite 修改成 true。 

config 节点

JSON 格式存储。 存储任务的配置信息，包含执行类，cron 表达式，分片算法类，分片数量，分片参 数等等。

config 节点的数据是通过ConfigService 持久化到 zookeeper中去的。默认状态下， 如果你修改了 Job 的配置比如 cron 表达式、分片数量等是不会更新到 zookeeper 上去 的，除非你在 Lite 级别的配置把参数 overwrite 修改成 true。

instances 节点

同一个 Job 下的 elastic-job 的部署实例。一台机器上可以启动多个 Job 实例，也就 是 Jar 包。instances 的命名是 IP+@-@+PID。只有在运行的时候能看到

leader 节点

任务实例的主节点信息，通过 zookeeper 的主节点选举，选出来的主节点信息。在 elastic job 中，任务的执行可以分布在不同的实例（节点）中，但任务分片等核心控制， 需要由主节点完成。因此，任务执行前，需要选举出主节点。 下面有三个子节点：

• election：主节点选举
• sharding：分片
• failover：失效转移

election 下面的 instance 节点显示了当前主节点的实例 ID：jobInstanceId。 election 下面的 latch 节点也是一个永久节点用于选举时候的实现分布式锁。 sharding 节点下面有一个临时节点，necessary，是否需要重新分片的标记。如果 分片总数变化，或任务实例节点上下线或启用/禁用，以及主节点选举，都会触发设置重 分片标记，主节点会进行分片计算。

servers 节点

任务实例的信息，主要是 IP 地址，任务实例的 IP 地址。跟 instances 不同，如果多 个任务实例在同一台机器上运行则只会出现一个 IP 子节点。可在 IP 地址节点写入 DISABLED 表示该任务实例禁用

sharding 节点

任务的分片信息，子节点是分片项序号，从 0 开始。分片个数是在任务配置中设置 的。分片项序号的子节点存储详细信息。每个分片项下的子节点用于控制和记录分片运 行状态。最主要的子节点就是 instance

子节点名	是否临时节点	描述
instance	否	执行该分片项的作业运行实例主键
runnung	是	分片项正在运行的状态 仅配置 monitorExecution 时有效
failover	是	如果该分片项被失效转移分配给其他作业服务器，则此节点值记录执行此分 片的作业服务器 IP
misfire	否	是否开启错过任务重新执行
disabled	否	是否禁用此分片项