分布式定时任务elastic-job(四)
2021-05-30 本文已影响0人
后来丶_a24d
目录
目录.png
分布式定时任务系列
自诊断恢复
-
解决分布式作业不一致状态ReconcileService，AbstractScheduledService是guava提供的，scheduler方法配合runOneIteration，定时操作
ReconcileService.png
- 如果是主作业节点 而且 当前作业不需要重新分片 而且 查询是包含有分片节点的不在线服务器，那么设置需要重新分片的标记。这样达到自诊断修复
// 定时每分钟执行的方法
@Override
protected void runOneIteration() throws Exception {
LiteJobConfiguration config = configService.load(true);
int reconcileIntervalMinutes = null == config ? -1 : config.getReconcileIntervalMinutes();
if (reconcileIntervalMinutes > 0 && (System.currentTimeMillis() - lastReconcileTime >= reconcileIntervalMinutes * 60 * 1000)) { // 校验是否达到校验周期
// 设置最后校验时间
lastReconcileTime = System.currentTimeMillis();
// 主作业节点 而且 当前作业不需要重新分片 而且 查询是包含有分片节点的不在线服务器
if (leaderService.isLeaderUntilBlock()
&& !shardingService.isNeedSharding()
&& shardingService.hasShardingInfoInOfflineServers()) {
log.warn("Elastic Job: job status node has inconsistent value,start reconciling...");
// 设置需要重新分片的标记
shardingService.setReshardingFlag();
}
}
}
// 定时每分钟执行
@Override
protected Scheduler scheduler() {
return Scheduler.newFixedDelaySchedule(0, 1, TimeUnit.MINUTES);
}
事件追踪
- 基于guava的EventBus实现，是一种优雅的观察者模式实现方式。
- 两种作业事件
JobStatusTraceEvent, 作业状态追踪事件，比如五个分片就记录一条, 整体的状态
JobExecutionEvent, 作业执行追踪事件，比如五个分片记录每个分片执行的情况 - JobEventRdbStorage, 作业事件数据库存储, 存储时是用jdbc执行的，基于数据库的操作，查询也是基于数据库查询
- 当然也可以自定义事件追踪，比如es实现，通过配置JobEventConfig中JobEventListener自定义就可以实现了
// JobEventBus注册监听器，不同监听器可以实现不同的存储方式，比如默认的关系型数据库存储
private void register() {
try {
eventBus.register(jobEventConfig.createJobEventListener());
isRegistered = true;
} catch (final JobEventListenerConfigurationException ex) {
log.error("Elastic job: create JobEventListener failure, error is: ", ex);
}
}
elastic-job cloud
- 额外提供了进程隔离之类的，瞬时任务提供进程级调度场景mesos是c++写的, 瞬时任务是cloud提供的能力，长时间执行资源不紧张时，创建进程，执行完，销毁进程，nginx也是进程级的
- elastic-Job-cloud使用Mesos + Docker(TBD)的解决方案，额外提供资源治理, 应用分发以及进程隔离等服务
elastic-job的一些思考
- 用分布式锁进行失效任务拿取是为了集群能力能提供服务，有master节点是为了分配分片之类的这样就不用每次获取分布式锁了，简单高效
- elastic-job异常情况
- 扩容收容 有监听
- 宕机
- zk失连 又连上
- 分片时节点下线，先选主再分片
- 这种主节点选举方式有可能脑裂？实际上elastic-job用了zk分布式锁，zk分布式锁后续可以深入研究下，zk本身也能防止脑裂，而且连不上zk的作业服务器将立刻停止执行作业，防止主节点已重新分片，而脑裂的服务器还在执行
- elastic-job无中心的思想，cloud是中心化外提供了高级特性
- elastic-job通过zk节点变化感知服务上线下线，连接失连，感知后，可以通过代码保证高可用
分布式定时任务技术选型
quartz
- 不提供分布式
xxl-job
- 基于数据库，瓶颈在数据库，适合服务时的情况，服务量大，数据库压力大，性能下降，个人维护
elastic-job
- lite无中心化，适合服务多，量大，性能不受数据库影响，当当维护贡献给apache了
其他
- 其他的开源框架文档少
总结
-
借用参考文章7的图
总结.png
