1. 前言
Schedulerx2.0是一套分布式的任务调度+计算框架。作为一套分布式计算引擎，用户经常需要资源管理的需求，当前schedulerx仅仅支持单个任务实例的管控（比如单机子任务并发数、拉模型全局子任务并发数等），这一点是远远不够的。比如某一时刻大量任务要触发，用户资源不够，当前是无法管控的。
业内任务调度系统一般都focus在任务调度上，资源管理会借助第三方系统（比如mesos, yarn），这类系统的执行单元worker都是由调度平台管控的。这一点和schedulerx还是不一样的，schedulerx的计算worker都是各个用户自己的应用程序接入的，无法通过统一的第三方资源管理系统来管理。
2. 应用级别资源管理
1) 新建应用分组的时候，高级配置可以打开流控开关（默认关闭）
打开开关后，可以配置应用级别的任务队列（即任务实例并发数）。该队列表示一个应用最多同时运行的任务实例个数，超过并发数的任务实例不会丢弃，会放在队列中等待执行。
2) 在该分组下新建3个任务，分别手动运行一次
3) 会发现，第一个触发的任务hello_jobA在运行中，hello_jobB和hello_jobC在池子中排队
4) 等hello_jobA运行完，hello_jobB会进入执行队列
3. 任务优先级
任务支持优先级，同一个应用下，调度时间一样，优先级高的任务优先调度
用户1：“我把自己的任务全部设置为非常高，是不是能保证自己的任务比其他用户的任务优先调度？”
回答：任务优先级是应用级别的，只会在该应用下生效，不会影响其他应用。
用户2：“客户端都有很多台机器，高优先任务和低优先级任务分布式调度到不同的机器，也有可能低优先任务先运行啊，这个功能看起来貌似很鸡肋？”
回答：别急，接着看下一节。
4. 可抢占的优先级队列
熟悉大数据的同学，应该对下面这个图很熟悉。这个是yarn的优先级队列，对不同优先级的任务做资源隔离
我们可以来看下，schedulerx如何通过应用级别资源管理+任务优先级，来实现可抢占的任务优先级队列。
1) dts-all.hxm这个应用开启限流，队列大小=1方便观察，新建3个优先级任务如下图。先触发1次中优先级任务，再触发1次低优先级任务，再触发一次高优先级任务
2) 因为先触发中优先级任务的时候，队列还是空的，所以中优先任务先跑
3) 中优先级任务跑完之后，队列有空闲槽位了，高优先级任务会抢占低优先级任务先执行
5. 应用场景
该功能上线后，应用场景非常多，很多业务方都有应用级别资源控制和任务优先级的需求。比如数据平台每天要跑报表，可能会有成千上万的任务在晚上跑，如果没有资源控制，所有任务一起跑会把应用打挂。然后要求kpi报表必须早上9点前产生（老板和运营上班要看），这就需要在资源控制的基础上，高优先级任务优先调度，如果低优先级任务先进入队列，高优先任务也能抢占优先调度。
6. 总结及未来展望
相比较yarn的资源管理来说，yarn能做到vcore, cpu, memory等资源级别的管控。Schedulerx作为通用的任务调度平台，在调度端实现对任务运行实例个数和优先级的管控。
当前Schedulerx无法做到core, cpu, memory级别的资源管控，是因为当前接入方式，是应用自己的worker接入，不是由调度平台提供的机器。未来Schedulerx会和云原生结合，用户接入只需要上传jobProcessor的jar包，由调度平台申请容器运行，大大减少了接入的代价，还能做到细粒度的资源管控，弹性扩缩容等能力。
