Dobici:
- Može interpretirati ograničenja brzine (RPM/ITPM/OTPM) i 429 pogreške
- Implements exponential backoff and retry with retry-after
- Ispravno klasificira i obrađuje uobičajene HTTP kodove grešaka (400/401/429/500/529)
U produkcijskom okruženju niti jedan API ne reagira savršeno cijelo vrijeme. Ponekad šaljete zahtjeve prebrzo i dosegnete ograničenje; ponekad je poslužitelj privremeno zauzet; Ponekad je vaš zahtjev pogrešan od samog početka. What distinguishes a solid integration from an amateur attempt is that it handles these situations predictively and automatically. In this unit you will learn about rate limits (RPM/ITPM/OTPM), 429 error, retry with exponential backoff, and proper classification of common HTTP error codes. Cilj: izgraditi tijek koji je toliko robustan da ga korisnik nikada neće primijetiti.
Što su ograničenja brzine?
Davatelj ograničava koliko posla prekidač može obaviti u određenom vremenskom razdoblju. Ova zaštita; Štiti i infrastrukturu i vas od iznenadnih eksplozija troškova. Postoje tri uobičajene vrste ograničenja:
- RPM (Zahtjevi po minuti): Broj zahtjeva po minuti.
- ITPM (ulazni tokeni po minuti): ulazni token koji se može obraditi po minuti.
- OTPM (Izlazni tokeni po minuti): Izlazni token koji se može proizvesti po minuti.
Ako premašite bilo koje od ovih ograničenja, pružatelj odbija zahtjev i vraća šifru pogreške 429. Ograničenja općenito variraju ovisno o razini računa (razini) i mogu se povećati tijekom vremena.
Savjet: iz zaglavlja odgovora možete pratiti kada se približavate ograničenju. Većina pružatelja izvješćuje o vašoj preostaloj kvoti sa zaglavljima poput x-ratelimit-remaining-*. Praćenje ovih vrijednosti i usporavanje prometa ispred je najzreliji način da se spriječi problem bez dobivanja 429.
429 i eksponencijalni povratak
429 (ograničenje brzine) je privremena pogreška koja se može ponoviti. Ispravan odgovor je pričekati zahtjev neko vrijeme i pokušati ponovno. Ali stalno čekanje nije dovoljno; Ako svi pokušaju ponovno u isto vrijeme, ograničenje će biti ponovno dosegnuto. Rješenje je eksponencijalni backoff: eksponencijalno povećanje vremena čekanja sa svakim neuspjelim pokušajem.
# Logički pokušaj eksponencijalne povlačenja 1 → 429 → čekanje 1 sekunde, pokušaj 2 → 429 → čekanje 2 sekunde, pokušaj 3 → 429 → čekanje 4 sekunde, pokušaj 4 → 429 → čekanje 8 sekundi (+ mali nasumični "jitter")... odustanite i prijavite se nakon najviše N pokušaja
Dodavanje malo nasumičnosti (podrhtavanje) ovome sprječava sudaranje zahtjeva pri pokušaju ponovnog pokušaja u isto vrijeme. Osim toga, odgovor 429 često nosi zaglavlje `ponovi-nakon`: "pokušaj ponovo za ovoliko sekundi". Poštivanje ove titule točnije je od slijepog čekanja.
Oprez: kada dobijete 429, "forsiranje slanjem više zahtjeva" pogoršat će situaciju; Limit se i dalje popunjava i nijedan zahtjev ne prolazi. Ispravan odgovor je povlačenje, a ne ubrzanje. Dobre vijesti: većina službenih SDK-ova automatski ponovno iskušava 429 i pogreške poslužitelja s odmakom — upotrijebite ovo ponašanje SDK-a prije nego što ga ručno instalirate.
Klasificiranje HTTP kodova grešaka
Nije svaka greška ista. Kritična razlika: može li se pokušati ponovo ili je to problem sa zahtjevom/identitetom?
Šifra
Značenje
Može li se pokušati ponovno?
točan odgovor
400
Nevažeći zahtjev (pogreška formata/parametra)
br
Ispravite zahtjev; nemojte više slati isto
401
Pogreška autentifikacije (ključ nije valjan/nedostaje)
br
Popravi ključ/naslov
403
Nema autorizacije (nema pristupa modelu/značajki)
br
Provjerite dopuštenja/opseg
404
Nije pronađeno (netočan ID modela/krajnja točka)
br
Ispravan ID/adresa modela
429
Ograničenje brzine premašeno
da
Povlačenje + ponovni pokušaj nakon
500
Greška poslužitelja
da
Pokušajte ponovno s povlačenjem
529
Poslužitelj preopterećen
da
Pokušajte ponovno s povlačenjem
Zlatno pravilo: 429, 500 i 529 su privremeni; Pokušava se ponovno s povlačenjem. 400, 401, 403, 404 su problemi zahtjeva/identiteta; Ponovni pokušaj neće riješiti problem i uzalud troši trud. Vaš kod mora razlikovati ove dvije skupine.
Korak po korak: Izdržljiv poziv
- Pošaljite zahtjev. Ako uspije, nastavite.
- Klasificirajte šifru pogreške. Može li se pokušati ponovno?
- Ako se može isprobati: slijedite ponovni pokušaj nakon, primijenite eksponencijalno povlačenje + podrhtavanje, pokušajte ograničeni broj puta (npr. maksimalno 5).
- Ako nije pokušano: 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 uljudnu poruku korisniku i zabilježite događaj (jedinica za praćenje 11).
# Robusni poziv pseudo-codedene = 0repeat: response = request_at() if response.success: return response if response.code in [429, 500, 529] and try < 5: wait = retry_after ?? (2^pokušaj sek + podrhtavanje) spavanje (čekanje); pokušaj += 1; ponovno git if response.code u [400, 401, 403, 404]: save_error(response); return "zahtjev se mora popraviti" return "trajna pogreška, pokušaj kasnije"
# Ljubazna povratna informacija korisniku (kada se iscrpe ponovni pokušaji) "Trenutno sam zauzet, nisam mogao obraditi vaš zahtjev. Pokušajte ponovno uskoro ili sam spremio vaš zahtjev, javit ću vam se kada bude spreman."
Slab upit / Jak upit (ovdje: dizajn poruke o pogrešci)
# SLABO (prikazuje neobrađenu pogrešku korisniku)"Pogreška 429: rate_limit_error"
# SNAŽNO (korisnički prilagođeno, umirujuće, sugerira radnju) "Došlo je do privremenog zagušenja u sustavu. Sigurno smo primili vaš zahtjev i automatski ga pokušavamo ponovno izvršiti. Ako se rezultat ne pojavi u roku od nekoliko sekundi, možete osvježiti stranicu."
Otkrivanje neobrađene tehničke pogreške krajnjem korisniku potkopava povjerenje i može biti sigurnosna ranjivost. Interno kategorizirajte pogreške i dajte korisniku smirenu poruku usmjerenu na djelovanje; samo napišite tehničke detalje za zapisnik.
Tri mini kućišta
Slučaj 1 — Brod se srušio u prometnoj eksploziji. Bot korisničke službe primio je 429 u velikom prometu na dan kampanje; U kodu nije bilo ponovnog pokušaja, svaka se pogreška odražavala izravno korisniku kao "pogreška". Dodali su eksponencijalni retracement + ponovni pokušaj nakon; s istim prometom, zahtjevi su prošli s kašnjenjem od nekoliko sekundi, korisnik nije vidio nikakve pogreške.
Slučaj 2 — Pokušaj 400 u petlji. Integracija je dobivala 404 zbog nevažećeg ID-a modela, ali je tretirala sve pogreške kao "prolazne" i pokušavala ponovno u beskonačnoj petlji; Cjepanica je nabubrila i stvorilo se nepotrebno opterećenje. Dodali su klasifikaciju pogrešaka: 404 se smatra trajnom, petlja se zaustavlja i ID modela se ispravlja. Pouka: ne pokušavajte svaku pogrešku ponovno.
Slučaj 3 — Upravljanje ograničenjem sprijeda. Posao obogaćivanja podataka stalno se izvodio na ograničenju od 429. Slijedili su x-ratelimit-remain header i prigušili promet prema kvoti. Tako su držali stabilan tempo malo ispod granice, bez ikakvih 429s; 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 pogreške: 400/401/404 je trajno; Ponovni pokušaj je gubitak.
- Korištenje fiksnog čekanja: Stvara sudar; Koristite eksponencijalni + podrhtavanje.
- Ignoriranje 'ponovnog pokušaja': Najtočnije je pridržavati se vremena koje je odredio davatelj.
- Otkrivanje sirove pogreške korisniku: poljulja povjerenje, stvara ranjivosti; Razvrstaj unutra.
- Neograničeni ponovni pokušaji: postavite gornju granicu (npr. 5 ponovnih pokušaja); zatim graciozno odustati.
Deeper: Queuing, Concurrency i Circuit Breakers
Izdržljivost jedne jedine želje je prvi korak; Prava zrelost je upravljanje velikim brojem zahtjeva bez prekoračenja ograničenja. Ovdje u igru dolaze tri koncepta.
Red čekanja: Zahtjeve stavljate u red čekanja kako biste ih poslali kontroliranim tempom, a ne odmah. Red čekanja ublažava iznenadne navale prometa: Čak i ako 1000 zahtjeva stigne odjednom, red čekanja će ih otpustiti brzinom ispod ograničenja. Na ovaj način spriječite 429, a onda ne morate brinuti o njegovom 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 istodobnih zahtjeva) održava ograničenja i čini sustav predvidljivim.
Prekidač strujnog kruga: Ako pružatelj stalno vraća 500/529, umjesto da uporno pokušavate svaki zahtjev, vi "prekidate strujni krug" na neko vrijeme i brzo odbijate zahtjev bez da ste ga ikada poslali. Nakon čekanja, ponovno uključite krug i pokušajte. Ovaj uzorak sprječava pad vašeg sustava u slučaju privremenog kvara pružatelja usluga.
Zajedno, ovo troje uspostavlja otpornost na razini sustava izvan logike ponovnog pokušaja jednog poziva. U maloj mjeri dovoljan je automatski ponovni pokušaj SDK-a; Kako skala raste, čekanje u redu, istovremenost i prekidač strujnog kruga postaju nezamjenjivi. Svi oni 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 se prekorače ograničenja brzine (RPM/ITPM/OTPM); Ovo je privremena pogreška i pokušat će se ponovno korištenjem ponovnog pokušaja i eksponencijalnog odmaka + podrhtavanje. 500 i 529 također su privremeni; 400/401/403/404 je problem zahtjeva/identiteta i ne može se riješiti ponovnim pokušajem. Robusni tok razdvaja pogreške u ove dvije grupe, pokušava ograničen broj puta, nadzire ograničenje s prednje strane i prikazuje mirne poruke korisniku.
Zadatak aplikacije
Razmislite o svojoj integraciji. (1) Navedite kodove grešaka na koje biste mogli naići i odvojite ih u "ponovni pokušaj / trajno". (2) Zapišite svoj plan eksponencijalnog povlačenja (početno zadržavanje, koeficijent, ograničenje, podrhtavanje). (3) Odredite kako koristiti zaglavlje retry-after. (4) Napišite uljudnu poruku koja će se prikazati korisniku kada ponovni pokušaji budu iscrpljeni.
popis za provjeru
- [ ] Mogu objasniti RPM/ITPM/OTPM ograničenja i 429.
- [ ] Mogu primijeniti logiku eksponencijalnog povlačenja + podrhtavanja + ponovnog pokušaja.
- [ ] Kodove grešaka mogu klasificirati kao moguće ponovno pokušati/trajne.
- [ ] Znam da ne bismo trebali isprobavati svaku grešku.
- [ ] Umjesto neobrađene pogreške, korisniku mogu pokazati smirenu poruku usmjerenu na radnju.