Rajoittaminen Microsoft Fabric

Microsoft Fabric käyttää rajoittamista palvelun suorituskyvyn ja luotettavuuden ylläpitämiseen, kun kuormitukset ylittävät kapasiteetin tai REST-ohjelmointirajapinnan pyyntörajat. Tässä artikkelissa kerrotaan, miten rajoittaminen toimii, miten HTTP 429 -vastauksia tulkitaan ja miten suunnitella sovelluksia, jotka käsittelevät Fabric ohjelmointirajapintakiintiöitä tehokkaasti.

Ohjelmointirajapintakiintiön rajoitukset

Microsoft Fabric esittelee REST-ohjelmointirajapintojen unified quota -asetuksen REST-ohjelmointirajapintojaan varten. Tässä mallissa ohjelmointirajapintapyyntöihin sovelletaan käyttäjätason kiintiöitä, jotka on pakotettu käyttäjää tai palvelun päänimeä kohden.

Tavoitteena on yhdenmukainen, ennustettava rajoituskokemus hallituille ohjelmointirajapintaryhmille kaikissa automaatio-, CI/CD- ja agenttipohjaisissa skenaarioissa.

Aiemmin kukin REST-ohjelmointirajapinnan Microsoft Fabric valvoi omia riippumattomia rajoittamista koskevia sääntöjään, mikä usein johti epäyhtenäiseen käyttäytymiseen päätepisteissä. Tämän vuoksi oli vaikea ennustaa, milloin kuormitus saatetaan rajoittaa, erityisesti sellaisten automaatioskenaarioiden osalta, jotka olivat vuorovaikutuksessa useiden ohjelmointirajapintojen kanssa ja joita rajoitettiin eri rajoissa.

Ohjelmointirajapintojen kiintiön myötä Fabric on siirtymässä yhtenäisempään, käyttäjätietopohjaiseen lähestymistapaan. Ohjelmointirajapinnan kulutukseen sovelletaan nyt yhdistettyä käyttäjätietojen kiintiötä, joka tarjoaa selkeämmän ja ennustettavamman rajoitusmallin kaikissa Fabric ohjelmointirajapinnassa. On kuitenkin tärkeää huomata, että joitakin api-kohtaisia rajoitinrajoituksia saattaa edelleen soveltaa yleisen ohjelmointirajapintakiintiön lisäksi.

Kun ohjelmointirajapinnan viitesivulla on kiintiö, pidä kyseistä päätepistekohtaista rajoitusta kyseisen ohjelmointirajapinnan valtuuttavana. Jos ohjelmointirajapinnan viitesivulla ei ole numeerista kiintiötä, suunnittele sovelluksesi käsittelemään 429 vastausta, Retry-Afterottamalla käyttöön sidotut uudelleenvedot ja välttämällä halkeamat.

Kiintiömallin toiminta

Kullekin käyttäjätietoryhmälle (joko käyttäjälle tai palvelun päänimelle) määritetään useita riippumattomia kiintiösäilöjä, jotka ohjaavat eri ohjelmointirajapintaliikenteen luokkia. Kun käyttäjätiedot lähettävät pyynnön, pyyntö arvioidaan käytetyn ohjelmointirajapintaluokan kiintiöön nähden.

Yhdistettyjä kiintiöitä on kolme:

1. Unified Quota for Platform -ohjelmointirajapinnat – varattu ympäristön ohjelmointirajapinnoille.
2. Yhdistetty työaikataulujen ajoitusohjelmoinnin ohjelmointirajapinnat – varattu työn ajoitusohjelmoinnin ohjelmointirajapinnoille.
3. Unified Quota for Long-Running Operations -ohjelmointirajapinnat, jotka on omistettu Long-Running toimintojen ohjelmointirajapinnoille.

Koska nämä kiintiöt ovat riippumattomia, yhden luokan aktiviteetti ei kuluta kiintiötä toisesta luokasta. Palvelun päänimi voi esimerkiksi käyttää koko Unified Quota for Job Scheduler -ohjelmointirajapintojaan vaikuttamatta sen käytettävissä oleviin yhdistetyn ympäristön ohjelmointirajapintojen kiintiöön. Tämä erittely varmistaa, että suuren määrän kuormitukset erityisillä ohjelmointirajapinta-alueilla eivät vaikuta yleisiin ohjelmointirajapintatoimintoihin ja mahdollistavat ennustettavamman rajoittamistoiminnan erityyppisissä pyynnöissä.

Ohjelmointirajapinnan pakottaminen

Ohjelmointirajapintojen kiintiötä sovelletaan käyttäjäkohtaisesti, mikä tarkoittaa sitä, että jokainen käyttäjä, palvelun päänimi tai hallittu käyttäjätieto saa oman itsenäisen kiintiön jakamisen. Kiintiöitä ei koskaan jaeta käyttäjätietojen välillä, ja kaikki oikeutetut Fabric ohjelmointirajapinnat kuluttavat käyttäjätietoihin liittyvän yhteisen kiintiösijainnin kautta.

Tämän vuoksi yhden käyttäjätiedon ohjelmointirajapinnan käyttö ei vaikuta mihinkään muihin käyttäjätietoihin. Esimerkiksi paljon käytetty palvelun päänimi voi tyhjentää oman ohjelmointirajapintakiintiönsä vaikuttamatta muiden käyttäjien tai sovellusten kiintiöihin.

Samoin jos käyttäjätiedot saavuttavat kiintiörajansa ja niitä rajoitetaan, tämä rajoittaminen koskee vain kyseisiä käyttäjätietoja, kun taas muut käyttäjätiedot toimivat normaalisti. Eristys tarjoaa ennakoitavamman ja hallittavamman ohjelmointirajapinnan kulutuksen kaikissa kuormitusten välillä.

Kiintiön pakottaminen -hierarkia

Jokainen ohjelmointirajapintapyyntö alkaa käyttäjätiedoilla – joko käyttäjätilillä tai palvelun päänimellä. Kun käyttäjätiedot kutsuvat Fabric-ohjelmointirajapintaa, pyyntö käyttää ensin kapasiteettia jaetusta ohjelmointirajapintojen kiintiöstä, joka pakotetaan käyttäjätietojen mukaan ohjelmointirajapinnan sijaan. Tämä kiintiö toimii keskitetynä rajoittamismekanismina, joka on jaettu kaikille osallistuville ohjelmointirajapinnoille ja varmistaa, että yksittäiset käyttäjätiedot eivät voi ylittää varattua pyyntömäärää.

Kun pyyntö on arvioitu suhteessa jaettujen ohjelmointirajapintojen kiintiöön, sovelletaan myös ohjelmointirajapintakohtaisia rajoitinrajoituksia. Nämä rajoitukset ovat riippumattomia jaetusta kiintiöstä, ja ne voivat olla olemassa vain tietyissä ohjelmointirajapinoista. Tämän vuoksi pyynnön on täytettävä sekä käyttäjätietotason ohjelmointirajapintojen kiintiö että mahdolliset yksittäiset ohjelmointirajapintojen rajoitukset, jotta se voidaan käsitellä onnistuneesti.

Käytännössä jaettujen ohjelmointirajapintojen kiintiö tarjoaa johdonmukaisen rajoittamiskokemuksen ohjelmointirajapintojen välillä, kun taas yksittäiset ohjelmointirajapintojen rajoitukset suojaavat edelleen tiettyjä palveluja, jotka edellyttävät lisäsuojauksia. Ohjelmointirajapinnan kutsu voidaan siis rajoittaa joko siksi, että käyttäjätiedot ovat käyttäneet loppuun jaettua kiintiötään tai koska se on saavuttanut tietyn ohjelmointirajapinnan päätepisteen rajan.

Avainkäsitteet:

• Käyttäjätietopohjainen pakottaminen: kiintiötä seurataan erikseen kunkin käyttäjän tai palvelun päänimen osalta.
• Jaettu ohjelmointirajapintojen välillä: Eri ohjelmointirajapintoihin pyynnöt käyttävät samaa ohjelmointirajapintojen kiintiövarantoa.
• Vain rajoittaminen: Ohjelmointirajapintojen kiintiö hallitsee pyyntöjen hintoja, mutta ei vaikuta valtuutukseen tai käyttöoikeuksiin.
• Kaksoisvalvonta: Sekä jaettujen ohjelmointirajapintojen kiintiö että ohjelmointirajapintakohtaiset rajoitukset arvioidaan jokaista pyyntöä varten.
• Rajoittavin rajoittavin rajoitus voittaa: Pyyntö rajoitetaan, kun joko jaettu kiintiö tai soveltuva ohjelmointirajapintakohtainen raja ylitetään.

Miten kiintiötä kulutetaan

Jokainen ohjelmointirajapintapyyntö käyttää kiintiötä kutsuvien käyttäjätietojen ohjelmointirajapintojen kiintiöstä. Kaikki tämän käyttäjätietojen tekemät pyynnöt lasketaan mukaan samaan jaettuun kiintiöön riippumatta siitä, mitä ohjelmointirajapintaa kutsutaan.

Kiintiöikkuna ja uusiminen

Ohjelmointirajapintojen kiintiö pakotetaan käyttöön kiinteän 60 sekunnin ikkunan avulla. Kiintiö-säilö täydennetään kerralla, kun nykyinen ikkuna päättyy. Kiintiö ei vähitellen palautu ikkunan aikana.

Aikajanan esimerkki

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.

Käytännön vaikutukset

• Halkeavat pyynnöt sallitaan ikkunan alussa, mutta tämän tekeminen saattaa rajoittaa käyttäjätietoja kyseisen ikkunan loppuosan ajaksi.
• Pyyntöjen tasainen jakaminen 60 sekunnin aikana auttaa välttämään rajoittamista.
• Kunnioita aina Retry-After vastauksen otsikkoa. Se ilmaisee, kuinka kauan on odotettava, ennen kuin rajoitetaan pyyntöä uudelleen.

Suhderajapinnan mukaan

Vaikka Microsoft Fabric tarjoaa yhtenäiset rajoittamisen luokat ja jaetun kiintiön käsitteet, todelliset korkorajoitukset voivat vaihdella ohjelmointirajapinnan mukaan. Tarkista aina rajoittamisrajat -osio sen tietyn ohjelmointirajapinnan kohdalla, jolle olet kutsumassa.

Rajoitinsanoma

Kun rajoittaminen tapahtuu, Fabric palauttaa HTTP-tilakoodin 429 (liian monta pyyntöä). Fabric palauttaa 429-tilakoodin kahdesta eri syystä, joista jokainen on tunnistettu errorCode eri vastauksessa:

• Ylitetty suhderaja (RequestBlocked)
• Kapasiteetin raja ylitetty (CapacityLimitExceeded)

errorCode Tarkista vastauksessa oleva arvo, jotta voit määrittää, mikä ehto ilmeni ja miten siihen vastataan.

Suhderaja ylitetty (Pyynnön esto)

Kun käyttäjä lähettää useita pyyntöjä, jotka ylittävät ennalta määritetyn rajoituksen aikaikkunan aikana, Fabric rajoittaa käyttäjän pyyntöjä entisestään lyhyen aikaa.

Tässä tapauksessa Fabric palauttaa HTTP-tilakoodin 429 (liian monta pyyntöä), jonka vastauksessa on Retry-After HTTP-otsikko, mikä ilmaisee, kuinka monen sekunnin kuluttua kutsusovelluksen tulisi odottaa ennen kutsun uudelleenyritysten aloittamista. Vastauksen leipäteksti käyttää virhekoodia RequestBlocked :

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

Kun saat tämän virheen, odota otsikossa Retry-After määritettyä kestoa, ennen kuin yrität pyyntöä uudelleen.

Seuraavassa näyttökuvassa on esimerkki vastauksesta, joka ehdottaa, että käyttäjä odottaa 55 sekuntia ennen puhelun uudelleen yritämistä.

Kapasiteetin raja ylitetty (CapacityLimitExceeded)

Fabric palauttaa myös HTTP-tilakoodin 429 (Liian monta pyyntöä), kun organisaatiosi Fabric kapasiteetti on ylittänyt rajansa. Toisin kuin hintojen rajoittaminen, tämä rajoittaminen ei johdu tietyn soittajan kutsumien ohjelmointirajapintakutsujen määrästä. Näin käykin, kun kapasiteetissasi käytetty käsittely (kapasiteettiyksiköt) ylittää ostetun Fabric varastointiyksikön rajoitukset. Vastauksen leipäteksti käyttää virhekoodia CapacityLimitExceeded :

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

Kun saat tämän virheviestin, yritä myöhemmin uudelleen. Koska tämä rajoittaminen riippuu kapasiteetissasi käytetystä kokonais tietojenkäsittelystä eikä yksittäisestä pyyntöjen hinnasta, uudelleenyritysten heti ei todennäköisesti onnistu, ennen kuin kapasiteetin käsittely ei ylitä rajojaan. Jos kohtaat tämän virheen usein, harkitse Fabric kapasiteetin skaalaamista ylöspäin tai skaalaamista. Lisätietoja kapasiteettiyksiköistä, varastointiyksiköistä ja siitä, miten Fabric kapasiteettia kulutetaan, on artikkelissa Kapasiteetin koon suunnitteleminen.

Huomioitavat asiat ja rajoitukset

Kaikki Fabric järjestelmänvalvojan ja keskeistä julkista ohjelmointirajapintaa voidaan rajoittaa.

Pidä nämä seikat mielessä, kun suunnittelet sovelluksia, jotka kutsuvat Fabric REST-ohjelmointirajapintoja:

• Kiintiöt pakotetaan kutsuttavat käyttäjätiedoilla ja ohjelmointirajapinnalla. Erilliset käyttäjätiedot eivät välttämättä jaa samaa pyynnön laskuria, mutta kunkin soittajan on silti noudatettava ohjelmointirajapinnan dokumentoituja rajoituksia.
• Monet korkorajoitukset arvioidaan minuutin ikkunoiden aikana. Jos raja ylittyy, odota Retry-After arvoa, ennen kuin lähetät lisää pyyntöjä.
• Kapasiteetin rajoittaminen eroaa pyyntönopeuden rajoittamisesta. CapacityLimitExceededilmaisee, että Fabric kapasiteetti on ylikuormitettu, ei niin, että soittaja olisi ylittänyt minuuttikohtaisen ohjelmointirajapintakiintiön.
• Kapasiteetin rajoittamisvirheen uudelleen rajoittaminen heti ei todennäköisesti onnistu. Käytä sidottua uudelleenyritysten käytäntöä ja tutki kapasiteetin käyttöä, jos virhe jatkuu.
• Suuren määrän integroinneissa suositaan luettelo-, joukko- tai erätoimintoja, kun ne ovat käytettävissä, välimuistin metatietoja, jotka muuttuvat harvoin, ja jaetaan pyyntöjä tasaisesti ajan kuluessa.
• Sivutusta tukevissa ohjelmointirajapituissa kannattaa käyttää jatkumistunnuksia sen sijaan, että teet toistuvia laajoja kyselyitä alusta alkaen.

Usein kysyttyjä kysymyksiä

Mistä tiedän, saavutinko ohjelmointirajapintakiintiön vai kapasiteettirajan?

errorCode Tarkista 429-vastauksen leipäteksti. RequestBlocked tarkoittaa, että pyyntöjen määrä ylitti palvelun rajoittamisrajat. CapacityLimitExceededtarkoittaa, että Fabric -kapasiteetissa kulutettu käsittely ylitti ostetun SKU:n rajat.

Milloin kiintiöni nollautuu?

Monet Fabric REST-ohjelmointirajapinnan nopeusrajoitukset arvioidaan minuutin ikkunoiden aikana. Jos vastauksessa on Retry-After otsikko, käytä tätä arvoa oleellisena odotusaikana ennen uudelleenyritysten käyttämistä.

Voinko tarkistaa jäljellä olevan ohjelmointirajapintakiintiöni ennen pyynnön tekemistä?

Fabric REST-ohjelmointirajapinnan vastaukset eivät tarjoa yleistä jäljellä olevan kiintiön laskuria kaikille ohjelmointirajapinnoille. Luo asiakasohjelmia, jotta he voivat havaita 429 vastausta, noudattaa ja Retry-Afterpienentää pyyntöjen määrää rajoittamisen yhteydessä.

Miten voin pienentää rajoitusrajoitusten todennäköisyyttä?

Käytä joukko- ja erätoimintoja, kun ne ovat käytettävissä, käytä mieluummin luettelon ohjelmointirajapintoja kuin monia yksittäisen resurssin kutsuja, tallenna välimuistiin usein käytettyjä metatietoja ja vältä äkillisiä liikennekuormituksia. Jos haluat rajoittaa kapasiteettia, tunnista ylikuormitetut kapasiteetit ja kuormitukset Microsoft Fabric Capacity Metrics -sovelluksella.

Pitäisikö minun yrittää uudelleen jokaista 429 vastausta samalla tavalla?

Ei. Odota RequestBlockedotsikkoa Retry-After ja yritä sitten uudelleen sidotulla uudelleenyritysten käytännöllä. Yritä CapacityLimitExceededmyöhemmin uudelleen eksponentiaalisesti ja tutki kapasiteetin käyttöä, jos ongelma jatkuu.

Aiheeseen liittyvä sisältö

• Microsoft Fabric REST -ohjelmointirajapintojen käyttö
• Scopes -
• Microsoft Fabric REST-ohjelmointirajapintojen vianmääritys
• Kapasiteetin koon suunnitteleminen
• Fabric kapasiteetin rajoittamisen ymmärtäminen
• Microsoft Fabric Capacity Metrics -sovellus