Dobici:
- Može interpretirati ograničenja brzine (RPM/ITPM/OTPM) i 429 grešaka
- Implementira eksponencijalno povlačenje i ponovni pokušaj s ponovnim pokušajem nakon
- Ispravno klasifikuje i obrađuje uobičajene HTTP kodove grešaka (400/401/429/500/529)
U proizvodnom okruženju, nijedan API ne reagira savršeno cijelo vrijeme. Ponekad zahtjeve šaljete prebrzo i dostižete ograničenje; ponekad je server privremeno zauzet; Ponekad je vaš zahtjev pogrešan od početka. Ono što razlikuje čvrstu integraciju od amaterskog pokušaja je to što ona rješava ove situacije prediktivno i automatski. U ovoj jedinici ćete naučiti o ograničenjima brzine (RPM/ITPM/OTPM), grešci 429, ponovnom pokušaju s eksponencijalnim povlačenjem i pravilnoj klasifikaciji uobičajenih HTTP kodova grešaka. Cilj: izgraditi tok koji je toliko robustan da ga korisnik nikada neće primijetiti.
Šta su ograničenja brzine?
Provajder ograničava koliko posla prekidač može obaviti u datom vremenskom periodu. Ova zaštita; Štiti i infrastrukturu i vas od iznenadnih eksplozija troškova. Postoje tri uobičajene vrste ograničenja:
- RPM (Requests Per Minute): Broj zahtjeva u minuti.
- ITPM (Input Tokens Per Minute): Ulazni token koji se može obraditi u minuti.
- OTPM (Output Tokens Per Minute): Izlazni token koji se može proizvesti u minuti.
Ako prekoračite bilo koje od ovih ograničenja, provajder odbija zahtjev i vraća kod greške 429. Ograničenja općenito variraju ovisno o nivou vašeg računa (nivou) i mogu se vremenom povećati.
Savjet: Možete gledati kada se približavate ograničenju iz zaglavlja odgovora. Većina provajdera prijavljuje vašu preostalu kvotu sa zaglavljima poput x-ratelimit-remaining-*. Praćenje ovih vrijednosti i smanjenje prometa ispred je najzreliji način da se spriječi problem bez dobivanja 429.
429 i eksponencijalni retracement
429 (ograničenje brzine) je privremena greška koja se može ponoviti. Ispravan odgovor je sačekati zahtjev neko vrijeme i pokušati ponovo. Ali stalno čekanje nije dovoljno; Ako svi pokušaju ponovo u isto vrijeme, ograničenje će ponovo biti dostignuto. Rješenje je eksponencijalno povlačenje: eksponencijalno povećanje vremena čekanja sa svakim neuspjelim pokušajem.
# Eksponencijalna logička proba 1 → 429 → čekaj 1 sekunda proba 2 → 429 → čekaj 2 sekunde proba 3 → 429 → čekaj 4 sekunde proba 4 → 429 → čekaj 8 sekundi (+ mali nasumični "drhtanje")... odustani i prijavi nakon najviše N pokušaja
Dodavanje malo nasumičnosti (itter) ovome sprečava da se zahtjevi sudare pri pokušaju ponovnog pokušaja u isto vrijeme. Dodatno, odgovor 429 često nosi zaglavlje `pokušaj nakon`: "pokušaj ponovo za ovoliko sekundi". Poštivanje ovog naslova je tačnije nego slijepo čekanje.
Oprez: Kada dobijete 429, "forsiranje slanjem više zahtjeva" će pogoršati situaciju; Limit se i dalje ispunjava i nijedan zahtjev ne prolazi. Ispravan odgovor je povlačenje, a ne ubrzanje. Dobre vijesti: većina zvaničnih SDK-ova automatski ponovo pokušava 429 i greške servera uz povlačenje — koristite ovo ponašanje SDK-a prije nego što ga ručno instalirate.
Klasifikacija HTTP kodova grešaka
Nije svaka greška ista. Kritična razlika: može li se ponovo pokušati ili je u pitanju zahtjev/identitet?
Kod
Značenje
Može li se probati ponovo?
tačan odgovor
400
Nevažeći zahtjev (greška formata/parametra)
br
Ispravite zahtjev; nemojte ponovo slati isto
401
Greška u autentifikaciji (ključ nevažeći/nedostaje)
br
Popravi ključ/naslov
403
Nema autorizacije (nema pristupa modelu/funkciji)
br
Provjerite dozvole/opseg
404
Nije pronađeno (netačan ID modela/krajnja tačka)
br
Ispravan ID/adresa modela
429
Ograničenje brzine je prekoračeno
Da
Povlačenje + ponovni pokušaj nakon
500
Greška servera
Da
Pokušajte ponovo sa povlačenjem
529
Server je preopterećen
Da
Pokušajte ponovo sa povlačenjem
Zlatno pravilo: 429, 500 i 529 su privremeni; Pokušava se ponovo sa povlačenjem. 400, 401, 403, 404 su pitanja zahtjeva/identiteta; Ponovni pokušaj to neće riješiti, a gubi trud. Vaš kod mora razlikovati ove dvije grupe.
Korak po korak: Trajni poziv
- Pošaljite zahtjev. Ako je uspješno, nastavite.
- Klasifikujte šifru greške. Može li se probati ponovo?
- Ako je moguće: slijedite pokušaj ponovno nakon, primijenite eksponencijalno povlačenje + podrhtavanje, pokušajte ograničen broj puta (npr. maksimalno 5).
- Ako se ne pokuša: Popravi (format/ključ) i zaustavi; Nemojte ponavljati isti pogrešan zahtjev u petlji.
- Razmislite o odustajanju. Ako i dalje ne uspije nakon n pokušaja, pokažite ljubaznu poruku korisniku i zabilježite događaj (jedinica za praćenje 11).
# Robustan poziv pseudo-codedene = 0repeat: response = request_at() if response.success: vrati odgovor if response.code u [429, 500, 529] i pokušaj < 5: čekati = retry_after ?? (2^pokušaj sek + podrhtavanje) sleep(wait); pokušaj += 1; git ponovo if response.code u [400, 401, 403, 404]: save_error(response); vrati "zahtjev mora biti popravljen" vrati "trajna greška, pokušaj kasnije"
# Ljubazna povratna informacija korisniku (kada su ponovljeni pokušaji iscrpljeni) "Trenutno sam zauzet, nisam mogao obraditi vaš zahtjev. Pokušajte ponovo uskoro, ili sam sačuvao vaš zahtjev, javit ću vam se kada bude spreman."
Slaba prompt / Jaka prompt (ovdje: dizajn poruke o grešci)
# WEAK (prikazuje sirovu grešku korisniku) "Greška 429: rate_limit_error"
# JAKO (prilagođen korisniku, umirujući, predlaže radnju) "Došlo je do privremene zagušenja u sistemu. Sigurno smo primili vaš zahtjev i automatski se pokušava ponovo. Ako se rezultat ne pojavi u roku od nekoliko sekundi, možete osvježiti stranicu."
Otkrivanje sirove tehničke greške krajnjem korisniku podriva povjerenje i može predstavljati sigurnosni propust. Interno kategorizirajte greške i dajte korisniku mirnu poruku usmjerenu na akciju; samo napišite tehničke detalje za zapisnik.
Tri mini futrole
Slučaj 1 — Čamac se srušio u saobraćajnoj eksploziji. Bot za korisničku podršku dobio je 429 u porastu prometa na dan kampanje; Nije bilo ponovnog pokušaja u kodu, svaka greška se direktno odrazila na korisnika kao "greška". Dodali su eksponencijalni retracement + retry-after; sa istim prometom, zahtjevi su prolazili sa zakašnjenjem od nekoliko sekundi, korisnik nije vidio greške.
Slučaj 2 — Pokušavam 400 u petlji. Integracija je dobijala 404 zbog nevažećeg ID modela, ali je sve greške tretirala kao "prolazne" i pokušavala ponovo u beskonačnoj petlji; Trup je nabrekao i stvorio se nepotreban teret. Dodali su klasifikaciju grešaka: 404 se smatra trajnom, petlja je zaustavljena i ID modela je ispravljen. Pouka: ne pokušavajte svaku grešku ponovo.
Slučaj 3 — Upravljanje limitom s prednje strane. Posao obogaćivanja podataka je stalno radio na granici od 429. Pratili su zaglavlje x-ratelimit-remaining i ugasili promet prema kvoti. Tako su držali stabilan tempo malo ispod granice, bez ikakvih 429; Posao je obavljen predvidljivije i brže.
Uobičajene greške
- Povećanje brzine u 429: pogoršava situaciju; Prebacite se na povlačenje.
- Ponovni pokušaj svake greške: 400/401/404 je trajno; Pokušaj ponovo je gubitak.
- Korištenje fiksnog čekanja: Stvara koliziju; Koristite eksponencijalno + podrhtavanje.
- Zanemarivanje 'retry-after': Najtačnije je pridržavati se vremena koje je odredio provajder.
- Otkrivanje sirove greške korisniku: poljulja povjerenje, stvara ranjivosti; Klasifikujte unutra.
- Neograničeni pokušaji: Postavite gornju granicu (npr. 5 pokušaja); onda graciozno odustani.
Dublje: red čekanja, istovremenost i prekidači
Izdržljivost jedne želje je prvi korak; Prava zrelost je upravljati velikim brojem zahtjeva bez dostizanja granica. Ovdje se pojavljuju tri koncepta.
Red: zahtjeve stavljate u red čekanja da ih pošaljete kontroliranim tempom, a ne odmah. Red čekanja izglađuje iznenadne navale prometa: čak i ako 1.000 zahtjeva stigne odjednom, red će ih otpustiti brzinom ispod granice. Na ovaj način spriječite 429, a onda ne morate brinuti o popravljanju.
Ograničenje istovremenosti: Ograničavate koliko je zahtjeva "u zraku" u isto vrijeme. Neograničeni paralelni zahtjevi brzo ispunjavaju RPM i TPM ograničenja. Razumna gornja granica istovremenosti (npr. ne više od 10 istovremenih zahtjeva) održava ograničenja i čini sistem predvidljivim.
Prekidač strujnog kruga: Ako provajder stalno vraća 500/529, umjesto da uporno pokušavate svaki zahtjev, vi "prekidate strujno kolo" na neko vrijeme i brzo propadate zahtjev, a da ga nikada niste poslali. Nakon čekanja, ponovo uključite krug i pokušate. Ovaj obrazac sprečava da se vaš sistem sruši u slučaju privremenog kvara dobavljača.
Zajedno, ova tri uspostavljaju otpornost na nivou sistema izvan logike ponovnog pokušaja jednog poziva. U malom obimu, automatski ponovni pokušaj SDK-a je dovoljan; Kako obim raste, red čekanja, istovremenost i prekidač postaju nezamjenjivi. Svi imaju isti zajednički cilj: prikazati privremeni problem korisniku ne kao pad, već kao nevidljivo kašnjenje od nekoliko sekundi.
Ukratko
429 se vraća kada su ograničenja brzine (RPM/ITPM/OTPM) prekoračena; Ovo je privremena greška i pokušat će se ponovno korištenjem ponovnog pokušaja nakon i eksponencijalnog povlačenja + podrhtavanje. 500 i 529 su takođe privremeni; 400/401/403/404 je problem sa zahtjevom/identitetom i ne može se riješiti ponovnim pokušajem. Robustan tok razdvaja greške u ove dvije grupe, pokušava ograničen broj puta, prati ograničenje s prednje strane i pokazuje mirne poruke korisniku.
Zadatak aplikacije
Razmotrite svoju integraciju. (1) Navedite kodove grešaka na koje možete naići i razdvojite ih u "ponovljeni / trajni". (2) Zapišite svoj eksponencijalni plan povlačenja (početno zadržavanje, koeficijent, ograničenje, podrhtavanje). (3) Odredite kako koristiti zaglavlje ponovnog pokušaja. (4) Napišite ljubaznu poruku koja će se prikazati korisniku kada se potroše pokušaji.
kontrolna lista
- [ ] Mogu objasniti RPM/ITPM/OTPM ograničenja i 429.
- [ ] Mogu primijeniti logiku eksponencijalnog povlačenja + podrhtavanja + ponovnog pokušaja.
- [ ] Mogu klasifikovati kodove grešaka kao ponovni pokušaj/trajne.
- [ ] Znam da ne treba pokušavati svaku grešku.
- [ ] Umjesto neobrađene greške, mogu pokazati korisniku mirnu poruku usmjerenu na akciju.