1 簡介 任務是需要資源(CPU 時間、記憶體、存儲、網路帶寬等)在指定時間內完成的一段計算工作。 通過智能地將資源分配給任務以滿足任務級和系統級目標的系統稱為任務調度程式。 任務調度程式： 及時決定和分配資源給任務的過程稱為任務調度。 當我們在 Facebook 發表評論時。我們不會讓評論發佈者等待 ...
1 簡介
任務是需要資源(CPU 時間、記憶體、存儲、網路帶寬等)在指定時間內完成的一段計算工作。
通過智能地將資源分配給任務以滿足任務級和系統級目標的系統稱為任務調度程式。
任務調度程式：
及時決定和分配資源給任務的過程稱為任務調度。
當我們在 Facebook 發表評論時。我們不會讓評論發佈者等待直到那條評論被交付給所有關註者。交付被委托給一個非同步任務調度程式離線完成。
在分散式系統中，許多任務是在用戶的單個請求的背景下運行。考慮Facebook、WhatsApp 或 Instagram 這樣的熱門系統有數億用戶。這些系統需要一個任務調度程式來處理數十億個任務。Facebook 使用 Async 根據其用戶的數十億個並行非同步請求來調度其所有任務。
Async 是 Facebook 自己的分散式任務調度程式，調度其所有任務。一些任務時間敏感，如應該運行的通知用戶某項活動開始直播的任務。如果用戶在直播結束後才收到通知就沒意義了。某些任務可延遲，如向用戶提出好友建議的任務。Async 根據適當的優先順序調度任務。
2 需求
- 可用性：系統應高可用以調度和執行任務
- 持久性：系統收到的任務應持久化，不應丟失
- 可擴展性：系統應能每天調度和執行越來越多的任務
- 有限的等待時間：這是任務在開始執行之前需要等待的時間。我們不能在預期時間之後執行任務。用戶不應該無限期地等待。如果用戶的等待時間超過一定閾值，他們應該收到通知
3 組件設計
3.1 任務調度程式架構設計
① Task Submitter（任務提交者）
接受任務。沒有單一的任務提交者。相反，我們有一組接收越來越多任務的節點。
② Database（資料庫）
任務提交者接收的所有任務都存儲在分散式資料庫。使用關係資料庫來存儲：
- task IDs
- user IDs
- 所需資源
- 執行上限
- 客戶端嘗試總次數
- 延遲容忍度
- ...
使用有向無環圖（DAG）存儲依賴任務的數據的圖數據結構的非關係資料庫。
③ Batching and prioritization（批處理和優先順序）
將任務存儲在 RDB 後，將任務分批。優先順序基於任務的屬性，如：
- 延遲容忍度
- 或執行時間短的任務等。
將最高 K 優先順序的任務推送到分散式隊列，K限制可以推送到隊列的元素數量。K值取決許多因素，如：
- 當前可用資源
- 客戶端
- 或任務優先順序
- 訂閱級別
④ Queue manager（隊列管理器）
隊列管理器在隊列中添加、更新或刪除任務。它跟蹤我們使用的隊列的類型。它還負責保持任務在隊列中直到成功執行。如果任務執行失敗，該任務將再次出現在隊列。隊列管理器知道在高峰時段、非高峰時段應該運行什麼隊列。
⑤ Resource manager（資源管理器）
知道哪些資源空閑。它從分散式隊列中拉取任務並分配給它們資源。資源管理器：
- 跟蹤每個任務的執行情況
- 並將其狀態發送回隊列管理器
若任務超出其能力或所需的資源使用，則終止該任務，並將狀態發送回任務提交者，後者將通過錯誤消息通知客戶端有關任務終止的情況。
4 執行上限
4.1 任務分類
- 不能延遲的任務 - 緊急任務
- 可延遲的任務
- 需定期執行的任務 - 周期性任務
基於任務類別的多個隊列：
系統需確保非緊急隊列中的任務不會被餓死。一旦某些任務的延遲限制即將達到，它就會被移動到緊急任務隊列以獲得優先服務。
4.2 優先順序
一些任務執行時間很長並占用資源，阻塞其他任務。在調度任務時，執行上限（execution cap）是個重要參數。
若我們完全分配資源給單個任務並等待該任務完成，則由於任務腳本錯誤，某些任務可能不會停止，無法完成執行。我們允許用戶為其任務設置執行上限。指定時間後停止任務執行，釋放資源並分配給隊列中的下一任務。若由於執行上限而停止任務執行，系統會通知所屬用戶的這些實例。他們需針對這種情況採取人工兜底。
5 任務緊急執行
有些任務需緊急執行。如Facebook社交應用中，用戶可在緊急情況下標記自己是安全的，如地震。執行此活動的任務應及時執行，否則此功能對 Facebook 用戶毫無用處。向客戶發送電子郵件通知，告知其賬戶扣除一定金額的資金，是另一個需要緊急執行的任務示例。
為優先處理任務，任務調度程式為每個任務維護一個delay tolerance（延遲容忍度）參數，併在接近其延遲容忍度時執行該任務。
延遲容忍度是任務執行可延遲的最大時間量。首先執行延遲容忍時間最短的任務。通過使用延遲容忍參數，可在高峰時段推遲延遲容忍值更長的任務，為緊急任務留出空間。
6 資源容量優化
有時資源接近過載閾值(如超過 80% 利用率)，這就是高峰期。同一資源在非高峰時段可能閑置。所以，須考慮如何在非高峰時段更好利用資源及如何在高峰時段保持資源可用。
有些任務無需緊急執行。如Facebook社交應用，建議好友不是緊急任務。可以為這樣的任務創建一個單獨的隊列，併在非高峰時段執行它們。如果我們一直有比可用資源更多的工作要做，我們可能會遇到容量問題，就該配置更多資源。
7 任務冪等性
如果任務成功執行，但由於某些原因機器無法發送確認，則調度程式將再次調度該任務。再次執行該任務。
我們不希望再次執行任務時最終結果發生更改。這在轉賬時對金融應用程式至關重要。我們要求任務是冪等的。冪等任務無論執行多少次都會產生相同的結果。
此屬性是由開發人員在實現中添加的，通過某些內容(例如名稱)來標識該屬性並覆蓋舊的。
8 評估
8.1 可用性
任務提交是由多個節點完成的。若提交任務的節點失敗，其他節點將接替其位置。推送任務的隊列在本質上也是分散式，確保可用性。由於持續監控是否需要添加或刪除資源，可儘力保證始終有可用資源。設計中的每個組件都是分散式的，使得整個系統可用性大大增強。
8.2 持久性
我們將任務存儲在持久化分散式資料庫中,併在接近執行時間時將任務推送到隊列中。一旦提交任務,它就會在資料庫中直到執行完成。
8.3 可擴展性
任務調度程式提供可擴展性，因為設計中任務提交者是分散式的。可向集群添加更多節點以提交大規模數量的任務。
然後將這些任務保存到也是可擴展的分散式關係資料庫中。
再從 RDB 將任務推送到分散式隊列，它可隨任務數量增加而擴展。可為不同類型的任務添加更多隊列。還可根據資源與需求比添加更多資源。
8.4 容錯性
任務在首次發送執行時不會從隊列中刪除。如果執行失敗，將嘗試最大允許次數的重試。若任務包含死迴圈，會在指定時間後終止任務並通知用戶。
參考：
本文由博客一文多發平臺 OpenWrite 發佈！
