Schedulerx2.0分布式执行之——广播执行

简介: 1. 简介广播执行表示一个任务实例会广播到该分组所有worker上执行,当所有机器都执行完成,该实例才算完成。任意一台worker执行失败,都算该实例失败。所有worker执行成功,才算该实例成功。

1. 简介

广播执行表示一个任务实例会广播到该分组所有worker上执行,当所有机器都执行完成,该实例才算完成。

任意一台worker执行失败,都算该实例失败。

所有worker执行成功,才算该实例成功。

有子任务列表,可以看每台机器的执行详情。

2. 执行方式

执行方式选择广播

3. 任务类型

任务类型可以选择多种,比如脚本,或者java任务。如果选择java,还支持preProcess和postProcess高级特性。

使用java任务需要继承JavaProcessor(1.0.8+版本),接口如下:

public ProcessResult process(JobContext context) throws Exception; (必选)
public void preProcess(JobContext context); (可选)
public ProcessResult postProcess(JobContext context); (可选)
  • preProcess会在所有机器执行process之前执行,只会执行一次。
  • postProcess会在所有机器执行process之后且都成功执行,之后执行一次,可以返回结果,作为工作流数据传输。

4. 应用场景

4.1 批量运维

  • 定时广播所有机器运行某个脚本。
  • 定时广播所有机器清理缓存。

4.2 数据聚合

1)使用BroadcastJavaProcessor,preProcess的时候重置数据库count=0;
2)每台机器执行process的时候,根据自己机器内存或者日志的值,往数据库count叠加;
3)postProcess的时候,读取数据库count值,传给下游;

5. Demo

@Component
public class TestBroadcastJobProcessor extends JavaProcessor {

    @Override
    public ProcessResult process(JobContext context) throws Exception {
        System.out.println("this is process");
        return new ProcessResult(true);
    }

    @Override
    public void preProcess(JobContext context) {
        System.out.println("this is preProcess");
    }

    @Override
    public ProcessResult postProcess(JobContext context) {
        System.out.println("this is postProcess");
        return new ProcessResult(true, "hello broadcast");
    }
}

如上代码所示,起三台机器,执行结果如下:
worker1:

this is preProcess
this is process
this is postProcess

worker2:

this is process

worker3:

this is process
目录
相关文章
|
分布式计算 并行计算 数据库
Schedulerx2.0分布式计算原理&最佳实践
1. 前言 Schedulerx2.0的客户端提供分布式执行、多种任务类型、统一日志等框架,用户只要依赖schedulerx-worker这个jar包,通过schedulerx2.0提供的编程模型,简单几行代码就能实现一套高可靠可运维的分布式执行引擎。
23923 2
|
4月前
|
资源调度 Java 调度
项目环境测试问题之Schedulerx2.0通过分布式分片任务解决单机计算瓶颈如何解决
项目环境测试问题之Schedulerx2.0通过分布式分片任务解决单机计算瓶颈如何解决
项目环境测试问题之Schedulerx2.0通过分布式分片任务解决单机计算瓶颈如何解决
|
资源调度 运维 DataWorks
阿里分布式任务调度SchedulerX2.0支持Dataworks任务
在实际业务场景中业务处理往往依赖前置数据准备,目前在分布式任务调度平台上可进行dataworks任务数据处理与业务数据处理任务依赖编排定时调度。
1222 1
|
缓存 资源调度 分布式计算
阿里云分布式任务调度SchedulerX2.0正式商业化
Schedulerx2.0在公有云公测2年,服务超过1000家公司,积累了丰富的经验,稳定性也得到了足够的验证。为了提供更优质的服务,于2021.9.1正式商业化,同时也会带来更加强大的能力
1762 0
|
前端开发 Java 调度
阿里新一代分布式任务调度平台Schedulerx2.0破土而出
SchedulerX是阿里巴巴自研的基于Akka架构的分布式任务调度平台(兼容开源XXL-JOB/ElasticJob),支持Cron定时、一次性任务、任务编排、分布式跑批,具有高可用、可视化、低延时等能力。
17961 0
阿里新一代分布式任务调度平台Schedulerx2.0破土而出
|
分布式计算 前端开发 Java
阿里新一代分布式任务调度平台Schedulerx2.0破土而出
产品简介 Schedulerx2.0是阿里中间件自研的基于Akka架构的新一代分布式任务调度平台,提供定时、任务编排、分布式跑批等功能。使用Schedulerx2.0,您可以在控制台配置管理您的定时任务,查询历史执行记录,查看运行日志。
7670 0
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
4月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
125 2
基于Redis的高可用分布式锁——RedLock
|
4月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
27天前
|
NoSQL Redis
Redis分布式锁如何实现 ?
Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
54 16