1. 产品简介
Schedulerx2.0是阿里中间件自研的基于Akka架构的新一代分布式任务调度平台，提供定时、任务编排、分布式跑批等功能。使用Schedulerx2.0，您可以在控制台配置管理您的定时任务，查询历史执行记录，查看运行日志。借助Schedulerx2.0，您还可以通过工作流进行任务编排和数据传递。Schedulerx2.0还提供了简单易用的分布式编程模型，简单几行代码就可以将海量数据分布式到多台机器上执行。
Schedulerx2.0提供了任务调度与执行的一整套解决方案，在阿里巴巴集团内部广泛使用并久经考验，具有高可靠、海量任务、秒级别调度等能力。
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 报警监控
- 失败报警
- 超时报警
- 报警方式：短信
作者：黄晓萌
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。