官网 :: ElasticJob
ElasticJob 是面向互联网生态和海量任务的分布式调度解决方案,由两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。 它通过弹性调度、资源管控、以及作业治理的功能,打造一个适用于互联网场景的分布式调度解决方案,并通过开放的架构设计,提供多元化的作业生态。 它的各个产品使用统一的作业 API,开发者仅需一次开发,即可随意部署。
ElasticJob-Lite
简介:
定位为轻量级无中心化解决方案,使用 jar 的形式提供分布式任务的协调服务。
功能:
弹性调度:
支持任务分布式场景下的分片和高可用
能够水平扩张任务的吞吐量和执行效率
任务处理能力岁资源配备弹性伸缩
资源分配:
在适合的时间将适合的资源分配给任务并使其生效
相同任务聚合至相同的执行器统一处理
动态调配追加资源至新分配的任务
作业治理:
失效转移
错过作业重新执行
自诊断修复
作业依赖:
基于DAG的作业依赖
基于DAG的作业分片依赖
作业开放生态:
可扩展的作业类型统一接口
丰富的作业类型库,如数据流、脚本、http、文件、大数据等
易于对接业务作业,能够与spring依赖注入无缝整合
可视化管理端:
作业管控端
作业执行历史数据追踪
注册中心管理
入门:
引入 Maven 依赖
<dependency><groupId>org.apache.shardingsphere.elasticjob</groupId><artifactId>elasticjob-lite-core</artifactId><version>${latest.release.version}</version>
</dependency>
作业开发
public class MyJob implements SimpleJob {@Overridepublic void execute(ShardingContext context) {switch (context.getShardingItem()) {case 0: // do something by sharding item 0break;case 1: // do something by sharding item 1break;case 2: // do something by sharding item 2break;// case n: ...}}
}
作业配置
JobConfiguration jobConfig = JobConfiguration.newBuilder("MyJob", 3).cron("0/5 * * * * ?").build();
作业调度
public class MyJobDemo {public static void main(String[] args) {new ScheduleJobBootstrap(createRegistryCenter(), new MyJob(), createJobConfiguration()).schedule();}private static CoordinatorRegistryCenter createRegistryCenter() {CoordinatorRegistryCenter regCenter = new ZookeeperRegistryCenter(new ZookeeperConfiguration("zk_host:2181", "my-job"));regCenter.init();return regCenter;}private static JobConfiguration createJobConfiguration() {// 创建作业配置// ...}
}
概念:
调度模型:
ElasticJob-Lite 是面向进程内的线程级调度框架。通过它,作业能够透明化的与业务应用系统相结合。 它能够方便的与 Spring 、Dubbo 等 Java 框架配合使用,在作业中可自由使用 Spring 注入的 Bean,如数据源连接池、Dubbo 远程服务等,更加方便的贴合业务开发
弹性调度:
弹性调度是 ElasticJob 最重要的功能,ElasticJob 中任务分片项的概念,使得任务可以在分布式的环境下运行,每台任务服务器只运行分配给该服务器的分片, 随着服务器的增加或宕机,ElasticJob 会近乎实时的感知服务器数量的变更,从而重新为分布式的任务服务器分配更加合理的任务分片项,使得任务可以随着资源的增加而提升效率。任务的分布式执行,需要将一个任务拆分为多个独立的任务项,然后由分布式的服务器分别执行某一个或几个分片项。
个性化参数可以和分片项匹配对应关系,用于将分片项的数字转换为更加可读的业务代码。
ElasticJob 提供最灵活的方式,最大限度的提高执行作业的吞吐量。 当新增加作业服务器时,ElasticJob 会通过注册中心的临时节点的变化感知到新服务器的存在,并在下次任务调度的时候重新分片,新的服务器会承载一部分作业分片,如下图所示。
高可用
当作业服务器在运行中宕机时,注册中心同样会通过临时节点感知,并将在下次运行时将分片转移至仍存活的服务器,以达到作业高可用的效果。 本次由于服务器宕机而未执行完的作业,则可以通过失效转移的方式继续执行。如下图所示
资源分配:
失效转移:
ElasticJob 不会在本次执行过程中进行重新分片,而是等待下次调度之前才开启重新分片流程。 当作业执行过程中服务器宕机,失效转移允许将该次未完成的任务在另一作业节点上补偿执行。
错过任务重执行:
ElasticJob 不允许作业在同一时间内叠加执行。 当作业的执行时长超过其运行间隔,错过任务重执行能够保证作业在完成上次的任务后继续执行逾期的作业
作业开放生态:
ElasticJob 的作业可划分为基于 class 类型和基于 type 类型两种。
Class 类型的作业由开发者直接使用,需要由开发者实现该作业接口实现业务逻辑。典型代表:Simple 类型、Dataflow 类型。 Type 类型的作业只需提供类型名称即可,开发者无需实现该作业接口,而是通过外置配置的方式使用。典型代表:Script 类型、HTTP 类型
实现原理:
ElasticJob-Lite 并无作业调度中心节点,而是基于部署作业框架的程序在到达相应时间点时各自触发调度。 注册中心仅用于作业注册和监控信息存储。而主作业节点仅用于处理分片和清理等功能。
- 第一台服务器上线触发主服务器选举。主服务器一旦下线,则重新触发选举,选举过程中阻塞,只有主服务器选举完成,才会执行其他任务。
- 某作业服务器上线时会自动将服务器信息注册到注册中心,下线时会自动更新服务器状态。
- 主节点选举,服务器上下线,分片总数变更均更新重新分片标记。
- 定时任务触发时,如需重新分片,则通过主服务器分片,分片过程中阻塞,分片结束后才可执行任务。如分片过程中主服务器下线,则先选举主服务器,再分片。
- 通过上一项说明可知,为了维持作业运行时的稳定性,运行过程中只会标记分片状态,不会重新分片。分片仅可能发生在下次任务触发前。
- 每次分片都会按服务器IP排序,保证分片结果不会产生较大波动。
- 实现失效转移功能,在某台服务器执行完毕后主动抓取未分配的分片,并且在某台服务器下线后主动寻找可用的服务器执行任务。
数据模型:
注册中心在定义的命名空间下,创建作业名称节点,用于区分不同作业,所以作业一旦创建则不能修改作业名称,如果修改名称将视为新的作业。 作业名称节点下又包含5个数据子节点,分别是 config, instances, sharding, servers 和 leader。
config 节点:
作业配置信息,以 YAML 格式存储。
instances 节点:
作业运行实例信息,子节点是当前作业运行实例的主键。 作业运行实例主键由作业运行服务器的 IP 地址和 PID 构成。 作业运行实例主键均为临时节点,当作业实例上线时注册,下线时自动清理。注册中心监控这些节点的变化来协调分布式作业的分片以及高可用。 可在作业运行实例节点写入 TRIGGER 表示该实例立即执行一次。
sharding 节点:
作业分片信息,子节点是分片项序号,从零开始,至分片总数减一。 分片项序号的子节点存储详细信息。每个分片项下的子节点用于控制和记录分片运行状态。 节点详细信息说明:
servers 节点:
作业服务器信息,子节点是作业服务器的 IP 地址。 可在 IP 地址节点写入 DISABLED 表示该服务器禁用。 在新的云原生架构下,servers 节点大幅弱化,仅包含控制服务器是否可以禁用这一功能。 为了更加纯粹的实现作业核心,servers 功能未来可能删除,控制服务器是否禁用的能力应该下放至自动化部署系统。
leader 节点:
作业服务器主节点信息,分为 election,sharding 和 failover 三个子节点。 分别用于主节点选举,分片和失效转移处理。leader节点是内部使用的节点。
源码:
公司网络下载不下来源码,只能周末在家下载,下周来看了
ElasticJob-Cloud
采用自研 Mesos Framework 的解决方案,额外提供资源治理、应用分发以及进程隔离等功能