elastic-job（通过zookeeper管理元数据）

最新推荐文章于 2025-07-01 23:13:52 发布

gold_zwj

最新推荐文章于 2025-07-01 23:13:52 发布

阅读量2.3k

点赞数

CC 4.0 BY-SA版权

分类专栏： java

本文链接：https://blog.youkuaiyun.com/zwjyyy1203/article/details/99457370

java 专栏收录该内容

114 篇文章

订阅专栏

探讨了Elastic-Job在执行过程中遇到异常时的失效转移机制，详细解析了如何通过注册中心创建与管理failover节点，实现分片任务在其他节点上的重新执行。

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

任务重新分片只是解决了下次任务执行时，所有的分片任务都是分布到各个实例中，但是当前失效的任务是如何处理的。

失效转移。Failover：在执行任务的过程中遇见异常的情况，这个分片任务可以在其他节点再次执行。

首先，在某个任务实例elastic-job会在leader节点下面创建failover节点以及items节点。
items节点下会有失效任务实例的原本应该做好的分片。

处理步骤：

1、每个分片id写到/jobName/leader/failover/items

条件一：${JOB_NAME}/leader/failover/items/${ITEM_ID} 有失效转移的作业分片项。

条件二：当前作业不在运行中。此条件即是上文提交的作业节点空闲的定义。

       失效转移：运行中的作业服务器崩溃不会导致重新分片，只会在下次作业启动时分片。
               启用失效转移功能可以在本次作业执行过程中，监测其他作业服务器【空闲】，抓取未完成的孤儿分片项执行。

在FailoverLeaderExecutionCallback中回调逻辑如下：

（1）也会首先判断是否需要失效转移，

（2）从注册中心获得一个 `${JOB_NAME}/leader/failover/items/${ITEM_ID}` 作业分片项，

（3）在注册中心注册节点`${JOB_NAME}/sharding/${ITEM_ID}/failover` 作业分片项为当前作业节点，

（4）然后移除任务转移分片项，【${JOB_NAME}/leader/failover/items/${ITEM_ID}】

（5）最后调用执行，提交任务

// 获得一个 `${JOB_NAME}/leader/failover/items/${ITEM_ID}` 作业分片项
int crashedItem = Integer.parseInt(jobNodeStorage.getJobNodeChildrenKeys(FailoverNode.ITEMS_ROOT).get(0));
log.debug("Failover job '{}' begin, crashed item '{}'", jobName, crashedItem);
// 设置这个 `${JOB_NAME}/sharding/${ITEM_ID}/failover` 作业分片项为当前作业节点
jobNodeStorage.fillEphemeralJobNode(FailoverNode.getExecutionFailoverNode(crashedItem), JobRegistry.getInstance().getJobInstance(jobName).getJobInstanceId());
// 移除这个 `${JOB_NAME}/leader/failover/items/${ITEM_ID}` 作业分片项
jobNodeStorage.removeJobNodeIfExisted(FailoverNode.getItemsNode(crashedItem));
// TODO 不应使用triggerJob, 而是使用executor统一调度疑问：为什么要用executor统一，后面研究下
// 触发作业执行
JobScheduleController jobScheduleController = JobRegistry.getInstance().getJobScheduleController(jobName);
if (null != jobScheduleController) {
jobScheduleController.triggerJob();
}