elastic-job详解(四):失效转移
elastic-job详解(四):失效转移
细肉云吞 发表于5个月前
elastic-job详解(四):失效转移
  • 发表于 5个月前
  • 阅读 151
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

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:

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

标签: elastic-job
共有 人打赏支持
粉丝 80
博文 101
码字总数 109387
×
细肉云吞
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: