什么是elastic-job（持续更新）

Elastic-Job是当当基于Zookepper，Quartz开发并且开源的Java分布式定时任务

为什么要是用elastic-job举个典型的job场景

比如余额宝里的昨日收益，系统需要job在每天某个时间点开始，给所有余额宝用户计算收益。如果用户数量不多，我们可以轻易使用quartz来完成，我们让计息job在某个时间点开始执行，循环遍历所有用户计算利息，这没问题。可是，如果用户体量特别大，我们可能会面临着在第二天之前处理不完这么多用户。另外，我们部署job的时候也得注意，我们可能会把job直接放在我们的webapp里，webapp通常是多节点部署的，这样，我们的job也就是多节点，多个job同时执行，很容易造成重复执行，比如用户重复计息，为了避免这种情况，我们可能会对job的执行加锁，保证始终只有一个节点能执行，或者干脆让job从webapp里剥离出来，独自部署一个节点。
elastic-job就可以帮助我们解决上面的问题，elastic底层的任务调度还是使用的quartz，通过zookeeper来动态给job节点分片。

采用elastic-job+数据库+zk(可以用其他注册服务替换) 动态处理定时任务，由于elastic-job是通过向zk获取任务信息，所有任务动态处理是通过监听zk和操作zk来保证数据库的任务数据一致

1. elastic-job提供了三种类型的作业：Simple类型作业（继承的execute方法内做任务处理）、Dataflow类型作业（继承的fetchData做数据获取处理先执行，继承的processData做任务处理后执行，二者执行完表示任务完成）、Script类型作业（通过脚本执行）； 采用的是一个任务对于一个类，暂不支持自定义任务方法，如有需要得使用委托处理

2. 多服务部署，elastic-job的服务器纬度是根据ip地址来判断的，一个ip下如果部署两个任务服务，则只有一条纬度记录，但是有两个实例

3. 任务分片原则：

   当任务的分片总数=1时（必须大于0），如果部定时任务工程部署在多个服务器上，则任务将会以1主N从的方式执行。一旦本次执行任务的服务器崩溃，其他执行任务的服务器将会在下次作业启动时选择一个替补执行。如果开启了失效转移，那么功能效果更好，可以保证在本次作业执行时崩溃，备机之一立即启动替补执行。

   当任务分片总数大于1时，如果定时任务工程部署在多个服务器上，则任务根据分片策略去执行（可以通过策略项输入规则，支持三种，也可以通过实现JobShardingStrategy接口自定义分片策略规则），默认是平均分配（并行在各自的服务器上执行任务调度）。

   elastic-job只支持任务分片不支持数据分片，数据分片的实现需要开发人员自行根据分片下标和分片总数以及分片规则来处理，即如果任务分片中数据是查询所有的数据，则根据分片下标和分片总数和分片规则来计算各个分片下获取的数据；如：分片总数大1，有多台任务服务器执行同一个任务，分片规则为平均分配，采用分页获取数据