[学习笔记]Elastic-job分布式作业调度框架简介

2,158 阅读6分钟

简介

ElasticJob 是由当当开源面向互联网生态和海量任务的分布式调度解决方案,由两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。 它通过弹性调度、资源管控、以及作业治理的功能,打造一个适用于互联网场景的分布式调度解决方案,并通过开放的架构设计,提供多元化的作业生态。

架构图

ElasticJob-Lite

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

Elastic-Job-Cloud

采用自研 Mesos Framework 的解决方案,额外提供资源治理、应用分发以及进程隔离等功能。

ElasticJob-LiteElastic-Job-Cloud
无中心化
资源分配不支持支持
作业模式常驻常驻+瞬时
部署依赖ZooKeeperZooKeeper+Mesos

核心功能

弹性调度

  1. 支持任务在分布式场景下的分片和高可用
  2. 能够水平扩展任务的吞吐量和执行效率
  3. 任务处理能力随资源配备弹性伸缩

资源分配

  1. 在适合的时间将适合的资源分配给任务并使其生效
  2. 相同任务聚合至相同的执行器统一处理
  3. 动态调配追加资源至新分配的任务

作业治理

  1. 失效转移
  2. 错过作业重新执行
  3. 自诊断修复

作业依赖(TODO)

  1. 基于有向无环图(DAG)的作业间依赖
  2. 基于有向无环图(DAG)的作业分片间依赖

作业开放生态

  1. 可扩展的作业类型统一接口
  2. 丰富的作业类型库,如数据流、脚本、HTTP、文件、大数据等
  3. 易于对接业务作业,能够与 Spring 依赖注入无缝整合

可视化管控端

  1. 可视化管控端
  2. 作业执行历史数据追踪
  3. 注册中心管理

作业启动流图

  1. 启动注册中心
  2. 第一台服务器(作业服务器A)启动上线开启监听之后触发第一次主节点选举成为主节点,主服务器一旦下线,则重新触发选举,选举过程中阻塞,只有主服务器选举完成才会执行其他任务。
  3. 作业服务器B启动上线开启监听之后注册到注册中心,同时发起主节点选举,但此时已有主节点(服务器A)服务器B成为从节点,服务器下线时会更新服务器状态
  4. 主节点选举后,服务器的上下线,分片总数的变更都会更新重新分片标记,并将标记结果持久化到注册中心,同时会持久化服务器信息。
  5. 如果在定时任务触发时,需要重新分片,则通过主服务器分片,分片过程中阻塞,分片结束后才可以执行任务,如果分片过程中主服务器下线,则先选举主服务器,在进行分片。
  6. 通过5可得知,为了维持作业运行时的稳定,运行过程中只会标记分片状态,不会重新分片,分片仅可能发生在下次任务出发前。同时每次分片都会按照服务器ip排序,保证分片结果不会产生较大波动。
  7. 实现失效转移功能时,在某台服务器执行完毕后主动抓取未分配的分片,并且在某台服务器下线后主动寻找可以用的服务器执行任务。

作业执行流程图

  1. 当某一台服务器进行作业执行流程时,首先会判断是否需要重新分片,如果需要分片则会判断主服务器是否下线触发主节点选举,在这个过场中一直休眠阻塞,直到选举结束。
  2. 主节点选举完毕(或未触发主节点选举)判断当前服务器是否为主节点,如果是主节点服务器,则进行分片标记处理,并将分片结果持久化,并进行后续操作。如果不是主节点,则判断该服务器是否在分片中,这个过程会休眠阻塞至主节点服务器分片完成。
  3. 如果当前节点获取到了分片,则会根据服务器ip进行分片抓取,并在该分片在运行中时根据作业的类型调用对应的api。如simple任务则直接调用执行作业运行的接口,如为流式DataFlow则会先根据设置的参数(是否流式处理)抓取数据,如果设置为流式处理,则会一直抓取数据,只有当抓取数据接口返回null或者空集合时才会停止作业。
  4. 在流式任务DataFlow中会根据切片的数据多线程去执行数据的处理。最后记录数据处理成功或者失败的数量。

错过任务重执行

ElasticJob不允许作业在统一时间内叠加执行,当作业的执行时长超过其运行间隔,错过任务重执行能够保证作业在完成上次任务后继续执行逾期的作业

例如一个作业为整点运行,未来运行时间点为12:00,13:00,14:00...如果12点开始执行的作业由于种种原因知道13:10才运行结束,那么原来13:00应该触发的作业就错过了触发时间,则需要等到下一个执行时间点14:00才能触发。

如果开启了错过任务重执行功能之后,ElasticJob将会在上次作业执行完毕后,立即触发错过执行的任务。任务将会在13:10分立即被执行

适用场景

在一次运行耗时较长且间隔时间较长的作业场景中
对于不关注未见得关注单次作业的实时性的短间隔的作业来说,没有必要开启

失效转移

ElasticJob不会再本次执行过程中进行重新分片,只会在任务调度开始之前进行重新分片流程,当前作业运行过程中宕机,失效转移允许将该次未完成的作业在另一个作业节点上补偿执行

注意:失效转移需与监听作业运行状态同时开启才可以生效

执行机制

  1. 通知执行:当其他服务器感知到有失效转移的作业需要处理时,且该作业服务器已经完成了本次的作业任务,则会实时的拉取待失效转移的分片项,并开始补偿执行,也成为实时执行。
  2. 问询执行:作业服务器在执行完本次作业任务后,会向注册中心问询待失效转移分片项,如果有,则开始补偿执行。也成为异步执行。

适用场景

开启失效转移后,ElasticJob会监控作业每一分片的执行状态,并将其写入注册中心,供其他节点感知。 适用于一次运行耗时较长且间隔较长的作业场景
对于间隔较短的作业如果开启会产生大量与注册中心的交互,对集群性能产生依赖。不建议开启

需要注意,作业本身的幂等性是保证失效转移正确性的前提!