Begrensning i Microsoft Fabric

Microsoft Fabric bruker begrensning for å opprettholde tjenesteytelse og pålitelighet når arbeidsbelastninger overskrider kapasitets- eller REST API-forespørselsgrenser. Denne artikkelen forklarer hvordan begrensning fungerer, hvordan du tolker HTTP 429-svar og hvordan du utformer programmer som håndterer Fabric API-kvoter effektivt.

API-kvotegrenser

Microsoft Fabric introduserer enhetlig kvote for REST-API-er for REST-API-ene. I denne modellen styres API-forespørsler av kvoter på identitetsnivå som håndheves per bruker eller tjenestekontohaver.

Målet er en konsekvent, forutsigbar begrensningsopplevelse for de styrte API-gruppene, på tvers av automatisering, CI/CD og agentdrevne scenarier.

Tidligere håndhevet hver Microsoft Fabric REST-API sine egne uavhengige begrensningsregler, noe som ofte resulterte i inkonsekvent atferd på tvers av endepunkter. Som et resultat var det vanskelig å forutsi når en arbeidsbelastning kan begrenses, spesielt for automatiseringsscenarioer som samhandlet med flere API-er og var underlagt ulike grenser.

Med innføringen av API-kvoten går Fabric over til en mer konsekvent, identitetsbasert tilnærming. API-forbruk styres nå av en enhetlig kvote som håndheves per identitet, noe som gir en klarere og mer forutsigbar begrensningsmodell på tvers av Fabric API-er. Det er imidlertid viktig å være oppmerksom på at enkelte individuelle API-spesifikke begrensningsgrenser fortsatt kan gjelde i tillegg til den totale API-kvoten.

Når en API-referanseside dokumenterer en kvote, kan du behandle den endepunktspesifikke grensen som autoritativ for denne API-en. Hvis en API-referanseside ikke viser en numerisk kvote, utformer du programmet for å håndtere 429 svar ved å Retry-Afteroverholde, bruke avgrensede nye forsøk og unngå serier.

Slik fungerer kvotemodellen

Hver identitet – enten en bruker eller en tjenestekontohaver – tilordnes flere uavhengige kvotesamlinger som styrer ulike kategorier av API-trafikk. Når identiteten sender en forespørsel, evalueres forespørselen mot kvoten for API-kategorien som brukes.

Det finnes tre enhetlige kvoter:

1. Enhetlig kvote for plattform-API-er – dedikert til plattform-API-er.
2. Enhetlig kvote for API-er for jobbplanlegging – dedikert til API-er for jobbplanlegging.
3. Unified Quota for Long-Running Operations API-er – dedikert til Long-Running Operations API-er.

Fordi disse kvotene er uavhengige, bruker ikke aktiviteten i én kategori kvote fra en annen kategori. En tjenestekontohaver kan for eksempel bruke den fullstendige enhetlige kvoten for jobbplanleggings-API-er uten å påvirke den tilgjengelige enhetlige kvoten for plattform-API-er. Denne separasjonen sikrer at arbeidsbelastninger med høyt volum i spesialiserte API-områder ikke påvirker generelle API-operasjoner og muliggjør mer forutsigbar begrensningsatferd på tvers av ulike typer forespørsler.

API-håndhevelse

API-kvoten håndheves per identitet, noe som betyr at hver bruker, tjenestekontohaver eller administrert identitet mottar sin egen uavhengige kvotetildeling. Kvoter deles aldri mellom identiteter, og alle kvalifiserte Fabric API-er forbruker fra en felles kvotesamling som er knyttet til denne identiteten.

Som et resultat har API-bruk av én identitet ingen innvirkning på noen annen identitet. En mye brukt tjenestekontohaver kan for eksempel tømme sin egen API-kvote uten å påvirke kvotene til andre brukere eller programmer.

Likeledes, hvis en identitet når kvotegrensen og er begrenset, gjelder denne begrensningen bare for denne identiteten, mens andre identiteter fortsetter å fungere normalt. Denne isolasjonen gir mer forutsigbart og håndterbart API-forbruk på tvers av arbeidsbelastninger.

Kvotehåndhevelseshierarki

Hver API-forespørsel begynner med en identitet – enten en brukerkonto eller en tjenestekontohaver. Når denne identiteten kaller opp en Fabric API, bruker forespørselen først kapasitet fra den delte API-kvoten, som håndheves per identitet i stedet for per API. Denne kvoten fungerer som en sentralisert begrensningsmekanisme som deles på tvers av alle deltakende API-er, slik at én enkelt identitet ikke kan overskride den tildelte forespørselssatsen.

Når forespørselen er evaluert mot den delte API-kvoten, brukes også api-spesifikke begrensningsgrenser. Disse grensene er uavhengige av den delte kvoten og kan bare eksistere for bestemte API-er. Som et resultat må en forespørsel oppfylle både API-kvoten på identitetsnivå og eventuelle gjeldende individuelle API-grenser som skal behandles.

I praksis gir den delte API-kvoten en konsekvent begrensningsopplevelse på tvers av API-er, mens individuelle API-grenser fortsetter å beskytte bestemte tjenester som krever ytterligere sikkerhetstiltak. Et API-kall kan derfor begrenses enten fordi identiteten har brukt opp den delte kvoten eller fordi den har nådd grensen for et bestemt API-endepunkt.

Viktige begreper:

• Identitetsbasert håndhevelse: Kvoten spores separat for hver bruker eller tjenestekontohaver.
• Delt på tvers av API-er: Forespørsler til forskjellige API-er forbruker fra samme API-kvoteutvalg.
• Bare begrensning: API-kvoten kontrollerer forespørselssatser, men påvirker ikke autorisasjon eller tillatelser.
• Dobbel håndhevelse: Både den delte API-kvoten og eventuelle API-spesifikke grenser evalueres for hver forespørsel.
• Mest restriktive grense vinner: En forespørsel begrenses når den delte kvoten eller en gjeldende API-spesifikk grense overskrides.

Hvordan kvoten forbrukes

Hver API-forespørsel bruker kvote fra kallidentitetens API-kvotesamling. Alle forespørsler fra denne identiteten teller mot den samme delte kvoten, uavhengig av hvilken API som kalles.

Kvotevindu og fornyelse

API-kvote håndheves ved hjelp av et fast 60-sekunders vindu. Kvotesamlingen fylles på nytt samtidig når gjeldende vindu avsluttes. Kvoten gjenopprettes ikke gradvis i løpet av vinduet.

Tidslinjeeksempel

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.

Praktiske implikasjoner

• Bursting-forespørsler i begynnelsen av et vindu er tillatt, men hvis du gjør dette, kan identiteten bli begrenset for resten av vinduet.
• Distribusjon av forespørsler jevnt over 60 sekunder bidrar til å unngå begrensning.
• Tilnærm alltid Retry-After svarhode. Den angir hvor lenge du skal vente før du prøver en begrenset forespørsel på nytt.

Prisgrensedetaljer etter API

Selv om Microsoft Fabric gir enhetlige begrensningskategorier og delte kvotekonsepter, kan de faktiske rentegrensene variere etter API. Kontroller alltid begrensningsgrensedelen for den bestemte API-en du kaller.

Begrensningsmelding

Når begrensning oppstår, returnerer Fabric en HTTP-statuskode 429 (for mange forespørsler). Fabric returnerer en 429-statuskode av to forskjellige årsaker, hver identifisert av en annen errorCode i svarteksten:

• Rentegrense overskredet (RequestBlocked)
• Kapasitetsgrensen er overskredet (CapacityLimitExceeded)

errorCode Undersøk verdien i svaret for å finne ut hvilken betingelse som oppstod, og hvordan du svarer.

Rentegrense overskredet (RequestBlocked)

Når en bruker sender mange forespørsler som overskrider en forhåndsbestemt grense i løpet av et tidsvindu, Fabric begrense ytterligere forespørsler fra denne brukeren i en kort periode.

I dette tilfellet returnerer Fabric en HTTP-statuskode 429 (for mange forespørsler) med et Retry-After HTTP-hode i svaret, som angir hvor mange sekunder anropsprogrammet skal vente før anropet prøves på nytt. Svarteksten RequestBlocked bruker feilkoden:

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

Når du får denne feilen, venter du på varigheten som er angitt i toppteksten Retry-After , før du prøver forespørselen på nytt.

Skjermbildet nedenfor viser et svareksempel som tyder på at brukeren venter 55 sekunder før samtalen prøves på nytt.

Kapasitetsgrense overskredet (CapacityLimitExceeded)

Fabric returnerer også en HTTP-statuskode 429 (for mange forespørsler) når organisasjonens Fabric kapasitet har overskredet grensene. I motsetning til rentebegrensning er ikke denne begrensningen forårsaket av antall API-kall en bestemt innringer foretar. I stedet oppstår det når databehandlingen (kapasitetsenhetene) som forbrukes på kapasiteten, overskrider grensene for den kjøpte Fabric SKU. Svarteksten CapacityLimitExceeded bruker feilkoden:

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

Når du mottar denne feilen, kan du prøve forespørselen på nytt senere. Fordi denne begrensningen avhenger av den totale databehandlingen som forbrukes på kapasiteten i stedet for den individuelle forespørselsfrekvensen, vil det neppe lykkes å prøve på nytt umiddelbart før kapasitetens databehandlingsbruk faller tilbake innenfor grensene. Hvis du støter på denne feilen ofte, bør du vurdere å skalere opp eller skalere ut Fabric kapasitet. Hvis du vil ha mer informasjon om kapasitetsenheter, SKU-er og hvordan Fabric kapasitet forbrukes, kan du se Planlegge kapasitetsstørrelsen.

Hensyn og begrensninger

Hver Fabric administrator og kjerne offentlig API kan begrenses.

Husk disse vurderingene når du utformer programmer som kaller Fabric REST-API-er:

• Kvoter håndheves for anroperidentiteten og API-en som kalles. Separate identiteter deler ikke nødvendigvis samme forespørselsteller, men hver innringer må fortsatt følge de dokumenterte grensene for API-en.
• Mange rentegrenser evalueres over ett minutts vinduer. Hvis du overskrider en grense, må du vente på Retry-After verdien før du sender flere forespørsler.
• Kapasitetsbegrensning er forskjellig fra begrensning av forespørselsfrekvens. CapacityLimitExceededangir at den Fabric kapasiteten er overbelastet, ikke at innringeren overskred en API-kvote per minutt.
• Det er lite sannsynlig at det vil lykkes å prøve en kapasitetsbegrensningsfeil umiddelbart. Bruk en policy for avgrenset forsøk på nytt, og undersøk kapasitetsbruken hvis feilen vedvarer.
• For integreringer med høyt volum foretrekker du liste-, masse- eller satsvise operasjoner når de er tilgjengelige, hurtigbufre metadata som endres sjelden, og spre forespørsler jevnt over tid.
• For API-er som støtter paginering, kan du bruke fortsettelsestokener i stedet for å foreta gjentatte brede spørringer fra begynnelsen.

Vanlige spørsmål

Hvordan vet jeg om jeg har nådd en API-kvote eller en kapasitetsgrense?

errorCode Sjekk i svarteksten på 429. RequestBlocked betyr at forespørselsfrekvensen overskred tjenestens begrensningsgrenser. CapacityLimitExceededbetyr at databehandlingen som forbrukes på den Fabric kapasiteten, overskred grensene for den kjøpte SKU-en.

Når tilbakestilles kvoten min?

Mange Fabric REST API-rentegrenser evalueres over ett minutts vinduer. Hvis svaret inneholder en Retry-After topptekst, bruker du denne verdien som autoritativ ventetid før du prøver på nytt.

Kan jeg kontrollere den gjenværende API-kvoten før jeg foretar en forespørsel?

Fabric REST API-svar gir ikke en generell gjenkvoteteller for alle API-er. Bygg klienter slik at de kan oppdage 429 svar, ære Retry-Afterog redusere forespørselsvolumet når begrensning oppstår.

Hvordan kan jeg redusere sjansen for å bli begrenset?

Bruk masse- og satsvise operasjoner når det er tilgjengelig, foretrakk liste-API-er fremfor mange enkeltressurskall, hurtigbuffer ofte tilgjengelige metadata og unngå plutselige trafikkutbrudd. For fast kapasitetsbegrensning bruker du appen Microsoft Fabric Capacity Metrics til å identifisere overbelastede kapasiteter og arbeidsbelastninger.

Bør jeg prøve på nytt hver 429 svar på samme måte?

Nei. Vent RequestBlockedtil toppteksten Retry-After , og prøv deretter på nytt med en avgrenset policy for nye forsøk. Prøv CapacityLimitExceededpå nytt senere med eksponentiell backoff og undersøk kapasitetsutnyttelsen hvis problemet vedvarer.

Relatert innhold

• Bruke REST-API-ene for Microsoft Fabric
• omfang
• Feilsøke Microsoft Fabric REST-API-er
• Planlegge kapasitetsstørrelsen
• Forstå Fabric kapasitetsbegrensning
• Måledataapp for Microsoft Fabric Capacity Metrics