Elastic Job 分布式任务调度
1. Elastic Job1.1前言
我们开发定时任务一般都是使用quartz或者spring-task，无论是使用quartz还是spring-task，我们至少会遇到以下两个痛点：
l 不敢轻易跟着应用服务器多节点部署，可能会重复多次执行而引发系统逻辑的错误。
l quartz的集群仅仅只是用来HA，节点数量的增加并不能给我们的每次执行效率带来提升，即不能实现水平扩展。
说明：Elastic-job分布式任务调度，就可以帮我们解决上面两个痛点。
1.2介绍
Elastic-Job是当当开源的一款非常好用的分布式任务调度框架，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。Elastic-Job-Lite这也是本次所要讲解和使用的子项目。
主要功能：
l 分布式调度协调
l 弹性扩容缩容
l 失效转移
l 错过执行作业重触发
l 作业分片一致性，保证同一分片在分布式环境中仅一个执行实例
l 自诊断并修复分布式不稳定造成的问题
l 支持并行调度
l 支持作业生命周期操作
l 丰富的作业类型
l Spring整合以及命名空间提供
l 运维平台
官网：http://www.elasticjob.io/
1.3基本概念
n 分片概念
任务的分布式执行，需要将一个任务拆分为多个独立的任务项，然后由分布式的服务器分别执行某一个或几个分片项。
例如：有一个遍历数据库某张表的作业，现有2台服务器。为了快速的执行作业，那么每台服务器应执行作业的50%。 为满足此需求，可将作业分成2片，每台服务器执行1片。
n 分片项与业务处理解耦
Elastic-Job并不直接提供数据处理的功能，框架只会将分片项分配至各个运行中的作业服务器，开发者需要自行处理分片项与真实数据的对应关系。
n 个性化参数的适用场景
个性化参数即shardingItemParameter，可以和分片项匹配对应关系，用于将分片项的数字转换为更加可读的业务代码。
例如：按照地区水平拆分数据库，数据库A是北京的数据;数据库B是上海的数据;数据库C是广州的数据。 如果仅按照分片项配置，开发者需要了解0表示北京;1表示上海;2表示广州。 合理使用个性化参数可以让代码更可读，如果配置为0=北京,1=上海,2=广州，那么代码中直接使用北京，上海，广州的枚举值即可完成分片项和业务逻辑的对应关系。
n 分布式调度
Elastic-Job-Lite并无作业调度中心节点，而是基于部署作业框架的程序在到达相应时间点时各自触发调度。注册中心仅用于作业注册和监控信息存储。而主作业节点仅用于处理分片和清理等功能。
n 作业高可用
Elastic-Job-Lite提供最安全的方式执行作业。将分片总数设置为1，并使用多于1台的服务器执行作业，作业将会以1主n从的方式执行。
一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。
n 最大限度利用资源
Elastic-Job-Lite也提供最灵活的方式，最大限度的提高执行作业的吞吐量。将分片项设置为大于服务器的数量，最好是大于服务器倍数的数量，作业将会合理的利用分布式资源，动态的分配分片项。
例如：3台服务器，分成10片，则分片项分配结果为服务器A=0,1,2;服务器B=3,4,5;服务器C=6,7,8,9。 如果服务器C崩溃，则分片项分配结果为服务器A=0,1,2,3,4;服务器B=5,6,7,8,9。在不丢失分片项的情况下，最大限度的利用现有资源提高吞吐量。
作业类型说明
Elastic-Job提供Simple、Dataflow和Script 3种作业类型。 方法参数shardingContext包含作业配置、分片和运行时信息。可通过getShardingTotalCount(),getShardingItem()等方法分别获取分片总数，运行在本作业服务器的分片序列号等。
l Simple类型作业
意为简单实现，未经任何封装的类型。需实现SimpleJob接口。该接口仅提供单一方法用于实现，此方法将定时执行。与Quartz原生接口相似，但提供了弹性扩缩容和分片等功能。
l Dataflow类型作业
Dataflow类型用于处理数据流，需实现DataflowJob接口。该接口提供2个方法可供实现，分别用于抓取(fetchData)和处理(processData)数据。
l Script类型作业