elastic-job分布式作业调度框架简介

1.elastic-job是什么？

elastic-job是当当内部应用框架ddframe中dd-job的作业模块中分离出来的分布式弹性作业框架。

2. 什么是作业调度（定时任务）?

作业即定时任务。一般来说，系统可使用消息传递代替部分使用作业的场景。两者确有相似之处。可互相替换的场景，如队列表。将待处理的数据放入队列表，然后使用频率极短的定时任务拉取队列表的数据并处理。这种情况使用消息中间件的推送模式可更好的处理实时性数据。而且基于数据库的消息存储吞吐量远远小于基于文件的顺序追加消息存储。

3. elastic-job整体架构图

4. elastic-job具体模块的底层及如何实现以及它们的作用？

elastic-job的主要分为注册中心、数据分片、分布式协调，定时任务处理和多作业模式等模块。

注册中心模块目前直接使用Zookeeper，用于记录作业的配置，服务器信息以及作业运行状态。Zookeeper目前的znode分四类，config，servers，execution，leader。config用于保存分布式作业的全局控制，如，分多少片，要不要执行misfire，cron表达式。servers用于注册作业服务器状态和分片信息。execution以分片的维度存储作业运行时状态。leader用于存储主节点。elastic-job作业执行是无中心化的，但主节点起到协调的作用，如：重分片、清理上次运行时信息等。

如果Zookeeper挂了，是否全部的任务都挂了不能运行包括已经运行过一次的，如果又恢复了，任务能正常运行吗，还是业务应用服务也要重新启动？

其实Zookeeper是不太容易挂的。毕竟Zookeeper是分布式高可用，一般不会是单台。目前elastic-job做到的容错是，连不上Zookeeper的作业服务器将立刻停止执行作业，防止主节点已重新分片，而脑裂的服务器还在执行。也就是说，Zookeeper挂掉，所有作业都将停止。而作业服务器一旦与Zookeeper恢复连接，作业也将恢复运行。所以Zookeeper挂掉不会影响数据，而Zookeeper恢复，作业会继续跑，不用重启。

失效转移中如何判断失效？对任务本身实现有什么限制？

失效转移目前通过Zookeeper监听分片项临时节点判断。elastic-job会经过注册中心会话过期时间才能感知任务挂掉。失效转移有两种形式：1、任务挂掉，elastic-job会找空闲的作业服务器（可能是未分配任务的，也可能是完成执行本次任务执行的）执行。2、如果当时没有空闲服务器，则将在某服务器完成分配的任务时抓取未分配的分片项。

数据分片是elastic-job中实现分布式的重要概念，将真实数据和逻辑分片对应，用于解耦作业框架和数据的关系。作业框架只负责将分片合理的分配给相关的作业服务器，而作业服务器需要根据所分配的分片匹配数据进行处理。服务器分片目前都存储在注册中心中，各个服务器根据自己的IP地址拉取分片。

分布式协调模块用于处理作业服务器的动态扩容缩容。一旦集群中有服务器发生变化，分布式协调将自动监测并将变化结果通知给各个仍存活的作业服务器。协调时将会涉及主节点选举，重分片等操作。目前使用的Zookeeper的临时节点和监听器实现主动检查和通知功能。

定时任务处理根据cron表达式定时触发任务，目前有防止任务同时触发，错过任务重出发等功能。主要还是使用Quartz本身的定时调度功能，为了便于控制，每个任务都使用独立的线程池。

多作业模式将定时任务分为多种流程，有不经任何修饰的简单任务；有用于处理数据的fetchData/processData的数据流任务；以后还将增加消息流任务，文件任务，工作流任务等。

5. 除了elastic-job还有哪些是作业调度框架呢？

Quartz：

Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行执行作业的功能。

TBSchedule：

阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重。

Crontab：

Linux系统级的定时任务执行器。缺乏分布式和集中管理功能。

6. elastic-job有什么功能和优点呢？

主要功能

分布式：重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心。

并行调度：采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。

弹性扩容缩容：将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。

集中管理：采用基于Zookeeper的注册中心，集中管理和协调分布式作业的状态，分配和监听。外部系统可直接根据Zookeeper的数据管理和监控elastic-job。 定制化流程型任务：作业可分为简单和数据流处理两种模式，数据流又分为高吞吐处理模式和顺序性处理模式，其中高吞吐处理模式可以开启足够多的线程快速的处理数据，而顺序性处理模式将每个分片项分配到一个独立线程，用于保证同一分片的顺序性，这点类似于kafka的分区顺序性。

其他功能

失效转移：弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能。

Spring命名空间支持：elastic-job可以不依赖于spring直接运行，但是也提供了自定义的命名空间方便与spring集成。

运维平台：提供web控制台用于管理作业。

非功能需求

稳定性：在服务器无波动的情况下，并不会重新分片；即使服务器有波动，下次分片的结果也会根据服务器IP和作业名称哈希值算出稳定的分片顺序，尽量不做大的变动。

高性能：同一服务器的批量数据处理采用自动切割并多线程并行处理。

灵活性：所有在功能和性能之间的权衡，都可通过配置开启/关闭。如：elastic-job会将作业运行状态的必要信息更新到注册中心。如果作业执行频度很高，会造成大量Zookeeper写操作，而分布式Zookeeper同步数据可能引起网络风暴。因此为了考虑性能问题，可以牺牲一些功能，而换取性能的提升。

幂等性：elastic-job可牺牲部分性能用以保证同一分片项不会同时在两个服务器上运行。

容错性：作业服务器和Zookeeper断开连接则立即停止作业运行，用于防止分片已经重新分配，而脑裂的服务器仍在继续执行，导致重复执行。