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动态创建、修改、运行你的任务。
