題干與適用場景
共享計算叢集同時承載互動任務、批次與可搶占訓練作業。租戶可以突發提交，但不能無限佔用 CPU、記憶體或 GPU；高優先級工作需要較短等待，低優先級租戶也不能永久飢餓。
請設計佇列、資源帳本、調度策略、搶占與恢復流程。Kubernetes 將 PriorityClass、ResourceQuota 與搶占分開建模；IETF 佇列管理資料也指出公平調度與壅塞控制需要共同約束，不能只靠全域 FIFO。
面試官考察點
- 是否區分租戶配額、作業優先級與節點可行性。
- 是否能提出不讓低優先級作業永久飢餓的公平規則。
- 是否限制搶占副作用、重試放大與資源碎片。
- 是否處理調度器故障、重複派發與作業恢復。
- 是否用租戶指標證明公平，而非只看平均利用率。
回答前需要澄清的問題
- 資源是 CPU、記憶體、GPU，還是帶本地磁碟的異質節點？
- 配額按租戶、專案、佇列還是組織層級計算？
- 優先級是否允許搶占，檢查點恢復成本多高？
- 作業是否可拆分、取消、重試？結果寫入是否冪等？
- 公平目標是最大最小份額、加權份額，還是等待時間上限？
30 秒回答框架
我會為每個租戶維護資源配額、目前使用量與可借用額度，把工作放入按租戶分層的佇列。調度器先過濾節點約束，再用加權公平或最小虛擬完成時間選擇租戶；等待時間增加有效優先級，避免飢餓。只有明確允許搶占且受配額保護時才驅逐低優先級作業。所有分配帶租約與 fencing token，重啟後從持久狀態重建，指標按租戶、佇列與資源類型驗證。
分步驟深入解答
第一步：建立資源與配額帳本
把 CPU、記憶體、GPU 與節點標籤建成可計算的資源向量。租戶配額限制長期佔用，突發額度設過期時間；調度前原子預留，完成、取消或租約失效時歸還。入口與調度器都要檢查配額，避免直接建立高優先級工作繞過限制。
第二步：分層佇列與公平選擇
先按組織、租戶與工作類別分層，再在可執行租戶間按權重選擇。記錄每個租戶的虛擬服務量或近期資源使用，選擇欠服務租戶；等待超過門檻後增加老化分數。全域 priority queue 可能讓大租戶持續佔據隊首，租戶輪轉才能寫出公平邊界。
第三步：優先級、借用與搶占
優先級表達業務緊急度，不自動授予無限資源。租戶只能在全域閒置容量或明確借用窗口內超額執行。搶占前計算釋放量、檢查點成本與受害者預算；優先選擇低優先級且可恢復作業。無法證明恢復安全時，讓高優先級工作等待更安全。
第四步：節點過濾與碎片控制
先過濾架構、GPU 型號、區域、親和性與容量，再排序剩餘節點。大工作與小工作混在同一佇列會產生碎片；可為大資源請求保留有限預留池並設定等待上限。調度記錄拒絕原因，區分總容量不足、形狀不合與配額耗盡。
第五步：派發、租約與冪等恢復
調度器寫入帶版本的 reservation，工作節點領取短租約並攜帶 fencing token。重複派發時，執行器用 (job_id, attempt) 做冪等檢查；租約過期只允許新 token 接管。結果提交後才釋放預留，調度器重啟從日誌或資料庫重建未完成任務。
第六步：故障、取消與重試
節點失聯先標記未知，再依租約和心跳窗口決定回收。可恢復作業從檢查點重試，非冪等副作用必須查詢狀態或補償。重試消耗租戶與工作預算，使用退避和上限；恢復後禁止把所有逾時任務同時重派。
第七步：容量擴展與策略變更
增加節點或修改權重時發布版本化策略，保留舊策略處理已入隊任務，逐步遷移新任務。權重變化不能讓租戶瞬間失去已承諾份額。GPU、區域與本地磁碟等稀缺資源分別統計，借用與回收都記錄稽核事件。
第八步：驗證公平與效率
用合成租戶和真實工作混合壓測：一個租戶持續滿載、多個租戶低速提交、節點隨機失聯、檢查點恢復與策略熱更新。觀察每租戶等待 p50/p95、資源份額、最大連續飢餓時間、搶占次數、重複執行、佇列年齡、碎片率與恢復時間，並比較 FIFO、純優先級與公平策略。
高品質示範回答
我會把配額、優先級與節點可行性拆成三階段。租戶佇列用加權欠服務量選擇，等待增加老化分數；借用只使用有期限的閒置額度，搶占必須檢查可恢復性、配額與檢查點成本。每次分配持久化 reservation、租約與 fencing token，結果按 attempt 冪等提交。調度器從日誌恢復，重試有租戶預算，壓測則按租戶等待、份額、飢餓、重複執行、碎片與恢復時間判斷。
常見錯誤
- 只用全域優先佇列 → 大租戶長期佔據隊首 → 先選租戶，再選租戶內工作。
- 把配額當優先級 → 高優先級繞過邊界 → 配額檢查獨立且原子。
- 無限搶占 → 檢查點、重複副作用和抖動失控 → 設預算與冷卻時間。
- 只靠記憶體佇列 → 重啟後重複或丟失派發 → 持久化 reservation 與 token。
- 只看全域平均 → 局部租戶可能飢餓 → 記錄租戶等待和份額分布。
- 節點失聯立即重試 → 舊執行可能仍在跑 → 等 fencing 或走冪等路徑。
追問及應對
如何證明不會飢餓？
為每個可執行租戶保留最小服務份額，老化分數設上界；在固定容量和持續可調度假設下監控最大等待是否受策略上限約束。
搶占後如何避免重複扣費？
把計費綁定邏輯工作或成功階段，而非每次嘗試；外部副作用使用冪等鍵和狀態查詢。
配額與閒置資源衝突怎麼辦？
允許有期限借用並記錄可回收額度。配額恢復時先停止新借用，再等待工作結束或按策略搶占可恢復工作。
調度器需要強一致嗎？
reservation、租約與 fencing 需要線性化條件更新；統計和排行榜可非同步。不能讓最終一致快取決定最後一塊 GPU 的分配。
什麼時候不用公平調度？
單租戶、固定批次窗口或嚴格優先級且業務接受飢餓時，簡單優先佇列更易驗證。
哪個訊號會觸發回滾？
若重複執行、搶占恢復失敗、最大等待超標或租戶份額偏離預算，停止新策略，恢復舊版本並保留 reservation 日誌重放。