elastic-job详解（四）：失效转移

elastic-job中最关键的特性之一就是失效转移。配置了失效转移以后，若是在任务执行过程当中有一个执行实例挂了，那么以前被分配到这个实例的任务（或者分片）会在下次任务执行以前被从新分配到其余正常节点实例上执行。

简单的HA

当某一个任务实例节点宕机（离开与zookeeper的链接），会触发elastic-job主节点的从新分片逻辑。elastic-job启动任务节点之后生成的zookeeper中的instance节点是一个临时节点EPHEMERAL。为何要用EPHEMERAL节点，就是为了能在任务实例出现问题与zookeeper断开之后，能触发zookeeper的节点移除的事件，从而从新调整分区或者运行节点。既然是EPHEMERAL节点，就能够在zookeeper中配置sessionTimeoutMs参数。在使用spring的elastic-job配置中在以下地方配置：

若是在sessionTimeoutMs的时间段以内触发任务，则异常分片的任务会丢失。举个例子：假如sessionTimeoutMs被设置成1分钟，而自己的任务是30秒执行一次，有三个任务实例在三台机器各自执行分片1,2,3。当分片3所在的机器出现问题，和zk断开了，那么zk节点失效至少要到1分钟之后。期间30秒执行一次的任务分片3，至少会少执行一次。1分钟事后，zk节点失效，触发ListenServersChangedJobListener类的dataChanged方法，在这里方法中判断instance节点变化，而后经过方法shardingService.setReshardingFlag设置从新分片标志位，下次执行任务的时候，leader节点从新分配分片，分片3就会转移到其余好的机器上。

 

复杂的失效转移

elastic-job的任务配置有个failover，若是开启设置为true的时候，会启动真正的失效转移：，elastic-job的任务又两个配置failover（默认值为false）和monitorExecution（默认值是true）。只有对monitorExecution为true的状况下才能够开启失效转移。

所谓失效转移，就是在执行任务的过程当中碰见异常的状况，这个分片任务能够在其余节点再次执行。这个和上面的HA不一样，对于HA，上面若是任务终止，那么不会在其余任务实例上再次从新执行。

Job的失效转移监听来源于FailoverListenerManager中JobCrashedJobListener的dataChanged方法。FailoverListenerManager监听的是zk的instance节点删除事件。若是任务配置了failover等于true，其中某个instance与zk失去联系或被删除，而且失效的节点又不是自己，就会触发失效转移逻辑。

首先，在某个任务实例失效时，elastic-job会在leader节点下面建立failover节点以及items节点。items节点下会有失效任务实例的本来应该作的分片好。好比，失效的任务实例原来负责分片1和2。那么items节点下就会有名字叫1的子节点，就表明分片1须要转移到其余节点上去运行。以下图：

而后，因为每一个存活着的任务实例都会收到zk节点丢失的事件，哪一个分片失效也已经在leader节点的failover子节点下。因此这些或者的任务实例就会争抢这个分片任务来执行。为了保证不重复执行，elastic-job使用了curator的LeaderLatch类来进行选举执行。在得到执行权后，就会在sharding节点的分片上添加failover节点，并写上任务实例，表示这个故障任务迁移到某一个任务实例上去完成。以下图中的sharding节点上的分片1：

执行完成后，会把相应的节点和数据删除，避免下一次重复执行。