源码分析ElasticJob故障失效转移机制

文章详细描述了ElasticJob中当监听到任务节点宕机时的故障失效转移过程,包括获取任务实例ID、判断分片转移、创建持久节点、执行转移逻辑以及故障分片的重新执行。重点介绍了如何通过监听和分布式锁实现任务在节点故障后的自动恢复。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

}

}

代码@1:如果配置文件中设置开启故障失效转移机制,监听到${namespace}/jobname/instances节点下子节点的删除事件时,则被认为有节点宕机,将执行故障失效转移相关逻辑。

代码@2:获取被宕机的任务实例ID(jobInstanceId)。

代码@3:如果被删除的任务节点ID与当前实例的ID相同,则忽略。

代码@4:根据jobInstanceId获取作业服务器的失效转移分片项集合。

其实现逻辑如下:FailoverService#getFailoverItems

/**

  • 获取作业服务器的失效转移分片项集合.

  • @param jobInstanceId 作业运行实例主键

  • @return 作业失效转移的分片项集合

*/

public List getFailoverItems(final String jobInstanceId) {

List items = jobNodeStorage.getJobNodeChildrenKeys(ShardingNode.ROOT);

List result = new ArrayList<>(items.size());

for (String each : items) {

int item = Integer.parseInt(each);

String node = FailoverNode.getExecutionFailoverNode(item);

if (jobNodeStorage.isJobNodeExisted(node) && jobInstanceId.equals(jobNodeStorage.getJobNodeDataDirectly(node))) {

result.add(item);

}

}

Collections.sort(result);

return result;

}

首先获取 n a m e s p a c e / j o b n a m e / s h a r d i n g 目录下的直接子节点 ( 当前的分片信息 ) ,判断 {namespace}/jobname/sharding目录下的直接子节点(当前的分片信息),判断 namespace/jobname/sharding目录下的直接子节点(当前的分片信息)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值