# elasticjob-quratz-demo

**Repository Path**: wsjlb/elasticjob-quratz-demo

## Basic Information

- **Project Name**: elasticjob-quratz-demo
- **Description**: elastic-job定时任务，通过zk实现定时任务的分布式集群管理、任务的分片执行
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2018-09-11
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

### 定时任务使用介绍
1. 该项目包括Quratz 和 elastic job 的使用demo ， 其中Quratz的Demo 暂未开发，Elastic Job Demo 已经开发了纯Java 和 与Spring-boot集成两种方式的demo。
2. 项目中包含读取yml配置文件的帮助类，见 YmlUtils （java通过snakeyaml读取yml文件后是以 linkedHashMap 的数据接口进行储存的）
##### Elastic job 开发使用步骤： 
1. 配置并创建注册中心 zookeeper
2. 创建编写job处理类
3. 创建并配置job的作业控制器scheduler
##### Elastic job 配置说明：  
Elastic-Job配置分为3个层级，分别是Core, Type和Root。每个层级使用相似于装饰者模式的方式装配。 （配置实例见：JavaJobConfig）
1. Core对应JobCoreConfiguration，用于提供作业核心配置信息，如：作业名称、分片总数、CRON表达式等。 
2. Type对应JobTypeConfiguration，有3个子类分别对应SIMPLE, DATAFLOW和SCRIPT类型作业，提供3种作业需要的不同配置，如：DATAFLOW类型是否流式处理或SCRIPT类型的命令行等。 
3. Root对应JobRootConfiguration，有2个子类分别对应Lite和Cloud部署类型，提供不同部署类型所需的配置，如：Lite类型的是否需要覆盖本地配置或Cloud占用CPU或Memory数量等。 
4. 配置Job的步骤为： 1、定义作业核心配置 2、定义DATAFLOW类型配置 3、定义Lite作业根配置

##### Elastic job 注意事项：
1. 分配到本作业实例的每个分片都将会开启新的线程进行处理，每个分片对应一个线程，每个线程对应一个fetchData() 和 processDatd() 的处理流程。   
2. 注: 相比1.x的版本 ，1.x版本是所有的分片会同时分配到作业实例，系统会开启一个线程处理所有的分片项，通过ShardingContext 只能获取分配到本作业实例的分片项集合。

---------------------

## Elastic job 的相关介绍（引用）
#### Elastic-Job主要功能
- 定时任务： 基于成熟的定时任务作业框架Quartz cron表达式执行定时任务。
- 作业注册中心： 基于Zookeeper和其客户端Curator实现的全局作业注册控制中心。用于注册，控制和协调分布式作业执行。
- 作业分片： 将一个任务分片成为多个小任务项在多服务器上同时执行。
- 弹性扩容缩容： 运行中的作业服务器崩溃，或新增加n台作业服务器，作业框架将在下次作业执行前重新分片，不影响当前作业执行。
- 支持多种作业执行模式： 支持OneOff，Perpetual和SequencePerpetual三种作业模式。
- 失效转移： 运行中的作业服务器崩溃不会导致重新分片，只会在下次作业启动时分片。启用失效转移功能可以在本次作业执行过程中，监测其他作业服务器空闲，抓取未完成的孤儿分片项执行。
- 运行时状态收集： 监控作业运行时状态，统计最近一段时间处理的数据成功和失败数量，记录作业上次运行开始时间，结束时间和下次运行时间。
- 作业停止，恢复和禁用：用于操作作业启停，并可以禁止某作业运行（上线时常用）。
- 被错过执行的作业重触发：自动记录错过执行的作业，并在上次作业完成后自动触发。可参考Quartz的misfire。
- 多线程快速处理数据：使用多线程处理抓取到的数据，提升吞吐量。
- 幂等性：重复作业任务项判定，不重复执行已运行的作业任务项。由于开启幂等性需要监听作业运行状态，对瞬时反复运行的作业对性能有较大影响。
- 容错处理：作业服务器与Zookeeper服务器通信失败则立即停止作业运行，防止作业注册中心将失效的分片分项配给其他作业服务器，而当前作业服务器仍在执行任务，导致重复执行。
- spring支持：支持spring容器，自定义命名空间，支持占位符。
- 运维平台：提供运维界面，可以管理作业和注册中心。
#### 使用限制
- 作业一旦启动成功后不能修改作业名称，如果修改名称则视为新的作业。
- 同一台作业服务器只能运行一个相同的作业实例，因为作业运行时是按照IP注册和管理的。
- 作业根据/etc/hosts文件获取IP地址，如果获取的IP地址是127.0.0.1而非真实IP地址，应正确配置此文件。
- 一旦有服务器波动，或者修改分片项，将会触发重新分片；触发重新分片将会导致运行中的Perpetual以及SequencePerpetual作业再执行完本次作业后不再继续执行，等待分片结束后再恢复正常。
- 开启monitorExecution才能实现分布式作业幂等性（即不会在多个作业服务器运行同一个分片）的功能，但monitorExecution对短时间内执行的作业（如每5秒一触发）性能影响较大，建议关闭并自行实现幂等性。
- elastic-job没有自动删除作业服务器的功能，因为无法区分是服务器崩溃还是正常下线。所以如果要下线服务器，需要手工删除zookeeper中相关的服务器节点。由于直接删除服务器节点风险较大，暂时不考虑在运维平台增加此功能

#### 实现原理  
1. 弹性分布式实现
2. 第一台服务器上线触发主服务器选举。主服务器一旦下线，则重新触发选举，选举过程中阻塞，只有主服务器选举完成，才会执行其他任务。
3. 某作业服务器上线时会自动将服务器信息注册到注册中心，下线时会自动更新服务器状态。
4. 主节点选举，服务器上下线，分片总数变更均更新重新分片标记。
5. 定时任务触发时，如需重新分片，则通过主服务器分片，分片过程中阻塞，分片结束后才可执行任务。如分片过程中主服务器下线，则先选举主服务器，再分片。
6. 通过4可知，为了维持作业运行时的稳定性，运行过程中只会标记分片状态，不会重新分片。分片仅可能发生在下次任务触发前。
7. 每次分片都会按服务器IP排序，保证分片结果不会产生较大波动。
8. 实现失效转移功能，在某台服务器执行完毕后主动抓取未分配的分片，并且在某台服务器下线后主动寻找可用的服务器执行任务。  
![时序图](http://static.oschina.net/uploads/space/2015/0914/181007_yQ7b_719192.jpg "时序图")