Winst:
- Kan snelheidslimieten (RPM/ITPM/OTPM) en 429-fouten interpreteren
- Implementeert exponentieel uitstellen en opnieuw proberen met retry-after
- Classificeert en verwerkt op de juiste manier veelvoorkomende HTTP-foutcodes (400/401/429/500/529)
In een productieomgeving reageert geen enkele API altijd perfect. Soms verstuur je te snel verzoeken en loop je tegen de limiet aan; soms is de server tijdelijk bezet; Soms is uw verzoek vanaf het begin verkeerd. Wat een solide integratie onderscheidt van een amateurpoging is dat deze situaties voorspellend en automatisch worden afgehandeld. In dit onderdeel leert u over snelheidslimieten (RPM/ITPM/OTPM), 429-fouten, nieuwe pogingen met exponentiële uitstel en de juiste classificatie van algemene HTTP-foutcodes. Het doel: een flow bouwen die zo robuust is dat een gebruiker het nooit zal merken.
Wat zijn snelheidslimieten?
De aanbieder beperkt hoeveel werk een switch in een bepaalde periode kan doen. Deze bescherming; Het beschermt zowel de infrastructuur als uzelf tegen plotselinge kostenexplosies. Er zijn drie veel voorkomende soorten limieten:
- RPM (Verzoeken Per Minuut): Aantal verzoeken per minuut.
- ITPM (Input Tokens Per Minute): Invoertoken dat per minuut kan worden verwerkt.
- OTPM (Output Tokens Per Minute): Uitvoertoken dat per minuut kan worden geproduceerd.
Als u een van deze limieten overschrijdt, wijst de provider het verzoek af en retourneert een 429-foutcode. Limieten variëren over het algemeen afhankelijk van uw accountniveau (niveau) en kunnen in de loop van de tijd worden verhoogd.
Tip: Via de antwoordheaders kunt u zien wanneer u de limiet nadert. De meeste providers rapporteren uw resterende quotum met headers als x-ratelimit-remaining-*. Het monitoren van deze waarden en het afremmen van het verkeer vooraan is de meest volwassen manier om het probleem te voorkomen zonder een 429 te krijgen.
429 en exponentiële retracement
429 (snelheidslimiet) is een tijdelijke en opnieuw te proberen fout. De juiste reactie is om een tijdje op het verzoek te wachten en het opnieuw te proberen. Maar constant wachten is niet genoeg; Als iedereen het tegelijkertijd opnieuw probeert, wordt de limiet opnieuw bereikt. De oplossing is exponentieel uitstel: de wachttijd exponentieel verhogen bij elke mislukte poging.
# Exponentiële uitstellogica proef 1 → 429 → wacht 1 sec proef 2 → 429 → wacht 2 sec proef 3 → 429 → wacht 4 sec proef 4 → 429 → wacht 8 sec (+ kleine willekeurige "jitter")... geef op en rapporteer na maximaal N proeven
Door hieraan een beetje willekeur (jitter) toe te voegen, voorkom je dat verzoeken botsen wanneer je tegelijkertijd opnieuw probeert te proberen. Bovendien bevat het 429-antwoord vaak een 'retry-after'-header: "probeer het over zoveel seconden opnieuw". Het respecteren van deze titel is nauwkeuriger dan blindelings wachten.
Let op: wanneer u een 429 krijgt, zal "het forceren door meer verzoeken te sturen" de situatie verergeren; De limiet blijft gevuld en er komen geen verzoeken binnen. Het juiste antwoord is terugtrekken, niet versnellen. Goed nieuws: de meeste officiële SDK's proberen 429- en serverfouten automatisch opnieuw met een uitstel. Gebruik dit gedrag van de SDK voordat u deze handmatig installeert.
Classificatie van HTTP-foutcodes
Niet elke fout is hetzelfde. Kritisch onderscheid: kan het opnieuw worden geprobeerd of is er sprake van een verzoek/identiteitsprobleem?
Codeer
Betekenis
Kan het nog een keer geprobeerd worden?
juiste reactie
400
Ongeldig verzoek (formaat-/parameterfout)
nee
Corrigeer het verzoek; stuur hetzelfde niet nog een keer
401
Authenticatiefout (sleutel ongeldig/ontbreekt)
nee
Sleutel/titel repareren
403
Geen autorisatie (geen toegang tot model/functie)
nee
Controleer machtigingen/bereik
404
Niet gevonden (onjuiste model-ID/eindpunt)
nee
Juiste model-ID/adres
429
Snelheidslimiet overschreden
Ja
Terugtrekken + opnieuw proberen na
500
Serverfout
Ja
Probeer het opnieuw met retraite
529
Server overbelast
Ja
Probeer het opnieuw met retraite
Gulden regel: 429, 500 en 529 zijn tijdelijk; Het wordt opnieuw geprobeerd met intrekking. 400, 401, 403, 404 zijn verzoek-/identiteitsproblemen; Opnieuw proberen zal het probleem niet oplossen, en het verspilt moeite. Uw code moet onderscheid maken tussen deze twee groepen.
Stap voor stap: Duurzaam bellen
- Dien de aanvraag in. Indien succesvol, ga verder.
- Classificeer de foutcode. Kan het nog een keer geprobeerd worden?
- Indien mogelijk: volg opnieuw proberen na, pas exponentiële uitstel + jitter toe, probeer een beperkt aantal keren (bijvoorbeeld maximaal 5).
- Indien niet geprobeerd: Fix (format/key) en stop; Herhaal niet hetzelfde foutieve verzoek in de lus.
- Overweeg om op te geven. Als het na n pogingen nog steeds niet lukt, toon dan een beleefd bericht aan de gebruiker en registreer de gebeurtenis (volgeenheid 11).
# Robuuste aanroep pseudo-codedene = 0repeat: response = request_at() if response.success: return response if response.code in [429, 500, 529] en probeer < 5: wait = retry_after ?? (2^probeer sec + jitter) slaap(wacht); probeer += 1; git opnieuw als response.code in [400, 401, 403, 404]: save_error(response); return "verzoek moet worden opgelost" return "permanente fout, probeer het later"
# Beleefde feedback aan de gebruiker (wanneer er geen nieuwe pogingen meer mogelijk zijn) "Ik ben momenteel bezig, ik kan uw verzoek niet verwerken. Probeer het binnenkort opnieuw, of ik heb uw verzoek opgeslagen, ik neem contact met u op zodra het klaar is."
Zwakke prompt/sterke prompt (hier: ontwerp van de foutmelding)
# ZWAK (toont ruwe fout aan gebruiker) "Fout 429: rate_limit_error"
# STERK (gebruiksvriendelijk, geruststellend, actie-suggesterend) "Er was een tijdelijke overbelasting in het systeem. We hebben uw verzoek veilig ontvangen en het wordt automatisch opnieuw geprobeerd. Als er binnen enkele seconden geen resultaat verschijnt, kunt u de pagina vernieuwen."
Het onthullen van de ruwe technische fout aan de eindgebruiker ondermijnt het vertrouwen en kan een beveiligingsprobleem vormen. Categoriseer fouten intern en geef de gebruiker een rustige, actiegerichte boodschap; schrijf gewoon de technische details voor de goede orde.
Drie mini-hoesjes
Geval 1 — Boot stortte neer bij een verkeersexplosie. Een klantenservicebot ontving op de campagnedag 429 bezoekers; Er was geen nieuwe poging in de code, elke fout werd rechtstreeks aan de gebruiker weergegeven als een "fout". Ze voegden exponentiële retracement + retry-after toe; met hetzelfde verkeer werden verzoeken met een vertraging van enkele seconden doorgegeven, de gebruiker zag geen fouten.
Geval 2 — Probeer 400 in de lus. Een integratie kreeg een 404 vanwege een ongeldig model-ID, maar behandelde alle fouten als "tijdelijk" en probeerde het opnieuw in een oneindige lus; Het houtblok zwol op en er ontstond onnodige belasting. Ze voegden foutclassificatie toe: 404 wordt als permanent beschouwd, de lus wordt gestopt en de model-ID wordt gecorrigeerd. Les: probeer niet elke fout opnieuw.
Geval 3 — De limiet vanaf de voorkant beheren. Een taak voor gegevensverrijking draaide voortdurend op de limiet van 429. Ze volgden de x-ratelimit-resterende header en beperkten het verkeer volgens de quota. Ze hielden dus een gestaag tempo aan, net onder de limiet, zonder 429's te nemen; De klus werd voorspelbaarder en sneller geklaard.
Veel voorkomende fouten
- Snelheid verhogen in 429: maakt de situatie erger; Schakel over naar terugtrekken.
- Elke fout opnieuw proberen: 400/401/404 is permanent; Opnieuw proberen is zonde.
- Vast wachten gebruiken: Creëert een botsing; Gebruik exponentieel + jitter.
- Negeren van 'retry-after': Het is het meest nauwkeurig om de door de aanbieder opgegeven tijd aan te houden.
- De grove fout aan de gebruiker onthullen: schudt het vertrouwen, creëert kwetsbaarheden; Classificeer binnen.
- Onbeperkt aantal nieuwe pogingen: Stel een bovengrens in (bijvoorbeeld 5 nieuwe pogingen); geef het dan gracieus op.
Dieper: wachtrijen, gelijktijdigheid en stroomonderbrekers
Het volhouden van één enkel verlangen is de eerste stap; De echte volwassenheid is het beheren van een groot aantal verzoeken zonder de limieten te overschrijden. Hierbij spelen drie concepten een rol.
Wachtrij: u plaatst verzoeken in een wachtrij om ze in een gecontroleerd tempo te verzenden in plaats van onmiddellijk. Wachtrijen verzachten plotselinge verkeersstromen: zelfs als er 1.000 verzoeken tegelijk binnenkomen, zal de wachtrij deze vrijgeven met een snelheid die onder de limiet ligt. Zo voorkom je 429, waarna je je geen zorgen meer hoeft te maken over het repareren ervan.
Gelijktijdigheidslimiet: u beperkt het aantal verzoeken dat tegelijkertijd "in de lucht" is. Onbeperkte parallelle verzoeken vullen snel de RPM- en TPM-limieten. Een redelijk gelijktijdigheidsplafond (bijvoorbeeld niet meer dan tien gelijktijdige verzoeken) handhaaft zowel de limieten als maakt het systeem voorspelbaar.
Stroomonderbreker: Als de provider 500/529 blijft retourneren, in plaats van hardnekkig elk verzoek te proberen, "verbreekt u het circuit" voor een tijdje en faalt u snel het verzoek zonder het ooit te verzenden. Na een tijdje wachten zet u het circuit weer aan en probeert u het. Dit patroon voorkomt dat uw systeem crasht in het geval van een tijdelijke providerstoring.
Samen zorgen deze drie voor veerkracht op systeemniveau die verder gaat dan de logica van opnieuw proberen van een enkele oproep. Op kleine schaal is de automatische nieuwe poging van de SDK voldoende; Naarmate de schaal groeit, worden wachtrijen, gelijktijdigheid en stroomonderbrekers onmisbaar. Ze hebben allemaal hetzelfde gemeenschappelijke doel: een tijdelijk probleem voor de gebruiker niet weergeven als een crash, maar als een onzichtbare vertraging van een paar seconden.
Samengevat
429 keert terug wanneer snelheidslimieten (RPM/ITPM/OTPM) worden overschreden; Dit is een tijdelijke fout en zal opnieuw worden geprobeerd met behulp van retry-after en exponentiële uitstel + jitter. 500 en 529 zijn ook voorlopig; 400/401/403/404 is een verzoek/identiteitsprobleem en kan niet worden opgelost door het opnieuw te proberen. Een robuuste stroom verdeelt fouten in deze twee groepen, probeert een beperkt aantal keren, bewaakt de limiet vanaf de voorkant en toont rustige berichten aan de gebruiker.
Applicatie taak
Denk aan uw integratie. (1) Maak een lijst van de foutcodes die u kunt tegenkomen en scheid ze in "hernieuwbaar / permanent". (2) Schrijf uw exponentiële pullback-plan op (initiële hold, coëfficiënt, cap, jitter). (3) Geef op hoe u de retry-after-header wilt gebruiken. (4) Schrijf het beleefde bericht dat aan de gebruiker wordt getoond wanneer de nieuwe pogingen zijn uitgeput.
controlelijst
- [ ] Ik kan RPM/ITPM/OTPM-limieten en 429 uitleggen.
- [ ] Ik kan de logica van exponentiële terugtrekking + jitter + opnieuw proberen toepassen.
- [ ] Ik kan foutcodes classificeren als opnieuw te proberen/permanent.
- [ ] Ik weet dat we niet elke fout moeten proberen.
- [ ] In plaats van een ruwe fout kan ik de gebruiker een rustige, actiegerichte boodschap laten zien.