阿里新一代分布式任务调度平台Schedulerx2.0破土而出

1. 产品简介

Schedulerx2.0是阿里中间件自研的基于Akka架构的新一代分布式任务调度平台，提供定时、任务编排、分布式跑批等功能。使用Schedulerx2.0，您能够在控制台配置管理您的定时任务，查询历史执行记录，查看运行日志。借助Schedulerx2.0，您还能够经过工做流进行任务编排和数据传递。Schedulerx2.0还提供了简单易用的分布式编程模型，简单几行代码就能够将海量数据分布式到多台机器上执行。

Schedulerx2.0提供了任务调度与执行的一整套解决方案，在阿里巴巴集团内部普遍使用并久经考验，具备高可靠、海量任务、秒级别调度等能力。

上线时间：2019-04-30

2. 背景

Schedulerx2.0是Schedulerx1.0(DTS)的下一代产品，采用全新的架构，是全新自研的下一代分布式任务调度平台，不但解决了老产品的性能瓶颈，还提供了更多更快更强的能力。

• 更多：支持多种时间表达式，任务编排，支持更多的业务场景。单集群支持上千万任务，一天上十亿次调度，支持更多的任务数。
• 更快：支持秒级别调度，处理准实时业务。
• 更强：支持日志查询、原地重跑、重刷数据等多种操做，提供更强的运维能力和排错手段，解决为何没跑，为何失败，为何跑得慢等问题。

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 日历

支持多种日历，还能够自定义导入日历。好比金融业务须要在每一个交易日执行。

3.1.5 时区

跨国的业务，须要在每一个国家的时区定时执行某个任务。

3.2 任务编排

支持工做流（DAG）进行任务编排，操做简单，前端直接单手操做拖拖拽拽便可。详细的任务状态图能一目了然看到下游任务为何没跑。

3.3 任务类型

支持多种任务类型，能够无限扩展。

• java：能够跑在用户进程中，也能够上传jar包动态加载。
• shell：前端直接写shell脚本。
• python：前端直接写python脚本，须要机器有python环境。
• go：前端直接写go脚本，须要机器有go环境。
• 自定义：用户甚至能够自定义任务类型，而后实现一个plugin就好了。

3.4 执行方式&分布式编程模型

3.4.1 执行方式

• 单机：随机挑选一台机器执行
• 广播：全部机器同时执行且等待所有结束
• 并行计算：map/mapreduce模型，1~300个子任务，有子任务列表。
• 内存网格：map/mapreduce模型，10W如下子任务，无子任务列表，基于内存计算，比网格计算快。
• 网格计算：map/mapreduce模型，100W如下子任务，无子任务列表，基于文件H2计算。

3.4.2 分布式编程模型

• Map模型：相似于hadoop mapreduce里的map。只要实现一个map方法，简单几行代码就能够将海量数据分布式到客户本身的多台机器上执行，进行跑批。
• MapReduce模型：MapReduce模型是Map模型的扩展，新增reduce接口，全部子任务完成后会执行reduce方法，能够在reduce方法中返回该任务实例的执行结果，或者回调业务。

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 支持原生Spring

以前的老产品Schedulerx1.0(DTS)和spring的结合很是暴力，对bean的命名有强要求，常常遇到注入失败的问题。Schedulerx2.0支持原生spring语法，接入更加的方便。

3.10 报警监控

• 失败报警
• 超时报警
• 报警方式：短信

---

本文做者：黄晓萌

阅读原文

本文为云栖社区原创内容，未经容许不得转载。