Resursbegränsning i Microsoft Fabric

Microsoft Fabric använder begränsning för att upprätthålla tjänstens prestanda och tillförlitlighet när arbetsbelastningar överskrider kapacitets- eller REST API-begärandegränser. Den här artikeln beskriver hur begränsning fungerar, hur du tolkar HTTP 429-svar och hur du utformar program som hanterar Fabric API-kvoter effektivt.

API-kvotgränser

Microsoft Fabric introducerar Enhetlig kvot för REST-API:er för sina REST-API:er. I den här modellen styrs API-begäranden av kvoter på identitetsnivå som tillämpas per användare eller tjänstens huvudnamn.

Målet är en enhetlig och förutsägbar strypningsupplevelse för de styrda API-grupperna i automatiserings-, CI/CD- och agentdrivna scenarier.

Tidigare tillämpade varje Microsoft Fabric REST API sina egna oberoende strypningsregler, vilket ofta resulterade i inkonsekvent funktion mellan olika slutpunkter. Därför var det svårt att förutsäga när en arbetsbelastning kan begränsas, särskilt för automatiseringsscenarier som interagerade med flera API:er och som omfattades av olika gränser.

I och med introduktionen av API:erna Kvot övergår Fabric till en mer konsekvent, identitetsbaserad metod. API-förbrukningen styrs nu av en enhetlig kvot som tillämpas per identitet, vilket ger en tydligare och mer förutsägbar begränsningsmodell för Fabric API:er. Det är dock viktigt att observera att vissa enskilda API-specifika begränsningsgränser fortfarande kan gälla utöver den övergripande API-kvoten.

När en API-referenssida dokumenterar en kvot behandlar du den slutpunktsspecifika gränsen som auktoritativ för det API:et. Om en API-referenssida inte anger någon numerisk kvot ska du utforma din applikation så att den hanterar 429-svar genom att följa Retry-After, använda ett begränsat antal återförsök och undvika trafiktoppar.

Så här fungerar kvotmodellen

Varje identitet, antingen en användare eller ett huvudnamn för tjänsten, tilldelas flera oberoende kvot buckets som styr olika kategorier av API-trafik. När identiteten skickar en begäran utvärderas begäran mot kvoten för den API-kategori som används.

Det finns tre enhetliga kvoter:

1. Enhetlig kvot för plattforms-API:er – dedikerade till plattforms-API:er.
2. Enhetlig kvot för Job Scheduler-API:er – avsedd för Job Scheduler-API:er.
3. Enhetlig kvot för API:er för långvariga åtgärder – dedikerad till API:er för långvariga åtgärder.

Eftersom dessa kvoter är oberoende förbrukar aktiviteten i en kategori inte kvoten från en annan kategori. Ett tjänsthuvudnamn kan till exempel förbruka hela sin enhetliga kvot för Job Scheduler-API:er utan att påverka sin tillgängliga enhetliga kvot för plattforms-API:er. Den här separationen säkerställer att högvolymarbetsbelastningar i specialiserade API-områden inte påverkar allmänna API-åtgärder och möjliggör mer förutsägbart begränsningsbeteende för olika typer av begäranden.

API-tillämpning

API:ernas kvot tillämpas per identitet, vilket innebär att varje användare, tjänstens huvudnamn eller hanterade identitet får sin egen oberoende kvotallokering. Kvoter delas aldrig mellan identiteter, och alla kvalificerade Fabric-API:er förbrukar från en gemensam kvotpool som är kopplad till den identiteten.

Därför har API-användning med en identitet ingen inverkan på någon annan identitet. Till exempel kan ett starkt använt huvudnamn för tjänsten uttömma sin egen API:er-kvot utan att påverka kvoterna för andra användare eller program.

På samma sätt gäller den begränsningen endast för den identiteten om en identitet når sin kvotgräns och blir begränsad, medan andra identiteter fortsätter att fungera normalt. Den här isoleringen ger mer förutsägbar och hanterbar API-förbrukning mellan arbetsbelastningar.

Kvottillämpningshierarki

Varje API-begäran börjar med en identitet – antingen ett användarkonto eller ett huvudnamn för tjänsten. När den identiteten anropar ett Fabric API förbrukar begäran först kapacitet från den delade API:kvoten, som framtvingas per identitet i stället för per API. Den här kvoten fungerar som en centraliserad begränsningsmekanism som delas mellan alla deltagande API:er, vilket säkerställer att en enda identitet inte får överskrida den allokerade begärandefrekvensen.

När begäran har utvärderats mot den delade API:kvoten tillämpas även eventuella API-specifika begränsningsgränser. Dessa gränser är oberoende av den delade kvoten och kan bara finnas för vissa API:er. Därför måste en begäran uppfylla både API-kvoten på identitetsnivå och eventuella tillämpliga individuella API-gränser för att kunna behandlas.

I praktiken ger den delade API:kvoten en konsekvent begränsningsupplevelse mellan API:er, medan enskilda API-gränser fortsätter att skydda specifika tjänster som kräver ytterligare skydd. Ett API-anrop kan därför begränsas antingen för att identiteten har förbrukat sin delade kvot eller för att den har nått gränsen för en viss API-slutpunkt.

Viktiga begrepp:

• Identitetsbaserad tillämpning: Kvoten spåras separat för varje användare eller tjänstens huvudnamn.
• Delas mellan API:er: Begäranden till olika API:er använder samma API-kvotpool.
• Endast begränsning av begärandefrekvens: API-kvoten styr begärandefrekvensen men påverkar inte auktorisering eller behörigheter.
• Dubbel tillämpning: Både den delade API:kvoten och eventuella API-specifika gränser utvärderas för varje begäran.
• Mest restriktiva gräns vinner: En begäran begränsas när antingen den delade kvoten eller en tillämplig API-specifik gräns överskrids.

Hur kvoten förbrukas

Varje API-begäran förbrukar kvot från den anropande identitetens API-kvotgrupp. Alla begäranden som görs av den identiteten räknas mot samma delade kvot, oavsett vilket API som anropas.

Kvotperiod och förnyelse

API-kvoten upprätthålls med ett fast tidsfönster på 60 sekunder. Kvotbehållaren fylls på igen helt och hållet på en gång när det nuvarande tidsfönstret löper ut. Kvoten återhämtas inte gradvis under perioden.

Tidslinjeexempel

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.

Praktiska konsekvenser

• Att skicka många begäranden i snabb följd i början av ett tidsfönster är tillåtet, men om du gör det kan identiteten strypas under resten av tidsfönstret.
• Genom att distribuera begäranden jämnt under den 60 sekunder långa perioden kan du undvika begränsning.
• Respektera alltid Retry-After-svarsrubriken. Den anger hur lång tid det tar att vänta innan du försöker utföra en begränsad begäran igen.

Information om hastighetsbegränsning per API

Även om Microsoft Fabric tillhandahåller enhetliga begränsningskategorier och begrepp för delad kvot kan de faktiska hastighetsgränserna variera beroende på API. Kontrollera alltid avsnittet Throttling-gränser för det API som du anropar.

Begränsningsmeddelande

När begränsning inträffar returnerar Fabric HTTP-statuskoden 429 (för många förfrågningar). Fabric returnerar en 429-statuskod av två olika orsaker, som var och en identifieras av en annan errorCode i svarstexten:

• Hastighetsgränsen har överskridits (RequestBlocked)
• Kapacitetsgränsen har överskridits (CapacityLimitExceeded)

Kontrollera värdet errorCode i svaret för att avgöra vilket villkor som inträffade och hur du skulle svara.

Hastighetsgränsen har överskridits (RequestBlocked)

När en användare skickar många begäranden som överskrider en förutbestämd gräns under en tidsperiod begränsar Fabric ytterligare begäranden från användaren under en kort period.

I det här fallet returnerar Fabric en HTTP-statuskod 429 (för många begäranden) med ett Retry-After HTTP-huvud i svaret, vilket anger hur många sekunder det anropande programmet ska vänta innan det försöker anropa igen. Svarstexten RequestBlocked använder felkoden:

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

När du får det här felet väntar du på den varaktighet som anges i Retry-After rubriken innan du försöker utföra begäran igen.

Följande skärmbild visar ett svarsexempel som tyder på att användaren väntar 55 sekunder innan samtalet försöker igen.

Kapacitetsgränsen har överskridits (CapacityLimitExceeded)

Fabric returnerar också http-statuskoden 429 (för många begäranden) när organisationens Fabric kapacitet har överskridit sina gränser. Till skillnad från hastighetsbegränsning orsakas inte den här begränsningen av antalet API-anrop som en specifik anropare gör. I stället inträffar det när den beräkningskapacitet (kapacitetsenheter) som används i din kapacitet överskrider gränserna för den inköpta Fabric-SKU:n. Svarstexten CapacityLimitExceeded använder felkoden:

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

När du får det här felet kan du prova begäran igen senare. Eftersom den här strypningen beror på den totala beräkningskapacitet som används i din kapacitet snarare än på frekvensen för dina enskilda begäranden, är det osannolikt att det lyckas om du försöker igen omedelbart, förrän beräkningsanvändningen i kapaciteten sjunker tillbaka till en nivå inom gränserna. Om det här felet uppstår ofta kan du överväga att skala upp eller skala ut din Fabric kapacitet. Mer information om kapacitetsenheter, SKU:er och hur Fabric-kapacitet används finns i Planera storleken på din kapacitet.

Överväganden och begränsningar

Varje administratörs-API i Fabric och centralt publikt API kan begränsas.

Tänk på följande när du utformar program som anropar Fabric REST-API:er:

• Kvoter tillämpas för den anroparidentitet och API som anropas. Separata identiteter delar inte nödvändigtvis samma begäranderäknare, men varje anropare måste fortfarande följa de dokumenterade gränserna för API:et.
• Många hastighetsgränser utvärderas under en minuts fönster. Om du överskrider en gräns väntar du på Retry-After värdet innan du skickar fler begäranden.
• Kapacitetsbegränsning skiljer sig från begränsning av begärandefrekvens. CapacityLimitExceeded anger att Fabric-kapaciteten är överbelastad, inte att anroparen överskred en API-gräns per minut.
• Det är osannolikt att det lyckas om du försöker igen direkt efter ett fel på grund av kapacitetsbegränsning. Använd en begränsad återförsöksprincip och undersöka kapacitetsanvändningen om felet kvarstår.
• För högvolymintegreringar föredrar du list-, mass- eller batchåtgärder när de är tillgängliga, cachelagrar metadata som ändras sällan och sprider begäranden jämnt över tid.
• För API:er som stöder sidnumrering använder du fortsättningstoken i stället för att göra upprepade breda frågor från början.

Vanliga frågor och svar

Hur vet jag om jag har nått en API-kvot eller en kapacitetsgräns?

Kontrollera errorCode i svarstexten för 429-svaret. RequestBlocked innebär att begärandefrekvensen överskred tjänstens begränsningsgränser. CapacityLimitExceeded innebär att de beräkningsresurser som förbrukades på Fabric-kapaciteten överskred gränserna för den köpta SKU:n.

När återställs min kvot?

Många Fabric REST API-hastighetsgränser utvärderas under en minuts fönster. Om svaret innehåller en Retry-After rubrik använder du det värdet som auktoritativ väntetid innan du försöker igen.

Kan jag kontrollera min återstående API-kvot innan jag gör en begäran?

Fabric REST API-svar ger inte en allmän räknare för återstående kvoter för alla API:er. Utforma klienter så att de kan upptäcka 429-svar, följa Retry-After och minska antalet begäranden när begränsning tillämpas.

Hur kan jag minska risken för att bli strypt?

Använd mass- och batchåtgärder när det är tillgängligt, föredrar list-API:er framför många anrop med en resurs, cachelagrar metadata som används ofta och undviker plötsliga trafiktoppar. För ihållande kapacitetsbegränsning använder du Microsoft Fabric Capacity Metrics-appen för att identifiera överbelastade kapaciteter och arbetsbelastningar.

Ska jag försöka igen var 429:e svar på samma sätt?

No. För RequestBlocked, vänta på rubriken Retry-After och försök sedan igen med en begränsad princip för återförsök. För CapacityLimitExceeded gäller att du ska försöka igen senare med exponentiellt ökande väntetid och undersöka kapacitetsutnyttjandet om problemet kvarstår.

Relaterat innehåll

• Använda REST-API:er för Microsoft Fabric
• Scoper
• Felsöka MICROSOFT FABRIC REST API:er
• Planera din kapacitetsstorlek
• Förstå din Fabric-kapacitetsstrypning
• Microsoft Fabric App för kapacitetsmått