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包，由排程平台申請容器運作，大大減少了接入的代價，還能做到細粒度的資源管控，彈性擴縮容等能力。