Dobički:
- Lahko interpretira omejitve hitrosti (RPM/ITPM/OTPM) in napake 429
- Implementira eksponentni odmik in ponovni poskus s ponovnim poskusom
- Pravilno razvršča in obravnava pogoste kode napak HTTP (400/401/429/500/529)
V proizvodnem okolju se noben API ne odziva popolnoma ves čas. Včasih pošljete zahteve prehitro in dosežete omejitev; včasih je strežnik začasno zaseden; Včasih je vaša zahteva napačna že od začetka. Kar razlikuje trdno integracijo od amaterskega poskusa, je, da obravnava te situacije predvidljivo in samodejno. V tej enoti se boste naučili o omejitvah hitrosti (RPM/ITPM/OTPM), napaki 429, ponovnem poskusu z eksponentnim odmikom in pravilni klasifikaciji pogostih kod napak HTTP. Cilj: zgraditi tok, ki je tako robusten, da ga uporabnik ne bo nikoli opazil.
Kaj so omejitve hitrosti?
Ponudnik omeji, koliko dela lahko stikalo opravi v določenem časovnem obdobju. Ta zaščita; Ščiti infrastrukturo in vas pred nenadnimi eksplozijami stroškov. Obstajajo tri običajne vrste omejitev:
- RPM (Zahteve na minuto): Število zahtev na minuto.
- ITPM (Vhodni žetoni na minuto): Vhodni žeton, ki se lahko obdela na minuto.
- OTPM (izhodni žetoni na minuto): izhodni žeton, ki ga je mogoče proizvesti na minuto.
Če presežete katero od teh omejitev, ponudnik zavrne zahtevo in vrne kodo napake 429. Omejitve se na splošno razlikujejo glede na raven vašega računa (stopnjo) in se lahko sčasoma povečajo.
Namig: iz glav odgovorov lahko spremljate, kdaj se približujete omejitvi. Večina ponudnikov poroča o vaši preostali kvoti z naslovi, kot je x-ratelimit-remaining-*. Spremljanje teh vrednosti in dušenje prometa spredaj je najbolj zrel način za preprečevanje težave, ne da bi dobili 429.
429 in eksponentni odmik
429 (omejitev hitrosti) je začasna napaka, ki jo je mogoče znova poskusiti. Pravilen odgovor je, da nekaj časa počakate na zahtevo in poskusite znova. Toda nenehno čakanje ni dovolj; Če vsi poskusijo znova hkrati, bo omejitev znova dosežena. Rešitev je eksponentni povratek: z vsakim neuspelim poskusom se čakalni čas eksponentno poveča.
# Eksponentni logični poskus odmika 1 → 429 → počakajte 1 sekundo, poskus 2 → 429 → počakajte 2 sekunde, poskus 3 → 429 → počakajte 4 sekunde, poskus 4 → 429 → počakajte 8 sekund (+ majhen naključni "tresenje")... obupajte in poročajte po največ N poskusih
Če k temu dodamo malo naključnosti (trepetanja), preprečimo trčenje zahtev, ko poskušajo istočasno poskusiti znova. Poleg tega ima odgovor 429 pogosto glavo `ponovi-po`: "poskusi znova čez toliko sekund". Spoštovanje tega naziva je bolj natančno kot slepo čakanje.
Pozor: Ko dobite 429, bo "silitev s pošiljanjem več zahtev" poslabšalo situacijo; Omejitev se še naprej polni in nobena zahteva ne gre skozi. Pravilen odziv je umik, ne pospešek. Dobra novica: večina uradnih SDK-jev samodejno znova poskusi napake 429 in strežnika z odlogom — uporabite to vedenje SDK-ja, preden ga ročno namestite.
Razvrščanje kod napak HTTP
Vsaka napaka ni enaka. Kritično razlikovanje: ali je mogoče poskusiti znova ali gre za zahtevo/identiteto?
Koda
Pomen
Ali se lahko poskusi znova?
pravilen odgovor
400
Neveljavna zahteva (napaka formata/parametra)
št
Popravite zahtevo; ne pošiljaj istega več
401
Napaka pri preverjanju pristnosti (ključ ni veljaven/manjka)
št
Popravi ključ/naslov
403
Brez avtorizacije (ni dostopa do modela/funkcije)
št
Preverite dovoljenja/obseg
404
Ni najdeno (napačen ID modela/končna točka)
št
Pravilni ID/naslov modela
429
Omejitev hitrosti je presežena
ja
Umik + ponovni poskus
500
Napaka strežnika
ja
Poskusite znova z umikom
529
Strežnik preobremenjen
ja
Poskusite znova z umikom
Zlato pravilo: 429, 500 in 529 so začasni; Ponovno se poskusi z odvzemom. 400, 401, 403, 404 so težave z zahtevo/identiteto; Ponovni poskus ne bo rešil težave in je zaman truda. Vaša koda mora razlikovati med tema dvema skupinama.
Korak za korakom: vzdržljiv klic
- Oddajte zahtevo. Če je uspešno, nadaljujte.
- Razvrstite kodo napake. Ali se lahko poskusi znova?
- Če ga je mogoče preizkusiti: sledite ponovnemu poskusu, uporabite eksponentno odmikanje + tresenje, poskusite omejeno število krat (npr. največ 5).
- Če niste poskusili: Popravite (format/ključ) in ustavite; Ne ponovite iste napačne zahteve v zanki.
- Razmislite o odpovedi. Če je po n poskusih še vedno neuspešno, pokažite uporabniku vljudno sporočilo in zabeležite dogodek (sledilna enota 11).
# Robustni klic pseudo-codedene = 0repeat: response = request_at() if response.success: vrni odgovor if response.code v [429, 500, 529] in poskusi < 5: wait = retry_after ?? (2^poskusi s + tresenje) spanje(čakaj); poskusi += 1; ponovno git, če je response.code v [400, 401, 403, 404]: save_error(response); return "zahtevo je treba popraviti" return "trajna napaka, poskusite pozneje"
# Vljudna povratna informacija za uporabnika (ko so ponovni poskusi izčrpani) "Trenutno sem zaposlen, nisem mogel obdelati vaše zahteve. Poskusite znova kmalu ali pa sem shranil vašo zahtevo, oglasil se vam bom, ko bo pripravljena."
Šibek poziv/močan poziv (tukaj: zasnova sporočila o napaki)
# WEAK (prikaže neobdelano napako uporabniku)"Napaka 429: rate_limit_error"
# MOČNO (uporabniku prijazno, pomirjujoče, predlaga ukrepanje) "V sistemu je prišlo do začasne prezasedenosti. Varno smo prejeli vašo zahtevo in samodejno jo poskušamo ponovno poskusiti. Če se rezultat ne prikaže v nekaj sekundah, lahko osvežite stran."
Razkritje neobdelane tehnične napake končnemu uporabniku spodkopava zaupanje in je lahko varnostna ranljivost. Notranje kategorizirajte napake in dajte uporabniku mirno, akcijsko sporočilo; samo napišite tehnične podrobnosti za zapisnik.
Trije mini kovčki
Primer 1 – Čoln se je zrušil v prometni eksploziji. Bot za pomoč strankam je na dan kampanje prejel 429 v povečanem prometu; V kodi ni bilo ponovnega poskusa, vsaka napaka se je odražala neposredno uporabniku kot "napaka". Dodali so eksponentno retracement + retry-after; z enakim prometom so zahteve prešle z zamikom nekaj sekund, uporabnik ni videl nobenih napak.
2. primer — poskus 400 v zanki. Integracija je dobivala 404 zaradi neveljavnega ID-ja modela, vendar je vse napake obravnavala kot "prehodne" in poskušala znova v neskončni zanki; Hlod je nabrekel in nastala je nepotrebna obremenitev. Dodali so klasifikacijo napak: 404 velja za trajno, zanka je ustavljena in ID modela je popravljen. Nauk: ne poskušajte vsake napake znova.
Primer 3 – Upravljanje omejitve od spredaj. Opravilo za obogatitev podatkov je nenehno potekalo pri omejitvi 429. Sledili so glavi x-ratelimit-remaining in dušili promet v skladu s kvoto. Tako so ohranili enakomeren tempo tik pod mejo, ne da bi vzeli 429s; Delo je bilo opravljeno bolj predvidljivo in hitreje.
Pogoste napake
- Povečanje hitrosti v 429: poslabša situacijo; Preklopite na umik.
- Ponovni poskus vsake napake: 400/401/404 je trajna; Poskušati znova je izguba.
- Uporaba fiksnega čakanja: ustvari trk; Uporabite eksponentno + tresenje.
- Ignoriranje 'ponovnega poskusa': najbolj natančno je upoštevati čas, ki ga določi ponudnik.
- Razkrivanje neobdelane napake uporabniku: Zamaje zaupanje, ustvarja ranljivosti; Razvrsti znotraj.
- Neomejeno število ponovnih poskusov: nastavite zgornjo mejo (npr. 5 ponovnih poskusov); nato elegantno obupajte.
Deeper: čakalne vrste, sočasnost in odklopniki
Vzdržljivost ene same želje je prvi korak; Prava zrelost je upravljanje velikega števila zahtev, ne da bi dosegli omejitve. Tu pridejo v poštev trije koncepti.
Čakalna vrsta: zahteve postavite v čakalno vrsto, da jih pošljete z nadzorovano hitrostjo in ne takoj. Čakalna vrsta zgladi nenadne izbruhe prometa: tudi če naenkrat prispe 1000 zahtev, jih bo čakalna vrsta sprostila s hitrostjo pod omejitvijo. Na ta način preprečite 429, potem vam ni treba skrbeti, da bi ga popravili.
Omejitev sočasnosti: omejite, koliko zahtev je hkrati "v zraku". Neomejene vzporedne zahteve hitro zapolnijo omejitve RPM in TPM. Razumna zgornja meja sočasnosti (npr. ne več kot 10 sočasnih zahtev) ohranja omejitve in naredi sistem predvidljiv.
Prekinjevalec tokokroga: Če ponudnik vedno znova vrača 500/529, namesto da bi vztrajno preizkušali vsako zahtevo, za nekaj časa "prekinete tokokrog" in hitro zavrnete zahtevo, ne da bi jo sploh poslali. Po čakanju znova vklopite vezje in poskusite. Ta vzorec preprečuje, da bi se vaš sistem zrušil v primeru začasne okvare ponudnika.
Ti trije skupaj vzpostavijo odpornost na sistemski ravni, ki presega logiko ponovnega poskusa enega klica. V majhnem obsegu zadostuje samodejni ponovni poskus SDK-ja; Ko obseg raste, postajajo čakalne vrste, sočasnost in prekinjevalci tokokroga nepogrešljivi. Vsi imajo isti skupni cilj: uporabniku prikazati začasno težavo ne kot zrušitev, temveč kot nevidno nekajsekundno zamudo.
Če povzamem
429 se vrne, ko so prekoračene omejitve hitrosti (RPM/ITPM/OTPM); To je začasna napaka in se bo znova poskusilo z uporabo ponovnega poskusa in eksponentnega odmika + tresenje. 500 in 529 sta tudi začasni; 400/401/403/404 je težava z zahtevo/identiteto in je ni mogoče rešiti s ponovnim poskusom. Robusten tok loči napake v ti dve skupini, poskusi omejeno število krat, nadzoruje omejitev od spredaj in uporabniku prikazuje mirna sporočila.
Aplikacijska naloga
Razmislite o svoji integraciji. (1) Navedite kode napak, na katere lahko naletite, in jih ločite na »ponovno poskusiti/trajno«. (2) Zapišite svoj načrt eksponentnega umika (začetni zadržek, koeficient, zgornja meja, tresenje). (3) Določite, kako uporabiti glavo za ponovitev. (4) Napišite vljudno sporočilo, ki bo prikazano uporabniku, ko bo ponovnih poskusov izčrpano.
kontrolni seznam
- [ ] Lahko razložim omejitve RPM/ITPM/OTPM in 429.
- [ ] Lahko uporabim logiko eksponentnega umika + tresenja + ponovnega poskusa.
- [ ] Kode napak lahko razvrstim kot poskusne/trajne.
- [ ] Vem, da ne bi smeli poskusiti vsake napake.
- [ ] Namesto neobdelane napake lahko uporabniku pokažem mirno, akcijsko usmerjeno sporočilo.