一、简介
Elastic-job是一个分布式调度解决方案，由2个相互独立的子项目Elastic-job-Lite和Elastic-Job-cloud组成；
Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务；Elastic-Job-Cloud采用当当网自研Mesos Framework的解决方案，额外提供资源治理，应用分发以及进程隔离等功能；
官方开源资料：https://github.com/dangdangdotcom/elastic-job
二、基本概念
我们开发定时任务一般都是使用quartz或者spring-task（ScheduledExecutorService），无论是使用quartz还是spring-task，我们都会至少遇到两个痛点：
1.不敢轻易跟着应用服务多节点部署，可能会重复多次执行而引发系统逻辑的错误。
2.quartz的集群仅仅只是用来单机锁表防止重复多次执行，节点数量的增加并不能给我们的每次执行效率带来提升，即不能实现水平扩展。
Elastic-Job主要的设计理念是无中心化的分布式定时调度框架，思路来源于Quartz的基于数据库的高可用方案。但数据库没有分布式协调功能，所以在高可用方案的基础上增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。
三、Elastic-Job-Lite原理
Elastic-Job在2.x之后，出了两个产品线：Elastic-Job-Lite和Elastic-Job-Cloud。我们一般使用Elastic-Job-Lite就能够满足需求，本文也是以Elastic-Job-Lite为主。1.x系列对应的就只有Elastic-Job-Lite，并且在2.x里修改了一些核心类名，差别虽大，原理类似，建议使用2.x系列
举个典型的job场景，比如余额宝里的昨日收益，系统需要job在每天某个时间点开始，给所有余额宝用户计算收益。如果用户数量不多，我们可以轻易使用quartz来完成，我们让计息job在某个时间点开始执行，循环遍历所有用户计算利息，这没问题。可是，如果用户体量特别大，我们可能会面临着在第二天之前处理不完这么多用户。另外，我们部署job的时候也得注意，我们可能会把job直接放在我们的webapp里，webapp通常是多节点部署的，这样，我们的job也就是多节点，多个job同时执行，很容易造成重复执行，比如用户重复计息，为了避免这种情况，我们可能会对job的执行加锁，保证始终只有一个节点能执行，或者干脆让job从webapp里剥离出来，独自部署一个节点。
Elastic-job就可以帮着我们解决上面的问题，Elastic底层的任务调度还是使用了quartz，通过zookkeeper来动态给job节点分片；
我们来看问题点：
1、存在大数据量的用户需要再特定的时间段内完成计息
我们肯定希望我们的任务可以通过集群达到水平扩展，集群里面的每一个节点都处理部分用户，不管用户数量有多大，我们只要增加机器就可以了，比如说单个机器在特定的时间内能处理N个用户的计息，2台机器处理2N个用户，3台3N….,再多的用户也不怕了。
使用elastic-job开发的作业都是zookeeper的客户端，比如我希望3台机器跑job，我们将任务分成3片，框架通过zk的协调，最终会让3台机器分别分配到0,1,2的任务片，比如：
server0–>0，server1–>1，server2–>2，
1、当server0执行时，可以只查询id%30的用户；
2、server1执行时，只查询id%31的用户；
3、server2执行时，只查询id%3==2的用户。
在上面的基础上，我们再增加server3，此时，server3分不到任务分片，因为只有3片，已经分完了。没有分到任务分片的作业程序将不执行。如果此时server2挂了，那么server2的分片项会分配给server3，server3有了分片，就会替代server2执行。如果此时server3也挂了，只剩下server0和server1了，框架也会自动把server3的分片随机分配给server0或者server1，可能会这样，server0–>0，server1–>1,2。这种特性称之为弹性扩容，即elastic-job名称的由来。
四、作业类型
elastic-job提供了三种类型的作业：Simple类型作业、Dataflow类型作业、Script类型作业。这里主要讲解前两者。Script类型作业意为脚本类型作业，支持shell，python，perl等所有类型脚本，使用不多，可以参见github文档。
SimpleJob需要实现SimpleJob接口，意为简单实现，未经过任何封装，与quartz原生接口相似，比如示例代码中所使用的job。
Dataflow类型用于处理数据流，需实现DataflowJob接口。该接口提供2个方法可供覆盖，分别用于抓取(fetchData)和处理(processData)数据。
可通过DataflowJobConfiguration配置是否流式处理。
流式处理数据只有fetchData方法的返回值为null或集合长度为空时，作业才停止抓取，否则作业将一直运行下去； 非流式处理数据则只会在每次作业执行过程中执行一次fetchData方法和processData方法，随即完成本次作业。
实际开发中，Dataflow类型的job还是很有好用的。
五、分片策略
AverageAllocationJobShardingStrategy
全路径：
io.elasticjob.lite.api.strategy.impl.AverageAllocationJobShardingStrategy
策略说明：
基于平均分配算法的分片策略，也是默认的分片策略。
如果分片不能整除，则不能整除的多余分片将依次追加到序号小的服务器。如：
如果有3台服务器，分成9片，则每台服务器分到的分片是：1=[0,1,2], 2=[3,4,5], 3=[6,7,8]
如果有3台服务器，分成8片，则每台服务器分到的分片是：1=[0,1,6], 2=[2,3,7], 3=[4,5]
如果有3台服务器，分成10片，则每台服务器分到的分片是：1=[0,1,2,9], 2=[3,4,5], 3=[6,7,8]
OdevitySortByNameJobShardingStrategy
全路径：
io.elasticjob.lite.api.strategy.impl.OdevitySortByNameJobShardingStrategy
策略说明：
根据作业名的哈希值奇偶数决定IP升降序算法的分片策略。
作业名的哈希值为奇数则IP升序。
作业名的哈希值为偶数则IP降序。
用于不同的作业平均分配负载至不同的服务器。
RotateServerByNameJobShardingStrategy
全路径：
io.elasticjob.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy
策略说明：
根据作业名的哈希值对服务器列表进行轮转的分片策略。
六、代码示例
1、引入maven依赖
<dependency>
<groupId>com.dangdang</groupId>
<artifactId>elastic-job-lite-core</artifactId>
<version>2.0.5</version>
</dependency>
<!-- 使用springframework自定义命名空间时引入 -->
<dependency>
<groupId>com.dangdang</groupId>
<artifactId>elastic-job-lite-spring</artifactId>
<version>2.0.5</version>
</dependency>
2、Simple作业开发
意为简单实现，未经任何封装的类型。需实现SimpleJob接口。该接口仅提供单一方法用于覆盖，此方法将定时执行。与Quartz原生接口相似，但提供了弹性扩缩容和分片等功能。
public class MySimpleJob implements SimpleJob {
@Override
public void execute(ShardingContext shardingContext) {
int shardIndx = shardingContext.getShardingItem();
if (shardIndx == 0) {
//处理id为奇数的商家
System.out.println(String.format("------Thread ID: %s, Total number of task slices: %s, current fragmentation items: %s",
Thread.currentThread().getId(), shardingContext.getShardingTotalCount(), shardingContext.getShardingItem()));
} else {
//处理id为偶数的商家
System.out.println(String.format("------Thread ID: %s, Total number of task slices: %s, current fragmentation items: %s",
Thread.currentThread().getId(), shardingContext.getShardingTotalCount(), shardingContext.getShardingItem()));
}
/**
* 实际开发中，有了任务总片数和当前分片项，就可以对任务进行分片执行了
* 比如 SELECT * FROM user WHERE status = 0 AND MOD(id, shardingTotalCount) = shardingItem
*/
}
}
3、作业配置
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:reg="http://www.dangdang.com/schema/ddframe/reg"
xmlns:job="http://www.dangdang.com/schema/ddframe/job"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.dangdang.com/schema/ddframe/reg
http://www.dangdang.com/schema/ddframe/reg/reg.xsd
http://www.dangdang.com/schema/ddframe/job
http://www.dangdang.com/schema/ddframe/job/job.xsd">
<!--配置作业注册中心 -->
<reg:zookeeper id="regCenter" server-lists="172.16.150.247:2181" namespace="dd-job"
base-sleep-time-milliseconds="1000" max-sleep-time-milliseconds="3000" max-retries="3"/>
<!-- 配置作业-->
<job:simple id="mySimpleJob" class="com.liuxl.elastic.MySimpleJob" registry-center-ref="regCenter"
sharding-total-count="2" cron="0/2 * * * * ?" overwrite="true"/>
<!--failover:是否开启任务执行失效转移，开启表示如果作业在一次任务执行中途宕机，允许将该次未完成的任务在另一作业节点上补偿执行
description:作业描述
overwrite：本地配置是否可覆盖注册中心配置，如果可覆盖，每次启动作业都以本地配置为准
event-trace-rdb-data-source：作业事件追踪的数据源Bean引用
—>
</beans>
4、单机运行
本机运行
5、集群运行
本机运行、132机器
6、Dataflow作业开发
public class MyElasticJob implements DataflowJob<List> {
@Override
public List<List<Object>> fetchData(ShardingContext shardingContext) {
int shardIndx = shardingContext.getShardingItem();
File file = new File("/Users/liuxl/Desktop/worker/wsd/20181012.xlsx");
List<List<Object>> reslut = new ArrayList<>();
try {
List<ExcelSheetPO> pos = ExcelUtil.readExcel(file, 400, 3);
if (shardIndx == 0) {
List<List<Object>> list = pos.get(0).getDataList();
//不要id
for (List<Object> objects : list) {
objects.remove(1);
}
reslut = list;
} else {
List<List<Object>> list = pos.get(0).getDataList();
// 不要名字
for (List<Object> objects : list) {
objects.remove(0);
}
reslut = list;
}
} catch (IOException e) {
e.printStackTrace();
}
return reslut;
}
@Override
public void processData(ShardingContext shardingContext, List<List<Object>> list) {
List<Object> objects = list.get(0);
System.out.println(
String.format("------Thread ID: %s, Total number of task slices: %s, current fragmentation items: %s,content : %s", Thread.currentThread().getId(), shardingContext.getShardingTotalCount(), shardingContext.getShardingItem(), JSONObject.toJSON(objects)
));
}
}
7、作业配置
<job:dataflow id="myDataFlowJob" class="com.liuxl.elastic.MyElasticJob" registry-center-ref=“regCenter" sharding-total-count="2" cron="0/2 * * * * ?" streaming-process="true" overwrite=“true" job-exceptionhandler=“com.liuxl.elastic.exception.MyJobExceptionHandler"/>
七、任务日志捕捉
elastic-job允许用户在任务调度异常时指定处理异常的异常处理器，异常处理器由接口JobExceptionHandler定义，定义如下
public interface JobExceptionHandler {
void handleException(String var1, Throwable var2);
}
如果没有指定自己的异常处理器elastic-job默认将使用DefaultJobExceptionHandler处理异常，其定义如下：
public final class DefaultJobExceptionHandler implements JobExceptionHandler {
private static final Logger log = LoggerFactory.getLogger(DefaultJobExceptionHandler.class);
public DefaultJobExceptionHandler() {
}
public void handleException(String jobName, Throwable cause) {
log.error(String.format("Job '%s' exception occur in job processing", jobName), cause);
}
}
以下是一个自定义的异常处理器的示例：
public class MyJobExceptionHandler implements JobExceptionHandler {
private static final Logger logger = Logger.getLogger(MyJobExceptionHandler.class);
@Override
public void handleException(String jobName, Throwable cause) {
logger.error(String.format("任务[%s]调度异常", jobName), cause);
}
}
异常处理器的配置是通过job-exception-handler属性指定的，所有作业类型的异常处理器的配置是通用的：
<job:dataflow id="myDataFlowJob" class="com.liuxl.elastic.MyElasticJob" registry-center-ref="regCenter"
sharding-total-count="2" cron="0/2 * * * * ?" streaming-process="true" overwrite="true"
job-exception-handler="com.liuxl.elastic.exception.MyJobExceptionHandler"/>
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
