elastic-job分布式任务调度

elastic-job是一款分布式任务调度框架，基于zookeeper节点的watch机制进行订阅监听，从而达到任务动态分片sharding和故障恢复failover

基本概念

任务分片

任务分布式的执行，需要将一个任务拆分成多个独立的任务项，然后由分布式的服务器分别执行某一个或几个分片项。
elastic-job只会将任务的分片下标通过分配策略分配到每个节点，并不会提供处理业务代码的能力。所以具体每个分片处理代码需要程序员自己开发。
任务分片优势：可以将任务同时分配到不同的节点去执行，充分利用每个节点的线程资源。这样任务执行速度也会得到提高。

个性化参数：

shardingItemParameter，可以和分片项匹配对应关系。
比如：将商品的状态分成上架，下架。那么配置0=上架,1=下架，
代码中直接使用上架下架的枚举值即可完成分片项与业务逻辑的对应关系

作用高可用：

将分片总数设置成1，多台服务器执行作业将采用1主n从的方式执行

弹性扩容：

将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服器加入集群或有服务器宕机。Elastic-Job将保留本次任务不变，下次任务开始前重新分片。
（注意：如果节点数大于分区数量，则会出现多余节点分配不到分片）

并行调度：

采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。

集中管理：

采用基于zookepper的注册中心，集中管理和协调分布式作业的状态，分配和监听。外部系统可直接根据Zookeeper的数据管理和监控elastic-job。

定制化流程任务：

作业可分为简单和数据流处理两种模式，数据流又分为高吞吐处理模式和顺序性处理模式，其中高吞吐处理模式可以开启足够多的线程快速的处理数据，而顺序性处理模式将每个分片项分配到一个独立线程，用于保证同一分片的顺序性，这点类似于kafka的分区顺序性。

failover故障恢复

即避免单点故障和保证任务的高可用；
某个节点失效，然后会进行任务分片的重新分配(resetSharding), 然后交由其他可用的节点继续执行

任务分片

类似kafka的消息分区和客户端的分配balance、rebalance，可以定义每个任务分片，即将一个任务的处理转化为多个节点同时处理；

 public void execute(ShardingContext context) {
   
   
        String curThreadName = Thread.currentThread().getName();
        switch (context.getShardingItem()) {
   
   
			//代表任务的0分区
			//每个任务的执行execute会利用线程池调用
            case 0:
                System.out.println(curThreadName+"sharding do 0");
                break;
            //代表任务的1分区
            case 1:
                System.out.println(curThreadName+"sharding do 1");
                break;
            case 2:
                System.out.println(curThreadName+"sharding do 2");
                break