1. 产品简介
Schedulerx2.0是阿里中间件自研的基于Akka架构的新一代分布式任务调度平台,提供定时、任务编排、分布式跑批等功能。使用Schedulerx2.0,您可以在控制台配置管理您的定时任务,查询历史执行记录,查看运行日志。借助Schedulerx2.0,您还可以通过工作流进行任务编排和数据传递。Schedulerx2.0还提供了简单易用的分布式编程模型,简单几行代码就可以将海量数据分布式到多台机器上执行。
Schedulerx2.0提供了任务调度与执行的一整套解决方案,在阿里巴巴集团内部广泛使用并久经考验,具有高可靠、海量任务、秒级别调度等能力。
钉钉群号:23103656
产品链接:https://schedulerx2.console.aliyun.com
2. 核心竞争力
2.1 高可用
SchedulerX2.0采用高可用架构,任务多备份机制,经历阿里集团多年双十一、容灾演练,可以做到整个集群挂掉任意一个机房,任务调度都不会收到影响。
2.2 可视化
schedulerx拥有丰富的可视化能力,比如
- 用户大盘
- 查看任务历史执行记录
- 查看任务运行日志
- 查看任务运行堆栈
- 查看任务操作记录
2.3 可运维
Schedulerx提供了多种运维手段,比如动态修改任务、启用禁用任务、停止运行中的任务、重跑失败的任务等等。
3. 功能列表
3.1 强大的定时调度器
3.1.1 Crontab
支持unix crontab表达式,不支持秒级别。
3.1.2 Fixed rate
众所周知,crontab必须被60整除,比如想每隔40分钟跑一次,cron不支持。Fixed rate专门用来做定期轮询,表达式简单,不支持秒级别。
3.1.3 Fixed delay
适合对实时性要求比较高的业务,比如每次执行完成隔10秒再跑,那么second delay非常适合你。并且second delay能支持到秒级别。
3.1.4 one time
未来固定时间点跑一次,任务自动销毁。常见场景
- 订单超时未支付自动关闭
- 定时日历提醒
3.1.5 日历
支持多种日历,还可以自定义导入日历。比如金融业务需要在每个交易日执行。
3.1.6 时区
跨国的业务,需要在每个国家的时区定时执行某个任务。
3.2 任务编排
支持工作流(DAG)进行任务编排,操作简单,前端直接单手操作拖拖拽拽即可。详细的任务状态图能一目了然看到下游任务为什么没跑。
3.3 任务类型
支持多语言任务类型
- java:可以跑在用户进程中,也可以上传jar包动态加载。
- shell:前端直接写shell脚本。
- python:前端直接写python脚本,需要机器有python环境。
- go:前端直接写go脚本,需要机器有go环境。
- http: 不需要客户端/Agent接入,直接调用应用的http接口。
- 自定义:用户甚至可以自定义任务类型,然后实现一个plugin就行了。
3.4 分布式编程模型
Schedulerx2.0提供了丰富的分布式模型,可以处理各种各样的分布式处理业务场景。包括
- 单机:任务随机挑选一台机器幂等执行。
- 广播:任务广播所有机器同时执行。
- 分片模型:将分片参数平均分给不同机器分布式执行。
- MapReduce:通过编程,将任意海量数据(比如数据库或者oss)分布式给不同机器执行。
3.5 强大的运维能力
- 监控大盘:控制台提供了执行记录大盘和执行列表,可以看到每个任务的执行历史,并提供操作。
- 查看日志:每条执行记录,都可以详情中的日志页面实时看到日志。如果任务运行失败了,前端直接就能看到错误日志,非常方便。
- 原地重跑:任务失败,修改完代码发布后,可以点击原地重跑。
- 标记成功:任务失败,如果后台把数据处理正确了,重跑又需要好几个小时,直接标记成功就好了。
- Kill:实现JobProcessor的kill()接口,你就可以在前端kill正在运行的任务,甚至子任务。
3.6 数据时间
Schedulerx2.0可以处理有数据状态的任务。创建任务的时候可以填数据偏移。比如一个任务是每天00:30运行,但是实际上要处理上一天的数据,就可以向前偏移一个小时。运行时间不变,执行的时候通过context.getDataTime()获得的就是前一天23:30。
3.7 重刷数据
既然任务具有了数据时间,一定少不了重刷数据。比如一个任务/工作流最终产生一个报表,但是业务发生变更(新增一个字段),或者发现上一个月的数据都有错误,那么就需要重刷过去一个月的数据。
通过重刷数据功能,可以重刷某些任务/工作流的数据(只支持天级别),每个实例都是不同的数据时间。
3.8 失败自动重试
- 实例失败自动重试:在任务管理的高级配置中,可以配置实例失败重试次数和重试间隔,比如重试3次,每次间隔30秒。如果重试3次仍旧失败,该实例状态才会变为失败,并发送报警。
- 子任务失败自动重试:如果是分布式任务(并行计算/内网网格/网格计算),子任务也支持失败自动重试和重试间隔,同样可以通过任务管理的高级配置进行配置。
3.9 支持原生Springboot注入
支持Springboot声明式定义,命名空间、应用、任务、报警等都通过配置文件声明,方便管理自己应用下的任务,并且可以支持修改。可以拿到任何环境一键启动应用。
3.10 报警监控
支持邮件、钉钉、短信、电话,其他报警方式在规划中。支持任务失败、超时、无可用机器报警。报警内容可以简单的看出任务失败的原因,以钉钉机器人为例
3.11 可抢占的任务优先级队列
很多业务方都有限流和任务优先级的需求。比如数据平台每天要跑报表,可能会有成千上万的任务在晚上跑,如果没有资源控制,所有任务一起跑会把应用打挂。然后要求kpi报表必须早上9点前产生(老板和运营上班要看),这就需要在资源控制的基础上,高优先级任务优先调度,如果低优先级任务先进入队列,高优先任务也能抢占优先调度。详情请参考
3.12 权限管控
支持按照命名空间和应用级别隔离,支持细粒度的控制台管控及客户端接入鉴权
3.13 开发API
提供开放的API,可以通过API动态创建、修改、运行你的任务。