系統設計面試：如何為控制面 API 設計優先級與公平調度？
題幹與適用情境
控制面 API 同時承載健康檢查、控制器寫入、租戶查詢與長時間 watch。突發流量或單一租戶的失控請求會拖慢所有請求。請設計一套優先級與公平調度機制，說明分類、並發上限、排隊、逾時與降級如何協同。
面試官考察什麼
- 能否把「重要」轉成可稽核的請求分類，而不是給某個團隊永久特權。
- 能否用並發席位、佇列與配額保護控制面，而不只是在入口加限流器。
- 能否解釋公平的粒度、長請求占用、租戶隔離與故障時的降級。
- 能否用延遲、拒絕率、佇列年齡與控制器恢復時間驗證方案。
回答前要釐清的問題
- 哪些請求是安全關鍵寫入，哪些是可延後的讀取或 watch？
- 公平按租戶、身分、工作負載或資源類型計算？是否允許管理員緊急通道？
- 目標是保護 API server、下游資料庫，還是兩者都要保護？
- 長請求是否消耗多個並發席位，中斷後如何釋放？
- 超載時可以回傳 429，還是必須保留部分成功率與重試提示？
30 秒回答框架
我會先按身分、動詞與資源把請求映射到有限的優先級流，再為每條流設定並發席位與公平佇列。高優先級只取得有上限的保底容量，低優先級在壓力下排隊或拒絕。長請求獨立分類並計入持續占用，所有拒絕都帶可操作的重試訊號。最後用 p99、佇列年齡、429 比例、下游飽和度與關鍵控制器恢復時間作為閘門。
分步深入解答
第一步：建立可解釋的請求分類
分類鍵應來自可驗證的身分、HTTP 動詞、目標資源與請求是否長時間執行。不要讓客戶端任意提交「高優先級」欄位。將控制器寫入、節點心跳、管理員查詢與批量列出拆成不同流，並記錄命中規則。
第二步：把容量建模為席位
用席位表示同時占用的服務能力，而不是只按請求數計算。快速查詢可占一個席位，慢查詢或 watch 需要更多席位，完成或取消時釋放。每條優先級設定 nominal limit，同時保留總席位上限，避免各流保底相加超過實際容量。
第三步：在每條優先級內做公平排隊
同一優先級內再按租戶或流識別做加權公平佇列，防止單一租戶填滿該優先級。調度器選擇有等待請求且未超過 current limit 的流；連續逾時的請求提高年齡權重，但不能繞過全局席位上限。
第四步：處理長時間請求與下游依賴
watch、日誌尾讀等請求應有獨立預算、最大持續時間與心跳取消。對資料庫、快取或外部服務設定獨立艙壁；入口佇列不能把壓力無限傳給下游。重試只用於可重試錯誤，並使用指數退避與抖動。
第五步：定義超載動作
壓力升高時先暫停低優先級新請求，再限制批量列出與昂貴過濾，最後對無法排隊的請求回傳 429。回應應攜帶明確等待提示，客戶端也必須設定重試上限、抖動與截止時間。安全關鍵寫入若不能接受丟棄，應進入持久佇列並回傳可查詢的操作 ID。
第六步：觀測公平性而非只看平均延遲
按優先級、租戶、請求類型分別監控 p50、p99、佇列年齡、席位占用、429、取消與下游錯誤。加入最大等待時間、關鍵寫入成功率、恢復時間與租戶間服務差異的告警。壓測要涵蓋單租戶洪峰、長請求占滿、規則誤分類與控制器恢復。
第七步：安全演進與回滾
先以只觀測模式記錄新分類命中，再逐步啟用限額。配置版本要可稽核、可回滾，並保留緊急但受限的運維通道。改變席位或優先級時同時比較下游容量與歷史佇列分布，避免只看 API 層指標。
高品質示範回答
我會把控制面容量建模成全局席位池，按身分、動詞、資源與長時間屬性把請求映射到優先級流。控制器寫入與節點心跳有保底席位，但保底總和不超過安全容量；普通租戶查詢在同一優先級內按租戶做公平佇列。watch 單獨計費並有最長持續時間，中止時立即釋放席位。負載升高時依次暫停批量讀取、限制昂貴過濾，對無法排隊的請求回傳 429 與等待提示；寫入若必須完成則落到持久佇列。上線前記錄分類命中與各租戶佇列年齡，啟用後以關鍵寫入成功率、p99、429、下游飽和度與恢復時間做回滾閘門。
常見錯誤
- 只設定全局 QPS，導致長請求仍能耗盡並發。
- 把管理員或某個租戶設為無限優先級，造成不可稽核的飢餓。
- 只按請求數計費，不區分快查詢、列出與 watch 的資源占用。
- 讓所有客戶端立即重試 429，形成同步重試風暴。
- 只看平均延遲，忽略低優先級佇列的最大等待時間。
- 修改限額時沒有灰度、版本與回滾路徑。
追問及應對
追問一：為什麼不能只用令牌桶？
令牌桶限制進入速率，卻不表達不同請求的並發成本、長請求占用或租戶間公平。它可作為入口層的一部分，但需要席位與佇列補足。
追問二：高優先級會不會餓死低優先級？
會，除非高優先級也有上限，並在其內部與全局設定保留比例、最大連續服務量或老化策略。緊急通道必須受稽核與容量約束。
追問三：watch 應該算幾個席位？
不能固定回答。應以連線數、事件速率、序列化成本與下游查詢壓力測量，給出保守基線並透過壓測校準；逾時與斷線必須釋放席位。
追問四：429 的重試時間由誰決定？
服務端根據預計恢復時間給出最小等待提示，客戶端再疊加指數退避、抖動與截止時間。提示不是容量保證，客戶端仍要限制重試次數。
追問五：如何證明公平？
定義租戶級服務目標，例如同一優先級內的席位份額、最大佇列年齡與完成率，並在單租戶洪峰與混合負載下比較分布，而不是只報告全局平均。
追問六：規則誤把關鍵寫入歸到低優先級怎麼辦？
先保留規則命中日誌與人工稽核，配置以版本化方式發布；發現關鍵寫入成功率下降時立即回滾分類版本，並保留受限的安全通道處理存量任務。