背景
公司选用elasticjob作为分布式任务调度工具，版本2.1.5，其中有一个任务对应机器两台，A和B，任务总分片数是4，A对应分片0、1，B对应分片2、3。任务每晚23:30:00执行，T日计算数据记录日期T+1，供T+1日使用。
突然有一天，A机器在22:24运行执行起分片2任务，执行完分片2之后又执行了分片3，注意分片2、3本该是机器B所用的分片，这两点就很奇怪了，异常的时间执行了不属于自己的分片，而且是一个一个执行。下方是日志中记录的task id
// 异常的task id，很清楚的看到分片是@2@，机器A在执行
"taskId":"jobname@-@2@-@READY@-@A机器ip@-@4927"
// 正常的task id，分片号@2,3@，ip对应的是机器B
"taskId":"jobname@-@2,3@-@READY@-@B机器ip@-@12384"经过分析，基本断定是进任务失效转移逻辑了。但是，为什么任务失效转移呢？任务不在执行的时间点，而且也没有执行中，不可能出现这个情况。
经过回忆，22:23的时候，开发对机器B做了一次内存dump，与A机器启动相差一分钟，可能问题出在这里了。难道对B机器做dump操作导致B短暂与ZK注册中心断开了吗，导致误以为服务器宕机？带着问题，我们又对B做了一次dump，很快，证实了我们的猜测，如下图所示，分片2正在运行，实际执行分片2的是机器A，而且标识也很清楚，失效转移
但是，按照官方的说法，失效转移是指运行中的作业服务器崩溃不会导致重新分片，只会在下次作业启动时分片。启用失效转移功能可以在本次作业执行过程中，监测其他作业服务器空闲，抓取未完成的孤儿分片项执行。
运行中的作业服务器崩溃不会导致重新分片，经过确认，当时我们的任务并不在执行中，这个就很奇怪了，带着这些疑问我们深入elasticjob源码。
失效转移
失效转移相关逻辑入口在FailoverListenerManager#JobCrashedJobListener，实际处理是FailoverService。当一台服务器宕机后会触发一个事件Type.NODE_REMOVED，elastic-job根据这个事件来进行相关的处理，相关过程都注释在代码里了。
public final class FailoverListenerManager extends AbstractListenerManager {
// ...
private final FailoverService failoverService;
private final ShardingService shardingService;
class JobCrashedJobListener extends AbstractJobListener {
@Override
protected void dataChanged(final String path, final Type eventType, final String data) {
// 1失效转移开启、2注册中心事件-节点移除，也就是一台服务器下线、3是instance路径，即jobName/instances路径
if (isFailoverEnabled() && Type.NODE_REMOVED == eventType && instanceNode.isInstancePath(path)) {
// path，jobName/instances/ip-@-@pid
// jobInstanceId是这个样子的ip-@-@pid
String jobInstanceId = path.substring(instanceNode.getInstanceFullPath().length() + 1);
// 如果jobInstanceId和当前机器一致，直接跳过
if (jobInstanceId.equals(JobRegistry.getInstance().getJobInstance(jobName).getJobInstanceId())) {
return;
}
// 获取失效转移的分片，对应zk目录jobName/sharding/分片号/failover，失效转移分片对应的实例id
List<Integer> failoverItems = failoverService.getFailoverItems(jobInstanceId);
if (!failoverItems.isEmpty()) {
// 如果有jobInstanceId的失效转移分片
for (int each : failoverItems) {
// 把分片存放到目录leader/failover/items
failoverService.setCrashedFailoverFlag(each);
failoverService.failoverIfNecessary();
}
} else {
// 获取如果jobInstanceId没有失效转移分片对应的分片，然后存放到目录leader/failover/items/分片号，执行分片分片失效转移
// 从这里看只要是服务器宕机就一定要执行时效转移逻辑了，其实也不是，
// shardingService.getShardingItems(jobInstanceId)会判断服务器是否还可用，不可用的话返回的分片集合就是空的
// 但是，针对dump对内存导致的服务器短暂的不可用，则有可能出现错误，我们的任务异常启动就出现这里
for (int each : shardingService.getShardingItems(jobInstanceId)) {
// 把分片存放到目录leader/failover/items
failoverService.setCrashedFailoverFlag(each);
failoverService.failoverIfNecessary();
}
}
}
}
}
// ...
}public final class FailoverService {
/**
* 如果需要失效转移, 则执行作业失效转移.
*/
public void failoverIfNecessary() {
if (needFailover()) {
jobNodeStorage.executeInLeader(FailoverNode.LATCH, new FailoverLeaderExecutionCallback());
}
}
// 判断leader/failover/items下是否有节点
// failoverService.setCrashedFailoverFlag(分片号);方法就是往leader/failover/items目录下存节点，也就是执行了setCrashedFailoverFlag方法后，needFailover()是true
private boolean needFailover() {
return jobNodeStorage.isJobNodeExisted(FailoverNode.ITEMS_ROOT) && !jobNodeStorage.getJobNodeChildrenKeys(FailoverNode.ITEMS_ROOT).isEmpty()
&& !JobRegistry.getInstance().isJobRunning(jobName);
}
/**
* 获取作业服务器的失效转移分片项集合.
*
* @param jobInstanceId 作业运行实例主键
* @return 作业失效转移的分片项集合
*/
public List<Integer> getFailoverItems(final String jobInstanceId) {
// 作业分片
List<String> items = jobNodeStorage.getJobNodeChildrenKeys(ShardingNode.ROOT);
List<Integer> result = new ArrayList<>(items.size());
for (String each : items) {
int item = Integer.parseInt(each);
// 获取目录sharding/分片号/failover下的节点
String node = FailoverNode.getExecutionFailoverNode(item);
// 确认jobName/sharding/分片号/failover下的实例是否和失效的jobInstanceId一致，如果是的话就加入到失效分片集合
if (jobNodeStorage.isJobNodeExisted(node) && jobInstanceId.equals(jobNodeStorage.getJobNodeDataDirectly(node))) {
result.add(item);
}
}
Collections.sort(result);
return result;
}
class FailoverLeaderExecutionCallback implements LeaderExecutionCallback {
@Override
public void execute() {
// 判断本机是否停止调度任务了以及是否需要失效转移
if (JobRegistry.getInstance().isShutdown(jobName) || !needFailover()) {
return;
}
// leader/failover/items下获取失效转移的分片
int crashedItem = Integer.parseInt(jobNodeStorage.getJobNodeChildrenKeys(FailoverNode.ITEMS_ROOT).get(0));
log.debug("Failover job '{}' begin, crashed item '{}'", jobName, crashedItem);
// 目录下sharding/分片号/failover下创建节点，标识失效转移正在执行中
jobNodeStorage.fillEphemeralJobNode(FailoverNode.getExecutionFailoverNode(crashedItem), JobRegistry.getInstance().getJobInstance(jobName).getJobInstanceId());
// 删除分片失效转移记录
jobNodeStorage.removeJobNodeIfExisted(FailoverNode.getItemsNode(crashedItem));
// TODO 不应使用triggerJob, 而是使用executor统一调度
// 执行失效转移作业
JobScheduleController jobScheduleController = JobRegistry.getInstance().getJobScheduleController(jobName);
if (null != jobScheduleController) {
jobScheduleController.triggerJob();
}
}
}
}
public final class ShardingService {
/**
* 设置需要重新分片的标记.
*/
public void setReshardingFlag() {
jobNodeStorage.createJobNodeIfNeeded(ShardingNode.NECESSARY);
}
/**
* 获取作业运行实例的分片项集合.
*
* @param jobInstanceId 作业运行实例主键
* @return 作业运行实例的分片项集合
*/
public List<Integer> getShardingItems(final String jobInstanceId) {
JobInstance jobInstance = new JobInstance(jobInstanceId);
// 服务器可用，即servers/目录及jobName/instances目录下存在对应的ip
if (!serverService.isAvailableServer(jobInstance.getIp())) {
return Collections.emptyList();
}
List<Integer> result = new LinkedList<>();
// 获取所有分片
int shardingTotalCount = configService.load(true).getTypeConfig().getCoreConfig().getShardingTotalCount();
for (int i = 0; i < shardingTotalCount; i++) {
// 找到宕机服务器对应的分片
if (jobInstance.getJobInstanceId().equals(jobNodeStorage.getJobNodeData(ShardingNode.getInstanceNode(i)))) {
result.add(i);
}
}
return result;
}
}结论
dump堆内存导致服务器B短暂不可用，与注册中心断开连接，触发了注册中心zk节点删除事件，服务器A监听到事件后执行失效转移逻辑，当服务器A去获取服务器B对应的分片时，服务器B又恢复了工作，这时服务器A拿到了服务B的两个分片2、3，依次执行失效转移逻辑，这就是为什么dump B之后A开始执行B的两个分片。
class JobCrashedJobListener extends AbstractJobListener {
@Override
protected void dataChanged(final String path, final Type eventType, final String data) {
// 1失效转移开启、2注册中心事件-节点移除，也就是一台服务器下线、3是instance路径，即jobName/instances路径
if (isFailoverEnabled() && Type.NODE_REMOVED == eventType && instanceNode.isInstancePath(path)) {
...
List<Integer> failoverItems = failoverService.getFailoverItems(jobInstanceId);
if (!failoverItems.isEmpty()) {
...
} else {
// 获取如果jobInstanceId没有失效转移分片对应的分片，然后存放到目录leader/failover/items/分片号，执行分片分片失效转移
// 从这里看只要是服务器宕机就一定要执行时效转移逻辑了，其实也不是，
// shardingService.getShardingItems(jobInstanceId)会判断服务器是否还可用，不可用的话返回的分片集合就是空的
// 但是，针对dump对内存导致的服务器短暂的不可用，则有可能出现错误，我们的任务异常启动就出现这里
for (int each : shardingService.getShardingItems(jobInstanceId)) {
failoverService.setCrashedFailoverFlag(each);
failoverService.failoverIfNecessary();
}
}
}
}
}附 zk注册中心任务记录
namespace/jobname
leader
failover
items
- 2 失效转移分片，也是判断是否需要标识
- 3 失效转移分片，也是判断是否需要标识
sharding
- necessary 需要重新调整分片
election
- host
- latch
servers
172.16.101.112
- prcessSuccessCount
- hostName
- processFailureCount
- status
- disabled
- sharding
172.16.101.52
- prcessSuccessCount
- hostName
- processFailureCount
- status
- disabled
- sharding
config
- cron
- shardingTermParameters
- failover
- processCountIntervalSeconds
- monitorExecution
- shardingTotalCount
- jobParameter
- fetchDataCount
- concurrentDataProcessThreadCount
instances
- [172.16.101.112@-@9644, 172.16.101.52@-@10138]
sharding
0
- running 分片运行中
- instance 运行的实例
- failover 分片失效转移，运行中
- 1
- 2
- 3
重要的类，待完善
JobRegistry 任务管理，一个JVM一个单例，记录任务和注册中心对应关心、任务状态、任务实例
SchedulerFacade 任务调度门面类，一个任务对应一个
JobNodeStorage 作业节点访问
ShardingNode zk节点名称构建规则
JobNodePath 作业节点构建
/jobname/sharding
注册中心
RegistryCenter
CoordinatorRegistryCenter
ZookeeperRegistryCenter
事件监听
AbstractListenerManager
ShutdownListenerManager
