elestic-job的机制

Elastic job

1.简单定时任务基本组成SimpleTrigger quartz

Scheduler：调度器

JobDetail：任务数据

触发条件：cron表达式

分布式quartz:

调度每个服务实例中会有一个调度器，任务名为key，包含任务触发的数据和触发条件,Quart集群为了保障一个任务只被执行一次，需要使用使用数据库悲观锁来实现分布式，性能低下。

2.elastic_job

任务分片:当需要执行大批量的跑批任务时，比如下载批量任务，一台机器需要花费100分钟，俩台机器只需要50分钟。需要将一个任务拆分成多个独立的任务项，然后由分布式的服务器分别执行某一个或几个分片项。

Quart：

Quart实现的集群，但性能低下，且不能实现任务分片，水平扩展难以实现。

ElasticJob：

采用基于zookeeper注册中心支持任务分片，效率高

任务高可用：将分片总数设置为1，能解决任务的分布式问题，从而实现服务的一主多从模式。（我们现在还没有使用任务分片的功能，所有的任务只在主服务器上执行）

弹性扩容：一旦有新的服器加入集群或有服务器宕机。Elastic-Job将保留本次任务不变，下次任务开始前重新分片。

并行调度：

集中管理

定制化流程任务：作业可分为简单和数据流处理两种模式，数据流又分为高吞吐处理模式和顺序性处理模式(我们使用的就是简单模式)

去中心化:elastic_job没有调度中心，每个服务自己负责任务调度，节点之间通过注册中心来进行分布式协调，但elastic有主从节点之分，主节点会进行任务分片算法将任务分片，并作为事务任务的总调度器。

数据分片：服务器分片目前都存储在注册中心中，各个服务器根据自己的IP地址拉取分片。

3.整体架构

 

4.zookeeper调度

4.1目录结构：

shardingItemParameters: 0=beijing,1=shanghai,2=suzhou

Elasticjob:命名空间

Config:

Cron:

Disabled:任务调度器会根据这个值来判断是否执行任务，禁用本地分片

JobEC：数据库配置源，任务执行完成后，会进入数据库更新log和trace_log

JobParameter：我们向注册中心注册的任务数据，对应我们的JobTask对象

Sit：定制个性化参数，配合业务逻辑

Stc：分片总数必须要大于个性化参数的长度

Server:历史实例机器的ip，节点存储的值如果不是DISABLE，则认为该节点可用。

Sharding:每个实例任务开始执行前需要获取任务分片信息，0代表不需要分片，主节点会等所有分片任务执行完成后

Leader

Sharding

Necessary：是否需要重新分片

Processing:正在分片

Runing:正在执行

Instance:当前的可用实例ip

监听器