Gevinster:
- Kan tolke fartsgrenser (RPM/ITPM/OTPM) og 429 feil
- Implementerer eksponentiell backoff og prøv på nytt med forsøk på nytt etter
- Klassifiserer og håndterer vanlige HTTP-feilkoder på riktig måte (400/401/429/500/529)
I et produksjonsmiljø reagerer ingen API perfekt hele tiden. Noen ganger sender du forespørsler for raskt og når grensen; noen ganger er serveren midlertidig opptatt; Noen ganger er forespørselen din feil fra begynnelsen. Det som skiller en solid integrasjon fra et amatørforsøk er at den håndterer disse situasjonene prediktivt og automatisk. I denne enheten vil du lære om hastighetsgrenser (RPM/ITPM/OTPM), 429-feil, prøve på nytt med eksponentiell backoff og riktig klassifisering av vanlige HTTP-feilkoder. Målet: å bygge en flyt som er så robust at en bruker aldri vil legge merke til det.
Hva er fartsgrenser?
Tilbyderen begrenser hvor mye arbeid en bytte kan gjøre i en gitt tidsperiode. Denne beskyttelsen; Det beskytter både infrastrukturen og deg mot plutselige kostnadseksplosjoner. Det er tre vanlige typer grenser:
- RPM (Requests Per Minute): Antall forespørsler per minutt.
- ITPM (Input Tokens Per Minute): Inndatatoken som kan behandles per minutt.
- OTPM (Output Tokens Per Minute): Utdatatoken som kan produseres per minutt.
Hvis du overskrider noen av disse grensene, avviser leverandøren forespørselen og returnerer en 429 feilkode. Grensene varierer vanligvis avhengig av kontonivået ditt (tier) og kan økes over tid.
Tips: Du kan se når du nærmer deg grensen fra svaroverskriftene. De fleste leverandører rapporterer den gjenværende kvoten din med overskrifter som x-ratelimit-remaining-*. Å overvåke disse verdiene og strupe trafikken foran er den mest modne måten å forhindre problemet på uten å få en 429.
429 og eksponentiell retracement
429 (hastighetsgrense) er en midlertidig feil som kan prøves på nytt. Det riktige svaret er å vente på forespørselen en stund og prøve igjen. Men en konstant venting er ikke nok; Hvis alle prøver på nytt samtidig, nås grensen igjen. Løsningen er eksponentiell backoff: å øke ventetiden eksponentielt for hvert mislykkede forsøk.
# Eksponentiell backoff-logikkprøve 1 → 429 → vent 1 sek prøve 2 → 429 → vent 2 sek prøve 3 → 429 → vent 4 sek prøve 4 → 429 → vent 8 sek (+ liten tilfeldig "jitter")... gi opp og rapporter etter maksimalt N forsøk
Å legge til litt tilfeldighet (jitter) til dette forhindrer at forespørsler kolliderer når du prøver å prøve på nytt samtidig. I tillegg har 429-svaret ofte en "try-efter"-overskrift: "prøv igjen om så mange sekunder". Å respektere denne tittelen er mer nøyaktig enn å vente blindt.
Forsiktig: Når du får en 429, vil "tvinge den ved å sende flere forespørsler" gjøre situasjonen verre; Grensen fortsetter å fylles og ingen forespørsler går gjennom. Riktig respons er retrett, ikke akselerasjon. Gode nyheter: de fleste offisielle SDK-er prøver automatisk 429 og serverfeil med en backoff - bruk denne oppførselen til SDK-en før du installerer den manuelt.
Klassifisering av HTTP-feilkoder
Ikke alle feil er like. Kritisk distinksjon: kan det prøves på nytt, eller er det et spørsmål om forespørsel/identitet?
Kode
Mening
Kan det prøves igjen?
riktig svar
400
Ugyldig forespørsel (format-/parameterfeil)
nei
Korriger forespørselen; ikke send det samme igjen
401
Autentiseringsfeil (nøkkel ugyldig/mangler)
nei
Fiks nøkkel/tittel
403
Ingen autorisasjon (ingen tilgang til modell/funksjon)
nei
Sjekk tillatelser/omfang
404
Ikke funnet (feil modell-ID/endepunkt)
nei
Riktig modell ID/adresse
429
Fartsgrensen er overskredet
Ja
Retreat + nytt forsøk etter
500
Serverfeil
Ja
Prøv igjen med retrett
529
Server overbelastet
Ja
Prøv igjen med retrett
Gylden regel: 429, 500 og 529 er midlertidige; Det prøves på nytt med tilbaketrekning. 400, 401, 403, 404 er forespørsel/identitetsproblemer; Å prøve igjen vil ikke løse det, og det er sløsing. Koden din må skille mellom disse to gruppene.
Trinn for trinn: Slitesterk samtale
- Send inn forespørselen. Hvis vellykket, fortsett.
- Klassifiser feilkoden. Kan det prøves igjen?
- Hvis det kan prøves: følg et nytt forsøk etter, bruk eksponentiell backoff + jitter, prøv et begrenset antall ganger (f.eks. maks. 5).
- Hvis ikke prøvd: Fiks (format/tast) og stopp; Ikke gjenta den samme feilaktige forespørselen i loopen.
- Vurder å gi opp. Hvis det fortsatt ikke lykkes etter n forsøk, vis en høflig melding til brukeren og logg hendelsen (sporingsenhet 11).
# Robust call pseudo-codedene = 0repeat: response = request_at() if response.success: returnere respons if response.code i [429, 500, 529] og prøv < 5: wait = retry_after ?? (2^prøv sek + jitter) sleep(vent); prøv += 1; git igjen hvis respons.kode i [400, 401, 403, 404]: save_error(response); return "forespørsel må rettes" return "permanent feil, prøv senere"
# Høflig tilbakemelding til brukeren (når gjenforsøk er oppbrukt) "Jeg er opptatt akkurat nå, jeg kunne ikke behandle forespørselen din. Prøv igjen snart, eller jeg har lagret forespørselen din, jeg kommer tilbake til deg når den er klar."
Svak forespørsel / sterk forespørsel (her: feilmeldingsdesign)
# SVAK (viser rå feil til bruker)"Feil 429: rate_limit_error"
# STERK (brukervennlig, betryggende, handlingssuggerende) "Det var en midlertidig overbelastning i systemet. Vi har mottatt forespørselen din trygt og den prøves automatisk på nytt. Hvis et resultat ikke vises innen noen få sekunder, kan du oppdatere siden."
Å avsløre den rå tekniske feilen for sluttbrukeren både undergraver tilliten og kan være en sikkerhetssårbarhet. Kategoriser feil internt og gi brukeren en rolig, handlingsorientert melding; bare skriv den tekniske detaljen for ordens skyld.
Tre minivesker
Sak 1 - Båt havarerte i trafikkeksplosjon. En kundeservice-bot mottok 429 i økt trafikk på kampanjedagen; Det var ingen nytt forsøk i koden, hver feil ble reflektert direkte til brukeren som en "feil". De la til eksponentiell retracement + retry-etter; med samme trafikk, forespørsler sendt med en forsinkelse på flere sekunder, så brukeren ingen feil.
Tilfelle 2 — Prøver 400 i sløyfen. En integrasjon fikk en 404 på grunn av en ugyldig modell-ID, men behandlet alle feil som "forbigående" og prøvde igjen i en uendelig sløyfe; Tømmerstokken ble hoven og unødvendig belastning ble opprettet. De la til feilklassifisering: 404 regnes som permanent, sløyfen stoppes og modell-ID-en korrigeres. Leksjon: Ikke prøv hver feil igjen.
Tilfelle 3 — Administrere grensen forfra. En dataanrikingsjobb kjørte konstant på 429-grensen. De fulgte x-ratelimit-gjenværende header og strupet trafikken i henhold til kvoten. Så de holdt et jevnt tempo like under grensen, uten å ta noen 429-ere; Jobben ble gjort mer forutsigbart og raskere.
Vanlige feil
- Økende hastighet i 429: Gjør situasjonen verre; Bytt til retrett.
- Prøver hver feil på nytt: 400/401/404 er permanent; Å prøve igjen er bortkastet.
- Bruke fast ventetid: Skaper en kollisjon; Bruk eksponentiell + jitter.
- Ignorerer "forsøk på nytt": Det er mest nøyaktig å overholde tiden spesifisert av leverandøren.
- Å avsløre den rå feilen for brukeren: Ryster tilliten, skaper sårbarheter; Klassifiser innsiden.
- Ubegrensede forsøk: Angi en øvre grense (f.eks. 5 forsøk); så gi opp grasiøst.
Dypere: Kø-, samtidighets- og strømbrytere
Utholdenheten til et enkelt ønske er det første trinnet; Den virkelige modenheten er å håndtere et stort antall forespørsler uten å nå grensene. Tre konsepter spiller inn her.
Kø: Du setter forespørsler i en kø for å sende dem i et kontrollert tempo i stedet for umiddelbart. Kø jevner ut plutselige utbrudd av trafikk: Selv om 1000 forespørsler kommer på en gang, vil køen frigjøre dem med en hastighet under grensen. På denne måten forhindrer du 429, da trenger du ikke å bekymre deg for å fikse det.
Samtidig grense: Du begrenser hvor mange forespørsler som er "i luften" samtidig. Ubegrensede parallelle forespørsler fyller raskt RPM- og TPM-grenser. Et rimelig samtidighetstak (f.eks. ikke mer enn 10 samtidige forespørsler) både opprettholder grenser og gjør systemet forutsigbart.
Strømbryter: Hvis leverandøren fortsetter å returnere 500/529, i stedet for hardnakket å prøve hver forespørsel, "bryter du kretsen" en stund og mislykkes raskt forespørselen uten å sende den. Etter en venting slår du på kretsen igjen og prøver. Dette mønsteret forhindrer systemet fra å krasjer i tilfelle en midlertidig leverandørfeil.
Sammen etablerer disse tre motstandsdyktighet på systemnivå utover logikken til å prøve på nytt for en enkelt samtale. I liten skala er SDKs automatiske gjenforsøk tilstrekkelig; Etter hvert som omfanget vokser, blir kø, samtidighet og strømbryter uunnværlig. De har alle samme felles mål: å reflektere et midlertidig problem for brukeren, ikke som et krasj, men som en usynlig forsinkelse på noen få sekunder.
Oppsummert
429 returnerer når fartsgrensene (RPM/ITPM/OTPM) overskrides; Dette er en midlertidig feil og vil bli forsøkt på nytt ved å bruke et nytt forsøk og eksponentiell backoff + jitter. 500 og 529 er også foreløpige; 400/401/403/404 er et forespørsel/identitetsproblem og kan ikke løses ved å prøve på nytt. En robust flyt skiller feil i disse to gruppene, prøver et begrenset antall ganger, overvåker grensen forfra og viser rolige meldinger til brukeren.
Søknadsoppgave
Vurder integreringen din. (1) List opp feilkodene du kan støte på, og del dem i "kan prøves på nytt / permanent". (2) Skriv ned din eksponentielle tilbaketrekningsplan (initial hold, koeffisient, cap, jitter). (3) Spesifiser hvordan du skal bruke overskriften for forsøk på nytt etter. (4) Skriv den høflige meldingen som skal vises til brukeren når gjenforsøk er oppbrukt.
sjekkliste
- [ ] Jeg kan forklare RPM/ITPM/OTPM-grenser og 429.
- [ ] Jeg kan bruke logikken til eksponentiell retrett + jitter + forsøk på nytt etter.
- [ ] Jeg kan klassifisere feilkoder som prøvebare/permanente.
- [ ] Jeg vet at vi ikke bør prøve alle feil.
- [ ] I stedet for en rå feil, kan jeg vise brukeren en rolig, handlingsorientert melding.