Drosselung in Microsoft Fabric

Microsoft Fabric verwendet Drosselung, um die Leistung und Zuverlässigkeit des Diensts aufrechtzuerhalten, wenn Workloads Kapazität oder REST-API-Anforderungsgrenzwerte überschreiten. In diesem Artikel wird erläutert, wie die Drosselung funktioniert, wie HTTP 429-Antworten interpretiert werden und wie Sie Anwendungen entwerfen, die Fabric API-Kontingente effektiv verarbeiten.

API-Kontingentbeschränkungen

Microsoft Fabric führt einheitliches Kontingent für REST-APIs für seine REST-APIs ein. Unter diesem Modell werden API-Anforderungen durch Kontingente auf Identitätsebene gesteuert, die pro Benutzer oder Dienstprinzipal erzwungen werden.

Das Ziel ist eine konsistente, vorhersagbare Drosselungserfahrung für die gesteuerten API-Gruppen über Automatisierungs-, CI-/CD- und agentgesteuerte Szenarien hinweg.

Zuvor hat jede Microsoft Fabric REST-API ihre eigenen unabhängigen Einschränkungsregeln erzwungen, was häufig zu inkonsistenten Verhaltensweisen über Endpunkte hinweg führte. Daher war es schwierig, vorherzusagen, wann eine Workload gedrosselt werden könnte, insbesondere für Automatisierungsszenarien, die mit mehreren APIs interagierten und unterschiedlichen Grenzwerten unterliegen.

Mit der Einführung von APIs Quota wechselt Fabric zu einem konsistenteren, identitätsbasierten Ansatz. Der API-Verbrauch wird jetzt durch ein einheitliches Kontingent gesteuert, das pro Identität erzwungen wird und ein klareres und vorhersagbareres Drosselungsmodell über Fabric-APIs hinweg bereitstellt. Es ist jedoch wichtig zu beachten, dass zusätzlich zur allgemeinen API-Quote weiterhin einige API-spezifische Drosselungsgrenzen gelten.

Hinweis

Das API-Kontingent dient ausschließlich dazu, API-Anfragen zu steuern und zu drosseln. Sie stellt keine Fabric Berechnungs-, Speicher- oder Abrechnungskapazität dar und hat keine Auswirkungen auf den Fabric Kapazitätsverbrauch oder die Kosten.

Wenn eine API-Referenzseite ein Kontingent dokumentiert, behandeln Sie diesen endpunktspezifischen Grenzwert als autoritativ für diese API. Wenn auf einer API-Referenzseite kein numerisches Kontingent angegeben ist, konzipieren Sie Ihre Anwendung so, dass sie 429-Antworten unter Beachtung von Retry-After verarbeiten kann, begrenzte Wiederholungsversuche anwendet und Lastspitzen vermeidet.

Funktionsweise des Kontingentmodells

Schematische Darstellung des Kontingentflusses.

Jede Identität – entweder ein Benutzer oder ein Dienstprinzipal – wird mehreren unabhängigen Kontingent-Buckets zugewiesen, die unterschiedliche Kategorien von API-Datenverkehr steuern. Wenn die Identität eine Anforderung sendet, wird die Anforderung anhand des Kontingents für die verwendete API-Kategorie ausgewertet.

Es gibt drei einheitliche Kontingente:

  1. Einheitliches Kontingent für Plattform-APIs – ausschließlich für Plattform-APIs vorgesehen.
  2. Einheitliches Kontingent für Auftragsplanungs-APIs – speziell für Auftragsplaner-APIs.
  3. Einheitliches Kontingent für APIs für lang laufende Vorgänge – ausschließlich für APIs für lang laufende Vorgänge.
Kontingent Limit
Einheitliches Kontingent für Plattform-APIs 200 Anrufe/Min.
Einheitliches Kontingent für Auftragsplanungs-APIs 200 Anrufe/Min.
Einheitliches Kontingent für Long-Running Operations-APIs 200 Anrufe/Min.

Da diese Kontingente unabhängig sind, verbraucht die Aktivität in einer Kategorie kein Kontingent aus einer anderen Kategorie. Beispielsweise könnte ein Dienstprinzipal sein vollständiges einheitliches Kontingent für Auftragsplanungs-APIs nutzen, ohne dass sich dies auf das verfügbare einheitliche Kontingent für Plattform-APIs auswirkt. Diese Trennung stellt sicher, dass hochvolumige Workloads in spezialisierten API-Bereichen keine Auswirkungen auf allgemeine API-Vorgänge haben und ein vorhersehbares Drosselungsverhalten für verschiedene Arten von Anforderungen ermöglicht.

API-Durchsetzung

Das APIs-Kontingent wird auf Identitätsbasis erzwungen, was bedeutet, dass jeder Benutzer, Dienstprinzipal oder verwaltete Identität eine eigene unabhängige Kontingentzuweisung erhält. Kontingente werden niemals zwischen Identitäten geteilt, und alle berechtigten Fabric APIs nutzen aus einem gemeinsamen Kontingent-Bucket, der dieser Identität zugeordnet ist.

Daher hat die API-Verwendung durch eine Identität keine Auswirkungen auf eine andere Identität. Beispielsweise kann ein stark genutzter Dienstprinzipal sein eigenes API-Kontingent ausschöpfen, ohne die Kontingente anderer Benutzer oder Anwendungen zu beeinträchtigen.

Wenn eine Identität ihr Kontingentlimit erreicht und gedrosselt wird, gilt diese Einschränkung nur für diese Identität, während andere Identitäten weiterhin normal funktionieren. Diese Isolation bietet eine berechenbare und verwaltbare API-Nutzung über Workloads hinweg.

Kontingenterzwingungshierarchie

Konzeptionelles Diagramm der Kontingenthierarchie.

Jede API-Anforderung beginnt mit einer Identität – entweder mit einem Benutzerkonto oder einem Dienstprinzipal. Wenn diese Identität eine Fabric-API aufruft, verbraucht die Anforderung zuerst Kapazität aus dem freigegebenen APIs-Kontingent, das pro Identität und nicht pro API erzwungen wird. Dieses Kontingent fungiert als zentralisierter Einschränkungsmechanismus, der für alle teilnehmenden APIs freigegeben wird, um sicherzustellen, dass eine einzelne Identität die zugewiesene Anforderungsrate nicht überschreiten kann.

Nachdem die Anforderung anhand des freigegebenen APIs-Kontingents ausgewertet wurde, werden auch alle API-spezifischen Einschränkungsgrenzwerte angewendet. Diese Grenzwerte sind unabhängig vom freigegebenen Kontingent und können nur für bestimmte APIs vorhanden sein. Daher muss eine Anforderung sowohl das API-Kontingent auf Identitätsebene als auch alle anwendbaren individuellen API-Grenzwerte erfüllen, die erfolgreich verarbeitet werden sollen.

In der Praxis bietet das freigegebene APIs-Kontingent eine konsistente Einschränkungserfahrung über APIs hinweg, während einzelne API-Grenzwerte weiterhin bestimmte Dienste schützen, die zusätzliche Schutzmaßnahmen erfordern. Ein API-Aufruf kann daher gedrosselt werden, entweder weil die Identität das freigegebene Kontingent ausgeschöpft hat oder weil sie den Grenzwert eines bestimmten API-Endpunkts erreicht hat.

Wichtige Konzepte:

  • Identitätsbasierte Erzwingung: Das Kontingent wird für jeden Benutzer oder Dienstprinzipal separat nachverfolgt.
  • API-übergreifend gemeinsam genutzt: Anfragen an verschiedene APIs werden auf denselben API-Kontingent-Pool angerechnet.
  • Nur Ratenbegrenzung: Das API-Kontingent regelt die Anfrageraten, wirkt sich jedoch nicht auf die Autorisierung oder Berechtigungen aus.
  • Duale Erzwingung: Sowohl das freigegebene APIs-Kontingent als auch alle API-spezifischen Grenzwerte werden für jede Anforderung ausgewertet.
  • Der restriktivste Grenzwert gewinnt: Eine Anforderung wird gedrosselt, wenn entweder das freigegebene Kontingent oder ein anwendbarer API-spezifischer Grenzwert überschritten wird.

Wie Kontingent verbraucht wird

Jede API-Anforderung verbraucht ein Kontingent aus dem APIs-Kontingent-Bucket der aufrufenden Identität. Alle Anforderungen, die von dieser Identität vorgenommen werden, zählen zu demselben freigegebenen Kontingent, unabhängig davon, welche API aufgerufen wird.

Kontingentzeitraum und Verlängerung

Das API-Kontingent wird in einem festen 60-Sekunden-Fenster durchgesetzt. Das Kontingent wird auf einmal wieder aufgefüllt, wenn das aktuelle Zeitfenster endet. Das Kontingent erholt sich während des Zeitraums nicht schrittweise.

Hinweis

Wenn eine Identität ihr gesamtes Kontingent zu Beginn des Zeitfensters verbraucht, kann sie keine zusätzlichen Anfragen senden, bis das nächste 60-Sekunden-Zeitfenster beginnt.

Zeitachsenbeispiel

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.

Praktische Auswirkungen

  • Eine Häufung von Anforderungen zu Beginn eines Zeitfensters ist zulässig, kann jedoch dazu führen, dass die betreffende Identität für den Rest dieses Zeitfensters gedrosselt wird.
  • Die gleichmäßige Verteilung von Anfragen über den gesamten 60-Sekunden-Zeitraum hinweg hilft, Drosselung zu vermeiden.
  • Beachten Sie immer den Retry-After-Response-Header. Es gibt an, wie lange gewartet werden soll, bevor eine gedrosselte Anforderung erneut gesendet wird.

Details zum Ratelimit nach API

Während Microsoft Fabric einheitliche Einschränkungskategorien und gemeinsame Kontingentkonzepte bereitstellt, können die tatsächlichen Ratengrenzwerte je nach API variieren. Überprüfen Sie immer den Abschnitt „Drosselungsgrenzen“ für die jeweilige API, die Sie aufrufen.

Hinweis

Überprüfen Sie immer den Abschnitt „Drosselungsgrenzen“ für die jeweilige API, die Sie aufrufen.

Drosselungsmeldung

Wenn eine Drosselung auftritt, gibt Fabric den HTTP-Statuscode 429 (Zu viele Anfragen) zurück. Fabric gibt aus zwei unterschiedlichen Gründen einen 429-Statuscode zurück, der jeweils durch einen anderen errorCode Im Antworttext identifiziert wird:

Überprüfen Sie den errorCode Wert in der Antwort, um zu bestimmen, welche Bedingung aufgetreten ist und wie reagiert werden soll.

Ratenlimit überschritten (RequestBlocked)

Wenn ein Benutzer viele Anforderungen sendet, die einen vordefinierten Grenzwert während eines Zeitfensters überschreiten, drosselt Fabric weitere Anforderungen dieses Benutzers für einen kurzen Zeitraum.

In diesem Fall gibt Fabric einen HTTP-Statuscode 429 (Zu viele Anforderungen) mit einem Retry-After HTTP-Header in der Antwort zurück, der angibt, wie viele Sekunden die aufrufende Anwendung warten soll, bevor der Aufruf erneut ausgeführt wird. Der Antworttext verwendet den RequestBlocked Fehlercode:

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

Wenn Sie diesen Fehler erhalten, warten Sie auf die im Retry-After Header angegebene Dauer, bevor Sie die Anforderung erneut versuchen.

Der folgende Screenshot zeigt ein Antwortbeispiel, das vorschlägt, dass der Benutzer 55 Sekunden wartet, bevor er den Anruf erneut versucht.

Screenshot eines HTTP-Antwortheaders.

Kapazitätsgrenze überschritten (CapacityLimitExceeded)

Fabric gibt auch einen HTTP-Statuscode 429 (Zu viele Anforderungen) zurück, wenn die Fabric Kapazität Ihrer Organisation ihre Grenzwerte überschritten hat. Im Gegensatz zur Ratenbegrenzung wird diese Drosselung nicht durch die Anzahl der API-Aufrufe verursacht, die ein bestimmter Aufrufer tätigt. Stattdessen tritt dies auf, wenn die auf Ihrer Kapazität verbrauchte Rechenkapazität (Kapazitätseinheiten) die Grenzen der erworbenen Fabric-SKU überschreitet. Der Antworttext verwendet den CapacityLimitExceeded Fehlercode:

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

Wenn Sie diese Fehlermeldung erhalten, versuchen Sie es später erneut. Da diese Drosselung von der gesamten Computenutzung auf Ihrer Kapazität und nicht von Ihrer individuellen Anfragerate abhängt, ist es unwahrscheinlich, dass ein sofortiger Wiederholungsversuch erfolgreich ist, bevor die Computenutzung der Kapazität wieder innerhalb ihrer Grenzwerte liegt. Wenn dieser Fehler häufig auftritt, sollten Sie in Erwägung ziehen, Ihre Fabric-Kapazität vertikal oder horizontal zu skalieren. Weitere Informationen zu Kapazitätseinheiten, SKUs und dazu, wie Fabric Kapazität verbraucht wird, finden Sie unter Planen der Kapazitätsgröße.

Überlegungen und Einschränkungen

Jeder Fabric Administrator und die öffentliche Kern-API können gedrosselt werden.

Beachten Sie diese Überlegungen beim Entwerfen von Anwendungen, die Fabric REST-APIs aufrufen:

  • Kontingente werden für die Identität des Aufrufers und die aufgerufene API durchgesetzt. Separate Identitäten teilen nicht unbedingt denselben Anforderungszähler, aber jeder Aufrufer muss weiterhin den dokumentierten Grenzwerten für die API folgen.
  • Viele Geschwindigkeitsbeschränkungen werden über einminütige Fenster ausgewertet. Wenn Sie einen Grenzwert überschreiten, warten Sie auf den Retry-After Wert, bevor Sie weitere Anforderungen senden.
  • Die Kapazitätsdrosselung unterscheidet sich von der Anforderungsratendrosselung. CapacityLimitExceededgibt an, dass die Fabric Kapazität überlastet ist und nicht, dass der Aufrufer ein API-Kontingent pro Minute überschritten hat.
  • Das erneute Wiederholen eines Kapazitätsdrosselungsfehlers ist wahrscheinlich nicht erfolgreich. Verwenden Sie eine gebundene Wiederholungsrichtlinie, und untersuchen Sie die Kapazitätsauslastung, wenn der Fehler weiterhin besteht.
  • Bei Integrationen mit hohem Volumen bevorzugen Sie Listen-, Massen- oder Batchvorgänge, wenn sie verfügbar sind, Cachemetadaten, die sich selten ändern, und verteilen Sie Anforderungen gleichmäßig im Laufe der Zeit.
  • Verwenden Sie für APIs, die die Paginierung unterstützen, Fortsetzungstoken, anstatt wiederholte allgemeine Abfragen von Anfang an auszuführen.

Häufig gestellte Fragen

Wie weiß ich, ob ich ein API-Kontingent oder ein Kapazitätslimit erreicht habe?

Überprüfen Sie den errorCode Antworttext von 429. RequestBlocked bedeutet, dass die Anforderungsrate die Einschränkungsgrenzwerte des Diensts überschritten hat. CapacityLimitExceeded bedeutet, dass die auf der Fabric-Kapazität verbrauchte Rechenleistung die Grenzwerte der erworbenen SKU überschritten hat.

Wann wird mein Kontingent zurückgesetzt?

Viele Fabric REST-API-Ratenbeschränkungen werden über einminütige Fenster ausgewertet. Wenn die Antwort einen Retry-After Header enthält, verwenden Sie diesen Wert als autoritative Wartezeit, bevor Sie den Vorgang wiederholen.

Kann ich mein verbleibendes API-Kontingent überprüfen, bevor ich eine Anforderung anfertige?

Fabric REST-API-Antworten bieten keinen allgemeinen Restkontingentzähler für alle APIs. Erstellen Sie Clients so, dass sie 429-Antworten erkennen, Retry-After beachten und das Anforderungsvolumen verringern, wenn eine Drosselung auftritt.

Wie kann ich die Chance reduzieren, gedrosselt zu werden?

Verwenden Sie nach Möglichkeit Sammel- und Batchvorgänge, bevorzugen Sie Listen-APIs gegenüber vielen Aufrufen einzelner Ressourcen, speichern Sie häufig abgerufene Metadaten im Cache, und vermeiden Sie plötzliche Lastspitzen. Verwenden Sie für die Drosselung der persistenten Kapazität die app Microsoft Fabric Kapazitätsmetriken, um überlastete Kapazitäten und Workloads zu identifizieren.

Sollte ich alle 429 Antworten auf die gleiche Weise wiederholen?

No. Warten Sie bei RequestBlockedauf den Retry-After-Header und versuchen Sie es dann mit einer begrenzten Wiederholungsrichtlinie erneut. Bei CapacityLimitExceeded sollten Sie es später mit exponentiellem Backoff erneut versuchen und die Kapazitätsauslastung untersuchen, wenn das Problem weiterhin besteht.

Verwandte Inhalte

  • Last updated on