系統設計面試：如何隔離多租戶服務中的噪聲租戶並實現公平調度？

題幹與適用場景

題目核心是效能隔離和公平性，不是簡單地給每個租戶加一個 tenantId。系統接收非同步報告任務，任務可能消耗佇列、CPU、資料庫掃描、物件儲存和下載頻寬；月底突發會讓少數租戶成為噪聲源。回答需要先定義服務等級，再說明共享與隔離的邊界。

假設租戶必須只能讀取自己的資料，報告允許非同步完成，短暫延遲比跨租戶資料洩露更可接受。企業租戶可能有不同套餐、區域和保留策略；合規、資料駐留和專用容量是需要先釐清的硬約束。不要把「公平」誤解成所有租戶永遠獲得相同吞吐，高優先級合約和安全任務可以擁有明確、可稽核的權重。

適用對象包括後端、平台、SRE 和系統設計職位。AWS 的 shuffle sharding 資料把隔離視為多租戶服務的核心模式；公開系統設計面試材料也把租戶隔離、資源配額和噪聲鄰居列為常見考察點。本題更聚焦調度與爆炸半徑，而非完整 SaaS 功能。

面試官考察點

第一，能否先定義隔離對象和服務目標。租戶身份、任務、佇列、worker、資料庫連線、快取、物件儲存和下載頻寬都可能共享；只隔離入口而不隔離下游，噪聲仍會穿透。

第二，能否區分配額、公平調度和硬隔離。租戶級令牌桶限制總量，公平佇列決定誰先執行，分片或專用池限制故障範圍；三者解決的問題不同。

第三，能否處理大租戶與小租戶的成本權衡。完全獨占會增加閒置容量和維運複雜度，完全共享又容易出現資源爭搶；強回答會給出分層策略和遷移觸發器。

第四，能否驗證隔離真的成立。指標需要按租戶、佇列和資源層觀察延遲、拒絕、排隊年齡、配額消耗、重試和丟棄，而不是只看全局平均值。

回答前需要釐清的問題

• 服務等級如何定義？ 互動查詢和非同步報告的 p95、最大等待時間、成功率、區域可用性是什麼？
• 哪些任務必須優先？ 合約等級、人工緊急任務、定時報告和普通探索任務是否有不同權重？
• 資料與資源邊界是什麼？ 是否需要獨立資料庫、區域、加密金鑰、物件儲存或專用 worker？
• 突發和長期配額如何計算？ 關注提交速率、並發任務、掃描位元組、CPU 時間、儲存量還是下載頻寬？
• 使用者如何感知排隊和拒絕？ 是否有預計完成時間、重試建議、配額解釋和管理員報表？

30 秒回答框架

「我先定義每個租戶和套餐的延遲、成功率、並發和資料隔離目標，區分提交配額、執行並發和下游資源預算。入口驗證認證租戶、任務大小和冪等鍵，把任務寫入持久佇列；調度器按租戶令牌桶和加權公平佇列出隊，熱點租戶必要時使用獨立或 shuffle-sharded worker 池。資料庫掃描、快取、物件儲存和下載頻寬也按租戶計量，不能只隔離佇列。過載時拒絕或延後低優先級任務，保留誠實狀態和取消能力。最後用跨租戶存取測試、噪聲注入、故障演練和按租戶 p99 指標驗證公平性、爆炸半徑和恢復。」

分步驟深入解答

第一步：定義資源和服務等級

把一次報告拆成提交、排隊、查詢、生成、寫入物件儲存和下載。為每一步定義可承諾的指標，例如提交介面 p95、排隊年齡、完成時間、下載成功率和資料隔離。把 CPU、記憶體、資料庫掃描、連線數、佇列槽位、物件儲存請求和出口頻寬列為預算，避免只給 worker 數量。

第二步：建立可信租戶上下文

租戶身份來自認證憑據和伺服器授權，不能信任請求體中自填的 tenantId。任務、佇列訊息、資料庫查詢、物件路徑、快取鍵和下載權杖都要攜帶經過驗證的租戶上下文。報告輸入還要限制欄位、時間範圍和最大掃描，避免合法租戶用超寬查詢耗盡共享資源。

authenticated principal
  -> authorize tenant and report definition
  -> assign quota class and priority
  -> enqueue {tenantId, taskId, costEstimate, deadline}
  -> every worker and storage call re-checks tenant scope

第三步：選擇隔離層級

小租戶可以共享佇列和 worker，但必須有租戶級配額、並發上限和公平調度。高流量或高合規租戶可以使用獨立佇列、分區、資料庫 schema、加密金鑰或 worker 池。AWS 的 shuffle sharding 將每個租戶映射到多個 worker 的組合，讓單個 worker 故障只影響部分租戶；它比單一共享池有更小的爆炸半徑，同時保留一定共享效率。

第四步：設計配額和公平調度

提交速率令牌桶限制入口突發，執行並發限制在途任務，成本預算限制掃描位元組或 CPU 時間。調度器使用加權公平佇列或每租戶虛擬佇列，避免一個租戶連續佔滿 worker；同一租戶內再按任務優先級、截止時間和年齡排序。拒絕要返回可解釋的暫時過載或配額狀態，不能讓客戶端無限重試。

第五步：保護下游資源

調度器取得資料庫、快取和物件儲存的獨立預算後才啟動任務。報告查詢使用只讀副本、時間範圍和最大掃描限制；結果寫入按租戶和區域分區，下載使用短期授權。連線池、快取、執行緒和出口頻寬若仍是全局共享，入口公平也無法阻止下游飢餓，因此要為關鍵依賴設定並發上限和有界佇列。

第六步：處理突發、失敗和恢復

佇列必須持久化任務狀態、租戶配額快照、冪等鍵和取消標記。worker 崩潰後任務可重試，但要避免重複寫結果；用任務版本或冪等結果鍵提交。下游不可用時暫停受影響類別、保留佇列年齡和預計完成時間，避免全量重試風暴。恢復時逐步增加每個租戶的准入，觀察 p99、錯誤率和配額，而不是瞬間放開所有積壓。

第七步：擴容、遷移和驗證

擴容根據有效吞吐、佇列年齡、資源利用率和租戶權重計算，不只看平均 CPU。租戶從共享池遷移到獨立分片時，保持任務狀態和結果路徑的冪等，先小比例切換再回滾。驗證包括跨租戶授權、噪聲注入、單 worker 故障、資料庫變慢、佇列恢復、取消和大租戶遷移；每個測試都要檢查其他租戶是否仍滿足目標。

高品質示範回答

「我會先把報告拆成提交、排隊、查詢、生成、儲存和下載，並為每一步定義延遲、成功率和資料隔離目標。租戶身份來自認證上下文，伺服器重新授權報告定義；請求體裡的租戶欄位只能作為輸入，不能作為邊界。任務寫入持久佇列，帶租戶、成本估算、冪等鍵和截止時間。

小租戶共享 worker，但每個租戶有提交速率、在途並發、掃描位元組和儲存配額。調度器用加權公平佇列和年齡優先，讓一個租戶的月底突發不能連續佔滿 worker。高流量或高合規租戶可以進入獨立佇列、分區或 shuffle-sharded worker 池，降低單個 worker 故障和熱點的爆炸半徑。資料庫連線、快取、物件儲存和出口頻寬也要設定租戶級或類別級預算。

超限時我會返回可解釋的排隊或暫時過載狀態，支援取消，禁止客戶端無限重試。worker 重試使用冪等結果鍵，狀態機防止重複寫報告；下游故障時只暫停受影響任務，恢復時按租戶和優先級逐步放量。

驗證方面，我會用跨租戶存取測試、一個租戶的突發注入、worker 和資料庫故障、佇列重放、取消和遷移演練，觀察每個租戶的 p99、佇列年齡、拒絕率、資源消耗和資料洩露斷言。只有在小租戶和高等級租戶都滿足目標後，才擴大隔離池或調整權重。」

常見錯誤

• 只在請求中相信 tenantId → 偽造租戶即可越權 → 從認證上下文派生並在下游複核。
• 每個租戶固定一個 worker → 閒置容量高且故障仍可能擴大 → 按風險分層，必要時使用組合分片。
• 只限制提交速率 → 在途任務仍佔滿下游 → 同時限制並發、成本和依賴資源。
• 用全局平均值判斷公平 → 小租戶的尾延遲被掩蓋 → 按租戶記錄 p95、p99、排隊和拒絕。
• 過載時無限重試 → 重試放大並拖垮服務 → 返回明確狀態、冪等重試和共享預算。
• 只擴 worker 不擴資料庫預算 → 下游成為新瓶頸 → 對每層資源做端到端預算。
• 恢復時一次性放開積壓 → 再次形成峰值 → 使用滯回和逐步准入。
• 遷移沒有冪等狀態 → 任務重複執行或結果遺失 → 用版本、結果鍵和可回滾切換。

追問及應對

追問 1：shuffle sharding 和普通分片有什麼區別？

普通分片通常把租戶放進一個固定分片；該分片故障會影響其中所有租戶。shuffle sharding 把每個租戶映射到多個 worker 的組合，不同租戶的組合重疊較少，因此單個 worker 故障的影響範圍更小，但需要處理容量、重平衡和熱點遷移。

追問 2：高等級租戶是否可以繞過公平佇列？

可以有明確、付費或合約約定的權重，但仍受系統總容量、資料隔離和安全邊界限制。為高等級租戶保留預算時，要記錄普通租戶的最低服務目標，避免「優先」變成無限搶佔。

追問 3：一個報告掃描全表怎麼辦？

在解析和計畫階段估算掃描成本，要求時間範圍、限制最大位元組和並發；超出預算就拆分、非同步、延後或拒絕。只給資料庫更大的連線池會把查詢壓力傳到儲存，不能作為唯一修復。

追問 4：如何證明沒有跨租戶資料洩露？

用認證主體建立跨租戶存取矩陣，覆蓋 API、佇列重放、worker、快取、物件路徑、匯出和管理員工具；加入負向測試，確認缺失或偽造租戶上下文預設拒絕，並對真實結果做租戶標籤和內容斷言。