Elastic-job三种模式（SPRING-实现）

什么是任务调度?

我们可以先思考一下下面业务场景的解决方案：

• 某电商系统需要在每天上午10点，下午3点，晚上8点发放一批优惠券。
• 某银行系统需要在信用卡到期还款日的前三天进行短信提醒。
• 某财务系统需要在每天凌晨0:10结算前一天的财务数据，统计汇总。
• 12306会根据车次的不同，而设置某几个时间点进行分批放票。
• 某网站为了实现天气实时展示，每隔5分钟就去天气服务器获取最新的实时天气信息。

以上场景就是任务调度所需要解决的问题。
任务调度是指系统为了自动完成特定任务，在约定的特定时刻去执行任务的过程。有了任务调度即可解放更多的人 力由系统自动去执行任务。

什么是分布式任务调度?

什么是分布式？
当前软件的架构正在逐步转变为分布式架构，将单体结构分为若干服务，服务之间通过网络交互来完成用户的业务 处理，如下图，电商系统为分布式架构，由订单服务、商品服务、用户服务等组成：

分布式系统具体如下基本特点：
1、分布性：每个部分都可以独立部署，服务之间交互通过网络进行通信，比如：订单服务、商品服务。
2、伸缩性：每个部分都可以集群方式部署，并可针对部分结点进行硬件及软件扩容，具有一定的伸缩能力。
3、高可用：每个部分都可以集群部分，保证高可用。
什么是分布式调度？
通常任务调度的程序是集成在应用中的，比如：优惠卷服务中包括了定时发放优惠卷的的调度程序，结算服务中包 括了定期生成报表的任务调度程序，由于采用分布式架构，一个服务往往会部署多个冗余实例来运行我们的业务， 在这种分布式系统环境下运行任务调度，我们称之为分布式任务调度，如下图：

不管是任务调度程序集成在应用程序中，还是单独构建的任务调度系统，如果采用分布式调度任务的方式就相当于 将任务调度程序分布式构建，这样就可以具有分布式系统的特点，并且提高任务的调度处理能力：
1、并行任务调度

并行任务调度实现靠多线程，如果有大量任务需要调度，此时光靠多线程就会有瓶颈了，因为一台计算机CPU的处 理能力是有限的。
如果将任务调度程序分布式部署，每个结点还可以部署为集群，这样就可以让多台计算机共同去完成任务调度，我
们可以将任务分割为若干个分片，由不同的实例并行执行，来提高任务调度的处理效率。

2、高可用

若某一个实例宕机，不影响其他实例来执行任务。

3、弹性扩容

当集群中增加实例就可以提高并执行任务的处理效率。

4、任务管理与监测

对系统中存在的所有定时任务进行统一的管理及监测。让开发人员及运维人员能够时刻了解任务执行情况，从而做 出快速的应急处理响应。

5、避免任务重复执行

当任务调度以集群方式部署，同一个任务调度可能会执行多次，比如在上面提到的电商系统中到点发优惠券的例子，就会发放多次优惠券，对公司造成很多损失，所以我们需要控制相同的任务在多个运行实例上只执行一次，考 虑采用下边的方法：
分布式锁，多个实例在任务执行前首先需要获取锁，如果获取失败那么久证明有其他服务已经再运行，如果获取成功那么证明没有服务在运行定时任务，那么就可以执行。

ZooKeeper选举，利用ZooKeeper对Leader实例执行定时任务，有其他业务已经使用了ZK，那么执行定时任 务的时候判断自己是否是Leader，如果不是则不执行，如果是则执行业务逻辑，这样也能达到我们的目的。

Elastic-Job介绍

针对分布式任务调度的需求市场上出现了很多的产品：

1）Elastic-job：当当网基于quartz
二次开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片。

2）Saturn：
唯品会开源的一个分布式任务调度平台，可以全域统一配置，统一监控，任务高可用以及分片并发处理。它是在elastic-job基础之上改良出来的。

3）xl-job：大众点评的分布式任务调度平台，是一个轻量级分布式任务调度平台,其核心设计目标是开发迅速、学
习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线,开箱即用。

4）TBSchedule：淘宝的一款非常优秀的高性能分布式调度框架，目前被应用于阿里、京东、支付宝、国美等很多
互联网企业的流程调度系统中。

Elastic-Job是一个分布式调度的解决方案，由当当网开源，它由两个相互独立的子项目Elastic-Job-Lite和Elastic- Job-Cloud组成，使用Elastic-Job可以快速实现分布式任务调度。
Elastic-Job的github地址 新的地址由于ELASTIC-JOB被阿帕奇孵化了
功能列表：
分布式调度协调

在分布式环境中，任务能够按指定的调度策略执行，并且能够避免同一任务多实例重复执行。

丰富的调度策略：

基于成熟的定时任务作业框架Quartz cron表达式执行定时任务。

弹性扩容缩容

当集群中增加某一个实例，它应当也能够被选举并执行任务；当集群减少一个实例时，它所执行的任务能被 转移到别的实例来执行。

失效转移

某实例在任务执行失败后，会被转移到其他实例执行。

错过执行作业重触发

若因某种原因导致作业错过执行，自动记录错过执行的作业，并在上次作业完成后自动触发。

支持并行调度

支持任务分片，任务分片是指将一个任务分为多个小任务项在多个实例同时执行。

作业分片一致性

当任务被分片后，保证同一分片在分布式环境中仅一个执行实例。

支持作业生命周期操作

可以动态对任务进行开启及停止操作。

丰富的作业类型

支持Simple、DataFlow、Script三种作业类型，后续会有详细介绍。

Spring整合以及命名空间支持

对Spring支持良好的整合方式，支持spring自定义命名空间，支持占位符。

运维平台

提供运维界面，可以管理作业和注册中心。
2Elastic-Job快速入门

2.1环境搭建
2.1.1.版本要求
JDK要求1.7及以上版本Maven要求3.0.4及以上版本
zookeeper要求采用3.4.6及以上版本
2.1.2.Zookeeper安装&运行
https://archive.apache.org/dist/zookeeper/ 下载某版本Zookeeper，并解压。执行解压目录下的bin/zkServer.cmd。
关于Zookeeper后续章节会有介绍。
2.1.3.创建maven工程
创建maven工程elastic-job-quickstart，并导入以下依赖：

<dependency>
<groupId>com.dangdang</groupId>
<artifactId>elastic‐job‐lite‐core</artifactId>
<version>2.1.5</version>
</dependency>

代码实现
编写定时任务类
demo

@Slf4j
public class MySimpleJob implements SimpleJob {
    @Override
    public void execute(ShardingContext shardingContext) {
        log.info("我是分片项："+shardingContext.getShardingItem());
    }
}

spring-config.xml

<?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 server-lists="localhost:2181" base-sleep-time-milliseconds="" namespace="spring-elasticjob" id="zkCenter"/>

    <!--simple作业配置-->
   <job:simple id="mySimpleJob" registry-center-ref="zkCenter" cron="0/10 * * * * ?" sharding-total-count="2"
               class="com.example.job.MySimpleJob" overwrite="true"/>

</beans>

引入tomcat MAVEN插件依赖

 <build>
    <plugins>
      <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <version>2.2</version>
        <executions>
          <execution>
            <id>tomcat-run</id>
            <goals>
              <goal>exec-war-only</goal>
            </goals>
            <phase>package</phase>
            <configuration>
              <path>/</path>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

1）多实例部署时避免任务重复执行，在任务执行时间到来时，从所有实例中选举出来一个，让它来执行任务，从 而避免多个实例同时执行任务。
2）高可用，若某一个实例宕机，不影响其他实例来执行任务。
3）弹性扩容，当集群中增加某一个实例，它应当也能够被选举并执行任务，如果作业分片将参与执行某个分片作 业。
Elastic-Job工作原理
Elastic-Job整体架构

App：

应用程序，内部包含任务执行业务逻辑和Elastic-Job-Lite组件，其中执行任务需要实现ElasticJob接口完成与Elastic-Job-Lite组件的集成，并进行任务的相关配置。应用程序可启动多个实例，也就出现了多个任务执行实
例。

Elastic-Job-Lite：

Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务，此组件负责任务的调度，并产生日志及任务调度记录。 无中心化，是指没有调度中心这一概念，每个运行在集群中的作业服务器都是对等的，各个作业节点是自治的、平
等的、节点之间通过注册中心进行分布式协调。

Registry：

以Zookeeper作为Elastic-Job的注册中心组件，存储了执行任务的相关信息。同时，Elastic-Job利用该组件进行执行任务实例的选举。

Console：

Elastic-Job提供了运维平台，它通过读取Zookeeper数据展现任务执行状态，或更新Zookeeper数据修改全局配置。通过Elastic-Job-Lite组件产生的数据来查看任务执行历史记录。

应用程序在启动时，在其内嵌的Elastic-Job-Lite组件会向Zookeeper注册该实例的信息，并触发选举（此时可能已经启动了该应用程序的其他实例），从众多实例中选举出一个Leader，让其执行任务。当到达任务执行时间时，
Elastic-Job-Lite组件会调用由应用程序实现的任务业务逻辑，任务执行后会产生任务执行记录。当应用程序的某一个实例宕机时，Zookeeper组件会感知到并重新触发leader选举。

Elastic-Job依赖ZooKeeper完成对执行任务信息的存储(如任务名称、任务参与实例、任务执行策略等)； Elastic-Job依赖ZooKeeper实现选举机制，在任务执行实例数量变化时(如在快速上手中的启动新实例或停止实例)，会触发选举机制来决定让哪个实例去执行该任务。

ZooKeeper是一个分布式一致性协调服务，它是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

咱们可以把ZooKeeper想象为一个特殊的数据库，它维护着一个类似文件系统的树形数据结构，ZooKeeper的客户端（如Elastic-Job任务执行实例）可以对数据进行存取：

每个子目录项如 /app1都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

ZooKeeper为什么称之为一致性协调服务呢？因为ZooKeeper拥有数据监听通知机制，客户端注册监听它关心的znode，当znode发生变化（数据改变、被删除、子目录节点增加删除）时，ZooKeeper会通知所有客户端。简单

来说就是，当分布式系统的若干个服务都关心一个数据时，当这个数据发生改变，这些服务都能够得知，那么这些 服务就针对此数据达成了一致。

应用场景思考，使用ZooKeeper管理分布式配置项的机制：

假设我们的程序是分布式部署在多台机器上，如果我们要改变程序的配置文件，需要逐台机器去修改，非常麻烦，
现在把这些配置全部放到zookeeper上去，保存在 zookeeper
的某个目录节点中，然后所有相关应用程序作为ZooKeeper的客户端对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到
ZooKeeper的通知，从而获取新的配置信息应用到系统中。

Elastic-Job任务信息的保存
Elastic-Job使用ZooKeeper完成对任务信息的存取，任务执行实例作为ZooKeeper客户端对其znode操作，任务信息保存在znode中。使用ZooInspector查看zookeeper节点

1 、 zookeeper 图 像 化 客 户 端 工 具 的 下 载 地 址 ： https://issues.apache.org/jira/secure/attachment/12436620/ZooInspector.zip；
2、下载完后解压压缩包，双击地址为ZooInspector\build\zookeeper-dev-ZooInspector.jar的jar包； 如果双击没有反应？首先电脑要配好java环境，使用java -jar 再加上你的jar文件的路径 启动即可.

config节点内容如下：

{
"jobName": "files‐job",
"jobClass": "com.itheima.scheduling.job.FileBackupJob", "jobType": "SIMPLE",
"cron": "0/3 * * * * ?", "shardingTotalCount": 1, "shardingItemParameters": "", "jobParameter": "", "failover": true,
"misfire": true, "description": "", "jobProperties": {
"job_exception_handler": "com.dangdang.ddframe.job.executor.handler.impl.DefaultJobExceptionHandler",
"executor_service_handler": "com.dangdang.ddframe.job.executor.handler.impl.DefaultExecutorServiceHandler"
},
"monitorExecution": true, "maxTimeDiffSeconds": ‐1, "monitorPort": ‐1, "jobShardingStrategyClass": "", "reconcileIntervalMinutes": 10, "disabled": false,
"overwrite": false
}

节点记录了任务的配置信息，包含执行类，cron表达式，分片算法类，分片数量，分片参数。默认状态下，如果你修改了Job的配置比如cron表达式，分片数量等是不会更新到zookeeper上去的，需要把LiteJobConfiguration的参数overwrite修改成true，或者删除zk的结点再启动作业重新创建。

instances节点：

同一个Job下的elastic-job的部署实例。一台机器上可以启动多个Job实例，也就是Jar包。instances的命名是
[IP+@-@+PID]。

leader节点：

任务实例的主节点信息，通过zookeeper的主节点选举，选出来的主节点信息。下面的子节点分为election，sharding和failover三个子节点。分别用于主节点选举，分片和失效转移处理。election下面的instance
节点显式了当前主节点的实例ID：jobInstanceId。latch节点也是一个永久节点用于选举时候的实现分布式锁。sharding节点下面有一个临时节点necessary，是否需要重新分片的标记，如果分片总数变化或任务实例节点上下线，以及主节点选举，都会触发设置重分片标记，主节点会进行分片计算。

sharding节点：

任务的分片信息，子节点是分片项序号，从零开始，至分片总数减一。从这个节点可以看出哪个 分片在哪个实例上运行

Elastic-Job任务执行实例选举

Elastic-Job使用ZooKeeper实现任务执行实例选举，若要使用ZooKeeper完成选举，就需要了解ZooKeeper的 znode类型了，ZooKeeper有四种类型的znode，客户端在创建znode时可以指定：
PERSISTENT-持久化目录节点

客户端创建该类型znode，此客户端与ZooKeeper断开连接后该节点依旧存在，如果创建了重复的key，比 如/data，第二次创建会失败。

PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

客户端与ZooKeeper断开连接后该节点依旧存在，允许重复创建相同key，Zookeeper给该节点名称进行顺序
编号，如zk会在后面加一串数字比如 /data/data0000000001，如果重复创建，会创建一
个/data/data0000000002节点（一直往后加1）

EPHEMERAL-临时目录节点

客户端与ZooKeeper断开连接后，该节点被删除，不允许重复创建相同key。

EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与ZooKeeper断开连接后，该节点被删除，允许重复创建相同key，依然采取顺序编号机制。 实例选举实现过程分析：

每个Elastic-Job的任务执行实例作为ZooKeeper的客户端来操作ZooKeeper的znode
1）任意一个实例启动时首先创建一个 /server 的PERSISTENT节点
2）多个实例同时创建 /server/leader EPHEMERAL子节点
3） /server/leader子节点只能创建一个，后创建的会失败。创建成功的实例被选为leader节点，用来执行任务。 4）所有任务实例监听 /server/leader 的变化，一旦节点被删除，就重新进行选举，抢占式地创建
/server/leader节点，谁创建成功谁就是leader。

对于应用程序，只需要将任务执行细节包装为ElasticJob接口的实现类并对任务细节进行配置即可完成与Elastic- Job的集成，而Elastic-Job需要依赖Zookeeper进行执行任务信息的存取，执行任务实例的选举。通过对快速入门程序的测试，我们可以看到Elastic-Job确实解决了分布式任务调度的核心问题。

作业分片
分片概念
作业分片是指任务的分布式执行，需要将一个任务拆分为多个独立的任务项，然后由分布式的应用实例分别执行某 一个或几个分片项。
例如：Elastic-Job快速入门中文件备份的例子，现有2台服务器，每台服务器分别跑一个应用实例。为了快速的执行作业，那么可以将作业分成4片，每个应用实例个执行2片。作业遍历数据的逻辑应为：实例1查找text和image 类型文件执行备份；实例2查找radio和video类型文件执行备份。 如果由于服务器扩容应用实例数量增加为4，则作业遍历数据的逻辑应为：4个实例分别处理text、image、radio、video类型的文件。
可以看到，通过对任务合理的分片化，从而达到任务并行处理的效果，最大限度的提高执行作业的吞吐量。 分片项与业务处理解耦
Elastic-Job并不直接提供数据处理的功能，框架只会将分片项分配至各个运行中的作业服务器，开发者需要自行处理分片项与真实数据的对应关系。
最大限度利用资源
将分片项设置为大于服务器的数量，最好是大于服务器倍数的数量，作业将会合理的利用分布式资源，动态的分配 分片项。
例如：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。在不丢失分片项的情况下，最大限度的利用现 有资源提高吞吐量。

作业配置说明
注册中心配置
ZookeeperConfiguration属性详细说明

作业配置
作业配置分为3级，分别是JobCoreConfiguration，JobTypeConfiguration和LiteJobConfiguration。 LiteJobConfiguration使用JobTypeConfiguration，JobTypeConfiguration使用JobCoreConfiguration，层层嵌套。 JobTypeConfiguration根据不同实现类型分为SimpleJobConfiguration，DataflowJobConfiguration和 ScriptJobConfiguration。

作业分片策略
AverageAllocationJobShardingStrategy
全路径：
com.dangdang.ddframe.job.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
全路径：
com.dangdang.ddframe.job.lite.api.strategy.impl.OdevitySortByNameJobShardingStrategy
策略说明：
根据作业名的哈希值奇偶数决定IP升降序算法的分片策略。作业名的哈希值为奇数则IP升序。
作业名的哈希值为偶数则IP降序。
用于不同的作业平均分配负载至不同的服务器。
AverageAllocationJobShardingStrategy的缺点是，一旦分片数小于作业服务器数，作业将永远分配至IP地址靠前的服务器，导致IP地址靠后的服务器空闲。而OdevitySortByNameJobShardingStrategy则可以根据作业名称重新分配服务器负载。如：
如果有3台服务器，分成2片，作业名称的哈希值为奇数，则每台服务器分到的分片是：1=[0], 2=[1], 3=[]
如果有3台服务器，分成2片，作业名称的哈希值为偶数，则每台服务器分到的分片是：3=[0], 2=[1], 1=[]
RotateServerByNameJobShardingStrategy
全路径：
com.dangdang.ddframe.job.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy
策略说明：
根据作业名的哈希值对服务器列表进行轮转的分片策略。配置分片策略
与配置通常的作业属性相同，在spring命名空间或者JobConfiguration中配置jobShardingStrategyClass属性，属性值是作业分片策略类的全路径。

分片策略配置xml方式：

<job:simple id="hotelSimpleSpringJob" class="com.chuanzhi.spiderhotel.job.SpiderJob" registry‐ center‐ref="regCenter" cron="0/10 * * * * ?" sharding‐total‐count="4" sharding‐item‐ parameters="0=A,1=B,2=C,3=D" monitor‐port="9888" reconcile‐interval‐minutes="10" job‐sharding‐ strategy‐ class="com.dangdang.ddframe.job.lite.api.strategy.impl.RotateServerByNameJobShardingStrategy"/>

Elastic-Job高级

事件追踪
Elastic-Job-Lite在配置中提供了JobEventConfiguration，支持数据库方式配置，会在数据库中自动创建 JOB_EXECUTION_LOG和JOB_STATUS_TRACE_LOG两张表以及若干索引，来记录作业的相关信息。

<?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
">
    <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource">
        <property name="username" value="root"/>
        <property name="password" value="123456"/>
        <property name="url" value="jdbc:mysql://localhost:3306/dataflow?serverTimezone=Asia/Shanghai&amp;useSSL=false"/>
    </bean>



    <!--注册中心配置-->
    <reg:zookeeper server-lists="localhost:2181" base-sleep-time-milliseconds="" namespace="spring-elasticjob" id="zkCenter"/>

    <!--Dataflow作业-->
    <job:dataflow registry-center-ref="zkCenter" cron="0/10 * * * * ?" sharding-total-count="2" id="myDataflowJob"
                  class="com.example.job.MyDataflowJob" event-trace-rdb-data-source="dataSource"  overwrite="true" streaming-process="true" >
        <job:listener class=""/>
        <job:distributed-listener class="" started-timeout-milliseconds="" completed-timeout-milliseconds=""/>
        
    </job:dataflow>
</beans>

JOB_EXECUTION_LOG记录每次作业的执行历史。分为两个步骤：
1.作业开始执行时向数据库插入数据，除failure_cause和complete_time外的其他字段均不为空。
2.作业完成执行时向数据库更新数据，更新is_success, complete_time和failure_cause(如果作业执行失败)。
JOB_STATUS_TRACE_LOG记录作业状态变更痕迹表。可通过每次作业运行的task_id查询作业状态变化的生命周期 和运行轨迹。

运维

elastic-job中提供了一个elastic-job-lite-console控制台设计理念
1.本控制台和Elastic Job并无直接关系，是通过读取Elastic Job的注册中心数据展现作业状态，或更新注册中心数据修改全局配置。
2.控制台只能控制作业本身是否运行，但不能控制作业进程的启停，因为控制台和作业本身服务器是完全分布 式的，控制台并不能控制作业服务器。
主要功能
1.查看作业以及服务器状态
2.快捷的修改以及删除作业设置
3.启用和禁用作业

4.跨注册中心查看作业
5.查看作业运行轨迹和运行状态
不支持项

1. 添加作业。因为作业都是在首次运行时自动添加，使用控制台添加作业并无必要。直接在作业服务器启动包含Elastic Job的作业进程即可
   具体搭建步骤如下：
   解压缩 。
   进入 bin目录 并执行：
   Elastic-job-lite- console-2.1.4.tar.gz

bin\start.sh

打开浏览器访问。
即可访问控制台。8899为默认端口号，可通过启动脚本输入-p自定义端
输入用户名 root 密码 root 即可打开主界面 如下图提供两种账户，管理员及访客，管理员拥有全部操作权限，访客仅拥有察看权限。默认管理员用户名和密码是
root/root，访客用户名和密码是guest/guest，可通过conf\auth.properties修改管理员及访客用户名及密码。

配置及使用
1、 配置注册中心地址
先启动zookeeper 然后在注册中心配置界面 点添加


连接成功后，在作业维度下可以显示该命名空间下作业名称、分片数量及该作业的cron表达式等信息 在服务器维度可以查看服务器ip、当前运行的实例数、作业总数等信息。

2、配置事件追踪数据源
在事件追踪数据源配置页面点添加按钮，输入相关信息
4.3dump命令
使用Elastic-Job-Lite过程中可能会碰到一些问题，导致作业运行不稳定。由于无法在生产环境调试，通过dump命令可以把作业内部相关信息dump出来，方便开发者debug分析。
（1）开启dump监控端口，并运行程序
修改中ElasticJobConfig中的createJobConfiguration方法里JobRootConfiguration的配置，开启dump监控端口：

JobRootConfiguration simpleJobRootConfig = LiteJobConfiguration.newBuilder(simpleJobConfig)
.monitorPort(9888)//设置dump端口
.build();

（2）windows中安装netcat（若操作系统中已经有nc命令，此步骤可略过）
tools文件夹内包含netcat-win32-1.12.zip，解压即可。
（3）执行dump命令
打开命令行工具，进入netcat-win32-1.12.zip的解压目录，执行以下命令：

echo dump| nc 127.0.0.1 9888 > job_debug_dump.txt

会在当前目录生成job_debug_dump.txt文件，打开job_debug_dump.txt后看到：里面展示的其实就是FileBackupJob任务在Zookeeper中的信息。