https://yennj12.js.org/yennj12_blog_V4/tags/multitenant/Recent content in MultiTenant on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-12-backpressure-fair-share-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-12-backpressure-fair-share-zh/核心定義：Backpressure 是下游受限資源（GPU 配額、LLM 速率上限）主動向上游發出「放慢」訊號的機制；Fair-Share 排程確保在削峰過程中每個租戶仍獲得保證的最低吞吐量，讓流量尖峰不會讓任何單一租戶將其他人餓死。 一、為什麼面試官問這個 多租戶 AI 平台的核心挑戰不是「如何服務單一大客戶」，而是「如何讓 500 個中小租戶與 5 個企業租戶共存，同時保證 SLA」。面試官用這個題目測試三件事： 系統思維：你是否理解流量從 API Gateway → Queue → Worker → LLM 整條鏈的壓力傳導方式，而不只是會設定 nginx rate limit。拿到這類題目，強答案一定會在 2 分鐘內畫出流量路徑，標明每個節點的限速機制。 數字直覺：Redis Token Bucket 0.5 ms vs DB-based 15 ms；在 50K req/s 的規模下，這個差距決定了你的 rate-limit 層是否成為系統瓶頸。能說出這個數字，代表你有實際操作過，不是只讀過文件。 公平性設計：高付費租戶應優先，但「優先」不等於「獨占」。能說清楚 floor rate 與 burst allowance 的區別，以及它們如何透過獨立 worker pool 實現隔離，才算真正懂多租戶設計。 弱答案長這樣：「我會用 nginx 的 limit_req 或 API Gateway 的 quota 設定來限速，超限就回 429。」— 這只說到最表層；沒提 Token Bucket 內部機制、Redis 的原子性問題、Pub/Sub 作為無限緩衝的作用，也沒有 Fair-Share 的 weighted queuing 概念。