一個調度平台，可以根據業務需要選擇不同的調度算法，這里的作業資源調度算法跟操作系統的進程資源調度算法有相似性，但是不存在操作系統的系統進程用戶進程調度划分，這里按照通俗的理解，例舉一些常用的作業資源調度算法。
一種方式是先來后到的方式，先來的先被調用，先分配CPU、內存等資源，后來的在隊列等待，這種方式適合平均計算時間、耗用資源情況差不多的作業，為了讓后來的作業有機會提前運行，通常還會匹配優先級，即優先級高的先運行，優先級一樣的按先來后到方式運行。
但是實際操作的時候，優先級容易碰到問題，如果用戶都認為自己的作業優先，把自己提交的作業優先級都設置的最高，這樣排在后面的作業還是要等很久才被調度，特別是前面有一個耗用資源特別久的作業，比如占用幾個小時乃至幾天的大部分機器的CPU和內存的訓練算法作業，導致排在后面的大量很短時間運行完、耗用資源比較少的作業很久才被調度，實際上他們優先調度更適合。
另一種方式，也就是根據上面問題產生的最短時間或者最少資源耗用優先方式。但是這樣也是有問題的，如果一個用戶像買彩票多買概率就高一樣，一次提交了大量作業（也許還有相同的作業），就為了優先得到執行，如果他提交的作業時間都比較短，那永遠都是這個用戶在占用計算平台集群資源，其他用戶永遠在等。
因此，還有一種公平方式去保證資源調度，也就是每個用戶分配一個資源池，不能多用，如果要多提交作業任務，把自己的資源池占光了，就只能等了，大家都公平的使用資源。這樣看似解決了公平問題，但是又是有問題的，跟大鍋飯問題相似，有的用戶的作業多任務重，分配到的資源少，有的用戶作業稀少也占用一樣的資源池，反而不公平了，這里按用戶平均分配資源池並不能真正公平。
所以，又出現了按容量調度方式，通俗的說，每個用戶的資源池里如果有多余的資源容量，要共享出來，拿出來給其他有需要的用戶使用，調度平台去保障這種容量的管理和分配。
還只有更多的調度算法，這里不再一一列舉。
我們可以看到，作業資源調度算法隨着使用問題和解決會不斷發展新的內容，同時在不同的業務場景中還會面臨不同的權重，比如作業性質的權衡，生產作業要優先，訓練作業要往后，生產作業中止后恢復要繼續優先排，還有資源類別的權衡和分配策略，CPU占用型和內存占用型誰更優先，CPU、內存、硬盤、帶寬幾種資源之間的調度搭配，不同硬件性能服務器的資源調度側重，等等，是一個很復雜的課題，跟業務場景也很相關。