Limitele de viteză și gestionarea rezistentă a erorilor

Câștiguri:

Poate interpreta limitele de viteză (RPM/ITPM/OTPM) și erori 429
Implementează backoff-ul exponențial și reîncercați cu retry-after
Clasifică și gestionează corect codurile de eroare HTTP comune (400/401/429/500/529)

Într-un mediu de producție, niciun API nu răspunde perfect tot timpul. Uneori trimiteți cereri prea repede și atingeți limita; uneori serverul este ocupat temporar; Uneori cererea ta este greșită de la început. Ceea ce distinge o integrare solidă de o încercare de amator este faptul că gestionează aceste situații în mod predictiv și automat. În această unitate veți afla despre limitele ratei (RPM/ITPM/OTPM), eroarea 429, reîncercarea cu backoff exponențial și clasificarea corectă a codurilor de eroare HTTP comune. Scopul: construirea unui flux care este atât de robust încât un utilizator nu îl va observa niciodată.

Ce sunt limitele de viteză?

Furnizorul limitează cât de multă muncă poate face un comutator într-o anumită perioadă de timp. Această protecție; Protejează atât infrastructura, cât și pe tine de exploziile bruște ale costurilor. Există trei tipuri comune de limite:

RPM (Solicitări pe minut): numărul de solicitări pe minut.
ITPM (Input Tokens Per Minute): Jeton de intrare care poate fi procesat pe minut.
OTPM (Jetoane de ieșire pe minut): Jeton de ieșire care poate fi produs pe minut.

Dacă depășiți oricare dintre aceste limite, furnizorul respinge cererea și returnează un cod de eroare 429. Limitele variază în general în funcție de nivelul (nivelul) contului dvs. și pot fi crescute în timp.

Sfat: Puteți urmări când vă apropiați de limita din anteturile de răspuns. Majoritatea furnizorilor raportează cota rămasă cu antete precum x-ratelimit-remaining-*. Monitorizarea acestor valori și accelerarea traficului din față este cel mai matur mod de a preveni problema fără a obține un 429.

429 și Retracere exponențială

429 (limită de viteză) este o eroare temporară și care poate fi reîncercată. Răspunsul corect este să așteptați solicitarea un timp și să încercați din nou. Dar o așteptare constantă nu este suficientă; Dacă toată lumea încearcă din nou în același timp, limita va fi atinsă din nou. Soluția este backoff-ul exponențial: creșterea exponențială a timpului de așteptare cu fiecare încercare eșuată.

# Încercarea logică de backoff exponențială 1 → 429 → așteptați 1 sec încercare 2 → 429 → așteptați 2 sec încercarea 3 → 429 → așteptați 4 sec încercarea 4 → 429 → așteptați 8 sec (+ mic „jitter”)... renunțați și raportați după cel mult N încercări

Adăugarea unui pic de aleatorie (jitter) la aceasta previne ciocnirea cererilor atunci când încearcă să reîncerce în același timp. În plus, răspunsul 429 poartă adesea un antet „retry-after”: „încercați din nou în atâtea secunde”. Respectarea acestui titlu este mai corectă decât așteptarea orbește.

Atenție: Când obțineți un 429, „forțarea lui prin trimiterea mai multor solicitări” va înrăutăți situația; Limita continuă să fie umplută și nu trece nicio solicitare. Răspunsul corect este retragerea, nu accelerarea. Vești bune: majoritatea SDK-urilor oficiale reîncercă automat 429 și erorile de server cu o retragere - folosește acest comportament al SDK-ului înainte de a-l instala manual.

Clasificarea codurilor de eroare HTTP

Nu toate greșelile sunt la fel. Distincție critică: poate fi reîncercată sau este o problemă de cerere/identitate?

Cod

Înțeles

Se poate incerca din nou?

răspuns corect

400

Solicitare nevalidă (eroare de format/parametru)

Corectați cererea; nu mai trimite la fel

401

Eroare de autentificare (cheie invalidă/lipsă)

Remediați cheia/titlul

403

Fără autorizare (fără acces la model/funcție)

Verificați permisiunile/sfera de aplicare

404

Nu a fost găsit (ID model/punct final incorect)

ID-ul/adresa modelului corect

429

Limita de viteză a fost depășită

Retragere + reîncercare după

500

Eroare de server

Încercați din nou cu retragere

529

Server supraîncărcat

Încercați din nou cu retragere

Regula de aur: 429, 500 și 529 sunt temporare; Se încearcă din nou cu retragere. 400, 401, 403, 404 sunt probleme de cerere/identitate; Încercarea din nou nu o va rezolva și irosește efort. Codul dvs. trebuie să facă distincția între aceste două grupuri.

Pas cu pas: Apel durabil

Trimiteți cererea. Dacă reușiți, continuați.
Clasificați codul de eroare. Se poate incerca din nou?
Dacă se poate încerca: urmați reîncercarea după, aplicați backoff exponențial + jitter, încercați de un număr limitat de ori (de exemplu, 5 max).
Dacă nu ați încercat: Remediați (format/cheie) și opriți; Nu repetați aceeași cerere eronată în buclă.
Luați în considerare renunțarea. Dacă încă nu reușește după n încercări, afișați un mesaj politicos utilizatorului și înregistrați evenimentul (unitatea de urmărire 11).

# Apel robust pseudo-codedene = 0repeat: răspuns = request_at() if response.success: returnează răspuns dacă response.code în [429, 500, 529] și încercați < 5: așteptați = retry_after ?? (2^try sec + jitter) sleep(wait); încercați += 1; git din nou dacă response.code în [400, 401, 403, 404]: save_error(response); return "solicitarea trebuie rezolvată" return "eroare permanentă, încercați mai târziu"

# Feedback politicos pentru utilizator (atunci când încercările sunt epuizate) „Sunt ocupat în acest moment, nu am putut procesa solicitarea dvs. Încercați din nou în curând sau v-am salvat solicitarea, vă voi contacta când este gata.”

Prompt slab / Prompt puternic (aici: design mesaj de eroare)

# WEAK (afișează eroare brută utilizatorului) „Eroare 429: rate_limit_error”

# STRONG (folositor, liniștitor, care sugerează acțiuni) „A existat o congestie temporară în sistem. Am primit solicitarea dumneavoastră în siguranță și este încercată din nou automat. Dacă un rezultat nu apare în câteva secunde, puteți reîmprospăta pagina.”

Dezvăluirea erorii tehnice brute utilizatorului final subminează încrederea și poate fi o vulnerabilitate de securitate. Clasificați erorile la nivel intern și oferiți utilizatorului un mesaj calm, orientat spre acțiune; scrieți doar detaliile tehnice pentru înregistrare.

Trei mini carcase

Cazul 1 — Barcă s-a prăbușit într-o explozie de trafic. Un bot de serviciu pentru clienți a primit 429 de trafic sporit în ziua campaniei; Nu a existat nicio reîncercare în cod, fiecare eroare a fost reflectată direct către utilizator ca o „eroare”. Au adăugat retragere exponențială + reîncercare după; cu același trafic, cererile au trecut cu o întârziere de câteva secunde, utilizatorul nu a văzut erori.

Cazul 2 - Încercați 400 în buclă. O integrare a primit un 404 din cauza unui ID de model nevalid, dar a tratat toate erorile ca „tranzitorii” și a încercat din nou într-o buclă infinită; Bușteniul s-a umflat și s-a creat încărcătură inutilă. Au adăugat clasificarea erorilor: 404 este considerat permanent, bucla este oprită și ID-ul modelului este corectat. Lecție: nu mai încerca fiecare greșeală din nou.

Cazul 3 — Gestionarea limitei din față. O lucrare de îmbogățire a datelor rula în mod constant la limita de 429. Au urmat antetul x-ratelimit-remaining și au reglat traficul conform cotei. Așa că au păstrat un ritm constant chiar sub limită, fără a lua niciun 429s; Lucrarea a fost făcută mai previzibil și mai rapid.

Greșeli comune

Creșterea vitezei în 429: Agravează situația; Treceți la retragere.
Reîncercarea fiecărei erori: 400/401/404 este permanent; Să încerci din nou este o risipă.
Utilizarea așteptării fixe: creează o coliziune; Utilizați exponențial + jitter.
Ignorarea „reîncercare după”: este cel mai precis să respectați timpul specificat de furnizor.
Dezvăluirea erorii brute utilizatorului: zdruncina încrederea, creează vulnerabilități; Clasifică în interior.
Reîncercări nelimitate: setați o limită superioară (de exemplu, 5 reîncercări); apoi renunță cu grație.

Mai profund: cozi de așteptare, concurență și întrerupătoare de circuit

Rezistența unei singure dorințe este primul pas; Adevărata maturitate este gestionarea unui număr mare de solicitări fără a atinge limitele. Aici intră în joc trei concepte.

Coadă: puneți cererile într-o coadă pentru a le trimite într-un ritm controlat, mai degrabă decât imediat. Așezarea în coadă atenuează exploziile bruște de trafic: chiar dacă sosesc 1.000 de solicitări deodată, coada le va elibera cu o rată sub limită. În acest fel preveniți 429, apoi nu trebuie să vă faceți griji că îl remediați.

Limită de concurență: limitați câte solicitări sunt „în aer” în același timp. Solicitările paralele nelimitate umple rapid limitele RPM și TPM. Un plafon rezonabil de concurență (de exemplu, nu mai mult de 10 solicitări simultane) menține limitele și face sistemul previzibil.

Întrerupător de circuit: dacă furnizorul continuă să returneze 500/529, în loc să încerce cu îndârjire fiecare cerere, „întrerupeți circuitul” pentru un timp și eșuați rapid cererea fără a o trimite vreodată. După o așteptare, reporniți circuitul și încercați. Acest model previne prăbușirea sistemului în cazul unei erori temporare a furnizorului.

Împreună, acești trei stabilesc reziliența la nivel de sistem dincolo de logica de reîncercare a unui singur apel. La scară mică, reîncercarea automată a SDK-ului este suficientă; Pe măsură ce scara crește, coada, concurența și întrerupătorul de circuit devin indispensabile. Toate au același scop comun: să reflecte utilizatorului o problemă temporară nu ca un accident, ci ca o întârziere invizibilă de câteva secunde.

Pe scurt

429 revine atunci când limitele de viteză (RPM/ITPM/OTPM) sunt depășite; Aceasta este o eroare temporară și va fi reîncercată folosind retry-after și backoff exponențial + jitter. 500 și 529 sunt și ele provizorii; 400/401/403/404 este o problemă de solicitare/identitate și nu poate fi rezolvată încercând din nou. Un flux robust separă erorile în aceste două grupuri, încearcă un număr limitat de ori, monitorizează limita din față și arată mesaje calme utilizatorului.

Sarcina de aplicare

Luați în considerare integrarea dvs. (1) Enumerați codurile de eroare pe care le puteți întâlni și separați-le în „reîncercat/permanent”. (2) Notează-ți planul de retragere exponențială (reținere inițială, coeficient, limită, jitter). (3) Specificați cum să utilizați antetul retry-after. (4) Scrieți mesajul politicos care urmează să fie afișat utilizatorului când reîncercările sunt epuizate.

lista de verificare

[ ] Pot explica limitele RPM/ITPM/OTPM și 429.
[ ] Pot aplica logica retragerii exponențiale + jitter + retry-after.
[ ] Pot clasifica codurile de eroare ca reîncercabile/permanente.
[ ] Știu că nu ar trebui să încercăm fiecare greșeală.
[ ] În loc de o eroare brută, pot arăta utilizatorului un mesaj calm, orientat spre acțiune.