定时任务之elastic-job概述

下面这个例子很好的覆盖了Quartz最重要的3个基本要素：

例子中是HelloQuartz。 为什么设计成JobDetail + Job，不直接使用Job？这是因为任务是有可能并发执行，如果Scheduler直接使用Job，就会存在对同一个Job实例并发访问的问题。而JobDetail &Job 方式，sheduler每次执行，都会根据JobDetail创建一个新的Job实例，这样就可以规避并发访问的问题。

定义Job类为HelloQuartz类，这是真正的执行逻辑所在

当当是在quartz的基础上封装了quartz，对应的有

1.创建一个org.quartz.Job的实现类，并实现实现自己的业务逻辑。

public final class LiteJob implements Job {}

2.定义一个JobDetail，引用这个实现类 。

3.Scheduler调度器。

以下举例说明如何使用当当：

设置分片参数，定义Job配置类，执行计划等配置

定义Job类

意为简单实现，未经任何封装的类型。需实现SimpleJob接口。该接口仅提供单一方法用于覆盖，此方法将定时执行。与Quartz原生接口相似，但提供了d性扩缩容和分片等功能。

Dataflow类型用于处理数据流，需实现DataflowJob接口。该接口提供2个方法可供覆盖，分别用于抓取(fetchData)和处理(processData)数据。

流式作业：涉及到两个概念分片分批

即上面重写的两个方法中

fetchData 用于抓取，如数据库中的待抓取歌曲中有一个字段用来标识该任务是属于哪一个分片，即到时候会在哪一个分片上执行。如有两个分片，用分片号0、1表示。1000首待抓取的歌，500首标记为0，500首标记为1。那么到时候我们将歌曲的信息作为上下文参数传入到fetch方法中，500首歌可以limit 100，每次查出100首歌进行处理，这就叫分批，一个任务被分成了2片，每片里面按照100首歌一批，分5批执行完。

processData 就是按照批次每次处理100首歌，其中100首歌作为一个子事物，其中有一首歌抛异常或者出现任何失败，那么都认为这个批次执行失败，下次会将这个批次内的所有任务数据在执行一遍。

事件追踪的event_trace_rdb_url属性对应库自动创建JOB_EXECUTION_LOG和JOB_STATUS_TRACE_LOG两张表以及若干索引。

JOB_EXECUTION_LOG记录每次作业的执行 历史 。分为两个步骤：

作业开始执行时向数据库插入数据，除failure_cause和complete_time外的其他字段均不为空。

作业完成执行时向数据库更新数据，更新is_success, complete_time和failure_cause(如果作业执行失败)。

JOB_STATUS_TRACE_LOG记录作业状态变更痕迹表。可通过每次作业运行的task_id查询作业状态变化的生命周期和运行轨迹。

可通过配置多个任务监听器，在任务执行前和执行后执行监听的方法。监听器分为每台作业节点均执行和分布式场景中仅单一节点执行2种。

若作业处理作业服务器的文件，处理完成后删除文件，可考虑使用每个节点均执行清理任务。此类型任务实现简单，且无需考虑全局分布式任务是否完成，请尽量使用此类型监听器。

步骤：

定义监听

将监听器作为参数传入JobScheduler

若作业处理数据库数据，处理完成后只需一个节点完成数据清理任务即可。此类型任务处理复杂，需同步分布式环境下作业的状态同步，提供了超时设置来避免作业不同步导致的死锁，请谨慎使用。

步骤：

定义监听

将监听器作为参数传入JobScheduler

全路径：

io.elasticjob.lite.api.strategy.impl.AverageAllocationJobShardingStrategy

策略说明：

基于平均分配算法的分片策略，也是默认的分片策略。

如果分片不能整除，则不能整除的多余分片将依次追加到序号小的服务器。如：

如果有3台服务器，分成9片，则每台服务器分到的分片是：1=[0,1,2], 2=[3,4,5], 3=[6,7,8]

如果有3台服务器，分成8片，则每台服务器分到的分片是：1=[0,1,6], 2=[2,3,7], 3=[4,5]

如果有3台服务器，分成10片，则每台服务器分到的分片是：1=[0,1,2,9], 2=[3,4,5], 3=[6,7,8]

全路径：

io.elasticjob.lite.api.strategy.impl.OdevitySortByNameJobShardingStrategy

策略说明：

根据作业名的哈希值奇偶数决定IP升降序算法的分片策略。

作业名的哈希值为奇数则IP升序。

作业名的哈希值为偶数则IP降序。

用于不同的作业平均分配负载至不同的服务器。

全路径：

io.elasticjob.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy

策略说明：

根据作业名的哈希值对服务器列表进行轮转的分片策略。

解压缩elastic-job-lite-console-${version}.tar.gz并执行binstart.sh。打开浏览器访问http://localhost:8899/即可访问控制台。8899为默认端口号，可通过启动脚本输入-p自定义端口号。

elastic-job-lite-console-${version}.tar.gz可通过mvn install编译获取。

登录

提供两种账户，管理员及访客，管理员拥有全部 *** 作权限，访客仅拥有察看权限。默认管理员用户名和密码是root/root，访客用户名和密码是guest/guest，可通过confauth.properties修改管理员及访客用户名及密码。

功能列表

登录安全控制

注册中心、事件追踪数据源管理

快捷修改作业设置

作业和服务器维度状态查看

*** 作作业禁用启用、停止和删除等生命周期

事件追踪查询

备注：

请使用JDK1.7及其以上版本

请使用Zookeeper 3.4.6及其以上版本

请使用Maven 3.0.4及其以上版本

注册中心在定义的命名空间下，创建作业名称节点，用于区分不同作业，所以作业一旦创建则不能修改作业名称，如果修改名称将视为新的作业。作业名称节点下又包含4个数据子节点，分别是config, instances, sharding, servers和leader。

config节点

作业配置信息，以JSON格式存储

instances节点

作业运行实例信息，子节点是当前作业运行实例的主键。作业运行实例主键由作业运行服务器的IP地址和PID构成。作业运行实例主键均为临时节点，当作业实例上线时注册，下线时自动清理。注册中心监控这些节点的变化来协调分布式作业的分片以及高可用。 可在作业运行实例节点写入TRIGGER表示该实例立即执行一次。

sharding节点

作业分片信息，子节点是分片项序号，从零开始，至分片总数减一。分片项序号的子节点存储详细信息。每个分片项下的子节点用于控制和记录分片运行状态。节点详细信息说明：

servers节点

作业服务器信息，子节点是作业服务器的IP地址。可在IP地址节点写入DISABLED表示该服务器禁用。 在新的cloud native架构下，servers节点大幅弱化，仅包含控制服务器是否可以禁用这一功能。为了更加纯粹的实现job核心，servers功能未来可能删除，控制服务器是否禁用的能力应该下放至自动化部署系统。

leader节点

作业服务器主节点信息，分为election，sharding和failover三个子节点。分别用于主节点选举，分片和失效转移处理。

leader节点是内部使用的节点，如果对作业框架原理不感兴趣，可不关注此节点。

我是 「翎野君」 ，感谢各位朋友的： 点赞 、 收藏 和 评论 ，我们下期见。

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

提供的功能：

分布式调度协调： 在分布式环境中，任务能够按指定的调度策略执行，并且能够避免同一任务多实例重复执行。 

丰富的调度策略： 基于成熟的定时任务作业框架Quartz cron表达式执行定时任务。 

d性扩容缩容： 当集群中增加某一个实例，它应当也能够被选举并执行任务；当集群减少一个实例时，它所执行的任务能被转移到别的实例来执行。 

失效转移： 某实例在任务执行失败后，会被转移到其他实例执行。 

错过执行作业重触发 ： 若因某种原因导致作业错过执行，自动记录错过执行的作业，并在上次作业完成后自动触发。 

支持并行调度 ： 支持任务分片，任务分片是指将一个任务分为多个小任务项在多个实例同时执行。 

作业分片一致性 ： 当任务被分片后，保证同一分片在分布式环境中仅一个执行实例。 

支持作业生命周期 *** 作 ： 可以动态对任务进行开启及停止 *** 作。 

丰富的作业类型： 支持Simple、DataFlow、Script三种作业类型，后续会有详细介绍。 

Spring整合以及命名空间支持 ： 对Spring支持良好的整合方式，支持spring自定义命名空间，支持占位符。 

运维平台 ： 提供运维界面，可以管理作业和注册中心。 

分片概念 

作业分片是指任务的分布式执行，需要将一个任务拆分为多个独立的任务项，然后由分布式的应用实例分别执行某 一个或几个分片项。 

例如：Elastic-Job快速入门中文件备份的例子，现有2台服务器，每台服务器分别跑一个应用实例。为了快速的执行作业，那么可以将作业分成4片，每个应用实例个执行2片。作业遍历数据的逻辑应为：实例1查找text和image 类型文件执行备份；实例2查找radio和video类型文件执行备份。 如果由于服务器扩容应用实例数量增加为4，则 作业遍历数据的逻辑应为：4个实例分别处理text、image、radio、video类型的文件。 

可以看到，通过对任务合理的分片化，从而达到任务并行处理的效果，最大限度的提高执行作业的吞吐量。 

分片项与业务处理解耦 

Elastic-Job并不直接提供数据处理的功能，框架只会将分片项分配至各个运行中的作业服务器，开发者需要自行处 理分片项与真实数据的对应关系。 

最大限度利用资源

将分片项设置为大于服务器的数量，最好是大于服务器倍数的数量，作业将会合理的利用分布式资源，动态的分配分片项。 

例如：3台服务器，分成10片，则分片项分配结果为服务器A=0,1,2服务器B=3,4,5服务器C=6,7,8,9。 如果服务器C 崩溃，则分片项分配结果为服务器A=0,1,2,3,4服务器B=5,6,7,8,9。在不丢失分片项的情况下，最大限度的利用现有资源提高吞吐量。 

作业类型

elastic-job提供了三种类型的作业：Simple类型作业、Dataflow类型作业、Script类型作业。这里主要讲解前两者。Script类型作业意为脚本类型作业，支持shell，python，perl等所有类型脚本，使用不多，可以参见github文档。 

SimpleJob需要实现SimpleJob接口，意为简单实现，未经过任何封装，与quartz原生接口相似。

Dataflflow类型的定时任务需实现DataflflowJob接口，该接口提供2个方法可供覆盖，分别用于抓取(fetchData)和处理(processData)数据。Dataflflow类型用于处理数据流，它和SimpleJob不同，它以数据流的方式执行，调用fetchData抓取数据，直到抓取不到数据才停止作业。 

非流式处理数据则只会在每次作业执行过程中执行一次fetchData方法和processData方法，随即完成本次作业。  

---