Microsoft Fabric 中的限速

當工作負載超過容量或 REST API 請求限制時，Microsoft Fabric 會使用限速來維持服務效能與可靠性。 本文說明限速機制如何運作、如何解讀 HTTP 429 回應，以及如何設計能有效處理 Fabric API 配額的應用程式。

API 配額限制

Microsoft Fabric 正在為其 REST API 推出統一配額（Unified Quota for REST API）。 在此模式下，API 請求由每位使用者或 服務主體強制執行的身份層級配額來管理。

目標是為受管控的 API 群組提供 一致且可預測的限速體驗 ，涵蓋自動化、CI/CD 及代理驅動場景。

過去，每個 Microsoft Fabric REST API 都強制執行獨立的限速規則，導致端點間行為不一致。 因此，預測工作負載何時會被限速變得困難，尤其是在涉及多個 API 且受不同限制限制的自動化情境中。

隨著 API Quota 的引入，Fabric 正朝向更一致、以身份為基礎的方法發展。 API 使用現由統一配額管理，並依身份強制執行，提供更清晰且可預測的 Fabric API 限速模型。 不過，值得注意的是，除了整體 API 配額外，某些個別 API 專屬的限速限制仍可能適用。

Note

API Quota 的存在純粹是用來管理和限制 API 請求。 它不代表 Fabric 的運算、儲存或計費容量，也不會影響你的 Fabric 容量消耗或成本。

當 API 參考頁面記錄配額時，將該端點特定的限制視為該 API 的權威。 如果 API 參考頁面沒有列出數值配額，請設計你的應用程式來處理 429 個回應，透過尊重 Retry-After、 應用有界重試並避免突發 s 來處理。

配額模型的運作原理

配額如何流動的概念示意圖。

每個身份——無論是使用者還是服務主體——都會被分配多個獨立的配額桶，管理不同類別的 API 流量。 當身份發送請求時，該請求會根據所使用的 API 類別的配額進行評估。

有三個統一配額：

  1. 平台 API 統一配額 — 專供平台 API 使用。
  2. 作業排程器 API 的統一配額 — 專門用於作業排程器 API。
  3. 長時間執行作業 API 的統一配額 — 專供長時間執行作業 API 使用。
Quota 極限
平台 API 統一配額 每分鐘500通電話
工作排程器 API 的統一配額 每分鐘200通電話
長時間執行作業 API 的統一配額 每分鐘500通電話

由於這些配額是獨立的，一個類別的活動不會消耗另一個類別的配額。 例如，服務主體可以完整使用其工作排程器 API 的統一配額，而不會影響其可用的平台統一配額。 這種分離確保了專門 API 領域的高負載不會影響一般 API 操作，並允許不同類型請求間更可預測的限速行為。

API 強制執行機制

API 配額是以每個身份為單位強制執行，意即每個使用者、服務主體或受管理身份都會獲得獨立的配額分配。 配額不會在身份間共享，所有符合資格的 Fabric API 都會從該身份相關的共同配額桶中消費。

因此，一個身份的 API 使用不會影響其他身份。 例如，一個高頻率使用的服務主體可以用盡自己的 API 配額，而不會影響其他使用者或應用程式的配額。

同樣地，若某身份達到配額上限並被限速，該限速僅適用於該身份，其他身份則繼續正常運作。 這種隔離性讓不同工作負載的 API 消耗更具可預測性與可控性。

配額執行階層

配額階層的概念圖。

每個 API 請求都以一個身份開始——可能是使用者帳號或服務主體。 當該身分呼叫 Fabric API 時，該要求會先耗用共用 API 配額中的容量，而此配額是依身分識別而非依個別 API 強制套用。 此配額作為集中式限速機制，在所有參與 API 間共享，確保單一身份不會超過其分配的請求速率。

在根據共享 API 配額評估請求後，任何 API 專屬的限速限制也會被套用。 這些限制與共享配額無關，可能僅適用於特定 API。 因此，請求必須同時符合身份層級 API 的配額及任何適用的個別 API 限制，才能成功處理。

實際上，共享 API 配額在各 API 間提供一致的限速體驗，而個別 API 限制則持續保護需要額外防護的特定服務。 因此，API 呼叫可能會被限速，可能是因為身份已用盡共享配額，或是達到特定 API 端點的極限。

關鍵概念：

  • 依身分識別強制執行：系統會分別追蹤每位使用者或服務主體的配額。
  • 跨 API 共享：對不同 API 的請求會消耗同一個 API 的配額池。
  • 僅限速率限制：API 配額會控制請求速率，但不會影響授權或權限。
  • 雙重強制：每個請求都會評估共享 API 的配額及任何 API 專屬限制。
  • 限制最嚴格的限制勝出：當請求超過共享配額或適用的 API 特定限制時，請求會被限速。

配額的消耗方式

每個 API 請求都會消耗呼叫身份的 API Quota 桶中的配額。 該身份所發出的所有請求，無論呼叫哪個 API，都會計入相同的共享配額。

配額期間與更新

API配額以固定的60秒窗口強制執行。 當目前時間窗結束時，配額桶會一次補滿。 配額不會在窗口期間逐步恢復。

Note

若身份在視窗開始時用盡全部配額，則在下一個 60 秒視窗開始前，無法再提出額外請求。

時間軸範例

Second 0   → Quota window begins. Bucket is full (300 requests available).
Second 1   → 300 requests are made. Bucket is exhausted.
             Additional requests receive HTTP 429 (Too Many Requests).

Seconds 2-59 → All additional requests continue to receive HTTP 429.
               No quota is restored during the window.

Second 60  → New quota window begins.
             Bucket is fully replenished (300 requests available).
             Requests are accepted again.

實務意涵

  • 允許在時間窗口開始時集中送出大量要求，但這樣做可能會導致該身分在該時間窗口的剩餘期間遭到節流。
  • 將請求平均分散在 60 秒期間內，有助於避免節流。
  • 一定要尊重 Retry-After 回應標頭。 它指出重新嘗試受節流限制的要求之前，應等待多久。

依 API 分類的速率限制細節

雖然 Microsoft Fabric 提供統一的限速類別與共享配額概念，但實際速率限制會因 API 而異。 請務必查看你所呼叫的特定 API 的「節流限制」章節。

Note

請務必查看你所呼叫的特定 API 的「節流限制」章節。

節流訊息

當發生限速時，Fabric 會回傳 HTTP 狀態碼 429（請求過多）。 Fabric 會因兩種不同的原因而傳回 429 狀態碼，每一種原因都可由回應本文中不同的 errorCode 識別：

檢查 errorCode 回應中的數值，以判斷發生了哪種狀況以及如何回應。

速率超過（請求被封鎖）

當使用者在某個時間窗口內發送超過預定限制的多次請求時，Fabric 會在短時間內限制該使用者的進一步請求。

此時，Fabric 會回傳一個 HTTP 狀態碼 429（請求過多），回應中附有 Retry-After HTTP 標頭，指示呼叫應用程式應等待多久才能重試呼叫。 回應體使用 RequestBlocked 錯誤代碼：

{
    "errorCode": "RequestBlocked",
    "message": "Request is blocked by the upstream service until: 2/18/2026 10:45:04 PM (UTC)"
}

當你收到這個錯誤時，請等到標頭中 Retry-After 指定的時間再重新嘗試請求。

以下截圖顯示一個回應範例，建議使用者等待 55 秒後再嘗試通話。

顯示 HTTP 回應標頭的螢幕快照。

容量上限超過（容量上限超額）

當您的組織 Fabric 容量超過限制時，Fabric 也會回傳 HTTP 狀態碼 429（請求過多）。 與速率限制不同，這種限速並非由特定呼叫者呼叫的 API 次數造成。 而是當你的運算（容量單位）超過購買的 Fabric SKU 的限制時，才會發生。 回應體使用 CapacityLimitExceeded 錯誤代碼：

{
    "errorCode": "CapacityLimitExceeded",
    "message": "Your organization's Fabric compute capacity has exceeded its limits. Try again later."
}

當您收到此錯誤時，請稍後再試一次。 由於這種限速取決於你容量所消耗的總計算量，而非個別請求速率，立即重試不太可能成功，直到容量的運算使用量回落到限制範圍內。 如果你經常遇到這個錯誤，可以考慮擴大或縮小你的 Fabric 容量。 欲了解更多容量單位、SKU 及 Fabric 容量的消耗方式，請參閱「規劃您的容量規模」。

考慮事項與限制條件

每個 Fabric 管理 API 和核心公開 API 都可能受到節流限制。

設計呼叫 Fabric REST API 的應用程式時，請牢記以下考量：

  • 系統會根據呼叫端身分與所呼叫的 API 強制執行配額。 不同的身份不一定共享相同的請求計數器，但每個呼叫者仍必須遵守 API 的官方限制。
  • 許多速率限制會以一分鐘為區間進行評估。 如果你超出限制，請等到 Retry-After 值後再發送更多請求。
  • 容量限速與請求速率限速不同。 CapacityLimitExceeded表示 Fabric 容量過載，而非呼叫者超過每分鐘 API 配額。
  • 立即重試降頻錯誤成功的可能性不大。 使用有界重試策略，若錯誤持續發生，請調查容量使用狀況。
  • 對於大量整合，若有清單、大量或批次作業可用，應優先採用，快取不常變動的中繼資料，並將請求平均分散到不同時間點。
  • 對於支援分頁的 API，請使用接續權杖，而不要每次都從頭開始重複進行大範圍查詢。

常見問題

我怎麼知道自己是達到 API 配額還是容量上限？

請查看429回應正文中的部分 errorCode 。 RequestBlocked 表示請求速率超過服務的限速限制。 CapacityLimitExceeded表示 Fabric 容量所消耗的運算超出購買 SKU 的限制。

我的配額什麼時候會重置？

許多 Fabric REST API 的速率限制是以一分鐘為單位的時間窗來評估。 如果回應包含 Retry-After 標頭，請將該值作為權威等待時間，然後再嘗試。

我可以在提出請求前先確認剩餘的 API 配額嗎？

Fabric REST API 回應並未提供所有 API 的通用剩餘配額計數器。 建立客戶端，使其能偵測 429 回應、尊重 Retry-After並減少限速時的請求量。

我該如何降低被限速的機率？

在可用時使用批量和批次作業，優先使用列表 API，而不是多次呼叫單一資源，快取經常存取的中繼資料，並避免流量突然暴增。 對於持續性容量限流，請使用 Microsoft Fabric 容量指標應用程式來識別超載容量與工作負載。

我是否應該以相同的方式重試每個 429 回應？

No. 針對 RequestBlocked，請等待 Retry-After 標頭，然後以具上限的重試策略重試。 對於 CapacityLimitExceeded，稍後再嘗試指數退讓，若問題持續，則調查容量利用率。

相關內容

  • 上次更新時間：