1 簡介

任務是需要資源(CPU 時間、內存、存儲、網絡帶寬等)在指定時間內完成的一段計算工作。

通過智能地將資源分配給任務以滿足任務級和系統(tǒng)級目標的系統(tǒng)稱為任務調度程序。

任務調度程序：

及時決定和分配資源給任務的過程稱為任務調度。

當我們在 Facebook 發(fā)表評論時。我們不會讓評論發(fā)布者等待直到那條評論被交付給所有關注者。交付被委托給一個異步任務調度程序離線完成。

在分布式系統(tǒng)中，許多任務是在用戶的單個請求的背景下運行?？紤]Facebook、WhatsApp 或 Instagram 這樣的熱門系統(tǒng)有數(shù)億用戶。這些系統(tǒng)需要一個任務調度程序來處理數(shù)十億個任務。Facebook 使用 Async 根據其用戶的數(shù)十億個并行異步請求來調度其所有任務。

Async 是 Facebook 自己的分布式任務調度程序，調度其所有任務。一些任務時間敏感，如應該運行的通知用戶某項活動開始直播的任務。如果用戶在直播結束后才收到通知就沒意義了。某些任務可延遲，如向用戶提出好友建議的任務。Async 根據適當?shù)膬?yōu)先級調度任務。

2 需求

• 可用性：系統(tǒng)應高可用以調度和執(zhí)行任務
• 持久性：系統(tǒng)收到的任務應持久化，不應丟失
• 可擴展性：系統(tǒng)應能每天調度和執(zhí)行越來越多的任務
• 有限的等待時間：這是任務在開始執(zhí)行之前需要等待的時間。我們不能在預期時間之后執(zhí)行任務。用戶不應該無限期地等待。如果用戶的等待時間超過一定閾值，他們應該收到通知

3 組件設計

3.1 任務調度程序架構設計

① Task Submitter（任務提交者）

接受任務。沒有單一的任務提交者。相反，我們有一組接收越來越多任務的節(jié)點。

② Database（數(shù)據庫）

任務提交者接收的所有任務都存儲在分布式數(shù)據庫。使用關系數(shù)據庫來存儲：

• task IDs
• user IDs
• 所需資源
• 執(zhí)行上限
• 客戶端嘗試總次數(shù)
• 延遲容忍度
• ...

使用有向無環(huán)圖（DAG）存儲依賴任務的數(shù)據的圖數(shù)據結構的非關系數(shù)據庫。

③ Batching and prioritization（批處理和優(yōu)先級）

將任務存儲在 RDB 后，將任務分批。優(yōu)先級基于任務的屬性，如：

• 延遲容忍度
• 或執(zhí)行時間短的任務等。

將最高 K 優(yōu)先級的任務推送到分布式隊列，K限制可以推送到隊列的元素數(shù)量。K值取決許多因素，如：

• 當前可用資源
• 客戶端
• 或任務優(yōu)先級
• 訂閱級別

④ Queue manager（隊列管理器）

隊列管理器在隊列中添加、更新或刪除任務。它跟蹤我們使用的隊列的類型。它還負責保持任務在隊列中直到成功執(zhí)行。如果任務執(zhí)行失敗，該任務將再次出現(xiàn)在隊列。隊列管理器知道在高峰時段、非高峰時段應該運行什么隊列。

⑤ Resource manager（資源管理器）

知道哪些資源空閑。它從分布式隊列中拉取任務并分配給它們資源。資源管理器：

• 跟蹤每個任務的執(zhí)行情況
• 并將其狀態(tài)發(fā)送回隊列管理器

若任務超出其能力或所需的資源使用，則終止該任務，并將狀態(tài)發(fā)送回任務提交者，后者將通過錯誤消息通知客戶端有關任務終止的情況。

4 執(zhí)行上限

4.1 任務分類

• 不能延遲的任務 - 緊急任務
• 可延遲的任務
• 需定期執(zhí)行的任務 - 周期性任務

基于任務類別的多個隊列：

系統(tǒng)需確保非緊急隊列中的任務不會被餓死。一旦某些任務的延遲限制即將達到，它就會被移動到緊急任務隊列以獲得優(yōu)先服務。

4.2 優(yōu)先級

一些任務執(zhí)行時間很長并占用資源，阻塞其他任務。在調度任務時，執(zhí)行上限（execution cap）是個重要參數(shù)。

若我們完全分配資源給單個任務并等待該任務完成，則由于任務腳本錯誤，某些任務可能不會停止，無法完成執(zhí)行。我們允許用戶為其任務設置執(zhí)行上限。指定時間后停止任務執(zhí)行，釋放資源并分配給隊列中的下一任務。若由于執(zhí)行上限而停止任務執(zhí)行，系統(tǒng)會通知所屬用戶的這些實例。他們需針對這種情況采取人工兜底。

5 任務緊急執(zhí)行

有些任務需緊急執(zhí)行。如Facebook社交應用中，用戶可在緊急情況下標記自己是安全的，如地震。執(zhí)行此活動的任務應及時執(zhí)行，否則此功能對 Facebook 用戶毫無用處。向客戶發(fā)送電子郵件通知，告知其賬戶扣除一定金額的資金，是另一個需要緊急執(zhí)行的任務示例。

為優(yōu)先處理任務，任務調度程序為每個任務維護一個delay tolerance（延遲容忍度）參數(shù)，并在接近其延遲容忍度時執(zhí)行該任務。

延遲容忍度是任務執(zhí)行可延遲的最大時間量。首先執(zhí)行延遲容忍時間最短的任務。通過使用延遲容忍參數(shù)，可在高峰時段推遲延遲容忍值更長的任務，為緊急任務留出空間。

6 資源容量優(yōu)化

有時資源接近過載閾值(如超過 80% 利用率)，這就是高峰期。同一資源在非高峰時段可能閑置。所以，須考慮如何在非高峰時段更好利用資源及如何在高峰時段保持資源可用。

有些任務無需緊急執(zhí)行。如Facebook社交應用，建議好友不是緊急任務?？梢詾檫@樣的任務創(chuàng)建一個單獨的隊列，并在非高峰時段執(zhí)行它們。如果我們一直有比可用資源更多的工作要做，我們可能會遇到容量問題，就該配置更多資源。

7 任務冪等性

如果任務成功執(zhí)行，但由于某些原因機器無法發(fā)送確認，則調度程序將再次調度該任務。再次執(zhí)行該任務。

我們不希望再次執(zhí)行任務時最終結果發(fā)生更改。這在轉賬時對金融應用程序至關重要。我們要求任務是冪等的。冪等任務無論執(zhí)行多少次都會產生相同的結果。

此屬性是由開發(fā)人員在實現(xiàn)中添加的，通過某些內容(例如名稱)來標識該屬性并覆蓋舊的。

8 評估

8.1 可用性

任務提交是由多個節(jié)點完成的。若提交任務的節(jié)點失敗，其他節(jié)點將接替其位置。推送任務的隊列在本質上也是分布式，確?？捎眯浴Ｓ捎诔掷m(xù)監(jiān)控是否需要添加或刪除資源，可盡力保證始終有可用資源。設計中的每個組件都是分布式的，使得整個系統(tǒng)可用性大大增強。

8.2 持久性

我們將任務存儲在持久化分布式數(shù)據庫中,并在接近執(zhí)行時間時將任務推送到隊列中。一旦提交任務,它就會在數(shù)據庫中直到執(zhí)行完成。

8.3 可擴展性

任務調度程序提供可擴展性，因為設計中任務提交者是分布式的?？上蚣禾砑痈喙?jié)點以提交大規(guī)模數(shù)量的任務。

然后將這些任務保存到也是可擴展的分布式關系數(shù)據庫中。

再從 RDB 將任務推送到分布式隊列，它可隨任務數(shù)量增加而擴展?？蔀椴煌愋偷娜蝿仗砑痈嚓犃?。還可根據資源與需求比添加更多資源。

8.4 容錯性

任務在首次發(fā)送執(zhí)行時不會從隊列中刪除。如果執(zhí)行失敗，將嘗試最大允許次數(shù)的重試。若任務包含死循環(huán)，會在指定時間后終止任務并通知用戶。

參考：

• 編程嚴選網

本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！文章來源地址http://www.zghlxwxcb.cn/news/detail-747811.html

到了這里，關于系統(tǒng)設計面試指南之分布式任務調度的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！