Kasu:
- Oskab tõlgendada kiiruspiiranguid (RPM/ITPM/OTPM) ja 429 vigu
- Rakendab eksponentsiaalset tagandamist ja uuesti proovimist koos korduskatsega
- Klassifitseerib ja käsitleb õigesti levinud HTTP veakoode (400/401/429/500/529)
Tootmiskeskkonnas ei reageeri ükski API kogu aeg ideaalselt. Mõnikord saadate päringuid liiga kiiresti ja saavutate limiidi; mõnikord on server ajutiselt hõivatud; Mõnikord on teie taotlus algusest peale vale. Tugevat integratsiooni eristab amatöörkatsest see, et see käsitleb neid olukordi ennustavalt ja automaatselt. Selles üksuses saate teada kiiruspiirangute (RPM/ITPM/OTPM), 429 vea, eksponentsiaalse tagasilükkamisega uuesti proovimise ja tavaliste HTTP veakoodide õige klassifitseerimise kohta. Eesmärk: luua voog, mis on nii tugev, et kasutaja ei märka seda kunagi.
Mis on kiiruspiirangud?
Pakkuja piirab, kui palju tööd saab lüliti teatud aja jooksul teha. See kaitse; See kaitseb nii infrastruktuuri kui ka teid ootamatute kuluplahvatuste eest. Levinud piiranguid on kolme tüüpi:
- RPM (Requests Per Minute): taotluste arv minutis.
- ITPM (Input Tokens Per Minute): sisendmärk, mida saab töödelda minutis.
- OTPM (Output Tokens Per Minute): väljundmärk, mida saab toota minutis.
Kui ületate mõne neist piirangutest, lükkab teenusepakkuja taotluse tagasi ja tagastab veakoodi 429. Limiidid varieeruvad üldiselt olenevalt teie konto tasemest (tasemest) ja võivad aja jooksul suureneda.
Näpunäide. Vastuste päistest saate vaadata, kui lähenete piirile. Enamik teenusepakkujaid teatab teie järelejäänud kvoodist päistega, nagu x-ratelimit-remaining-*. Nende väärtuste jälgimine ja eesoleva liikluse vähendamine on kõige küpsem viis probleemi ennetamiseks ilma numbrit 429 hankimata.
429 ja eksponentsiaalne retracement
429 (määrapiirang) on ajutine ja uuesti proovitav viga. Õige vastus on oodata mõnda aega päringut ja proovida uuesti. Kuid pidevast ootamisest ei piisa; Kui kõik korraga uuesti proovivad, saab limiit uuesti täis. Lahendus on eksponentsiaalne taganemine: ooteaega suurendatakse eksponentsiaalselt iga ebaõnnestunud katsega.
# Eksponentsiaalne tagasilöögi loogikakatse 1 → 429 → oodake 1 s proovi 2 → 429 → oodake 2 sekundit proovi 3 → 429 → oodake 4 sekundit katset 4 → 429 → oodake 8 sekundit (+ väike juhuslik "värina")... loobuge ja teatage pärast maksimaalselt N katset
Sellele väikese juhuslikkuse (värina) lisamine hoiab ära taotluste põrkumise, kui proovite samal ajal uuesti proovida. Lisaks sisaldab 429 vastus sageli päist "proovi pärast uuesti": "proovi selle mitme sekundi pärast uuesti". Selle tiitli austamine on täpsem kui pimesi ootamine.
Ettevaatust: kui saate numbri 429, muudab "selle sundimine rohkemate päringute saatmisega" olukorra hullemaks; Limiidi täitmine jätkub ja päringud ei lähe läbi. Õige vastus on taandumine, mitte kiirendamine. Hea uudis: enamik ametlikke SDK-sid proovib automaatselt uuesti 429 ja serveri tõrkeid tagasilöögiga – kasutage SDK seda käitumist enne selle käsitsi installimist.
HTTP veakoodide klassifitseerimine
Iga viga pole ühesugune. Kriitiline eristus: kas seda saab uuesti proovida või on see päringu/identiteedi probleem?
Kood
Tähendus
Kas seda saab uuesti proovida?
õige vastus
400
Kehtetu taotlus (vormingu/parameetri viga)
ei
Parandage taotlust; ära saada sama uuesti
401
Autentimisviga (võti on kehtetu/puudub)
ei
Parandage võti/pealkiri
403
Volitus puudub (juurdepääs mudelile/funktsioonile puudub)
ei
Kontrollige õigusi/ulatust
404
Ei leitud (vale mudeli ID/lõpp-punkt)
ei
Õige mudeli ID/aadress
429
Kiirusepiirang ületatud
Jah
Taganemine + proovi uuesti pärast
500
Serveri viga
Jah
Proovige uuesti taganemisega
529
Server on ülekoormatud
Jah
Proovige uuesti taganemisega
Kuldreegel: 429, 500 ja 529 on ajutised; Proovitakse uuesti tagasivõtmisega. 400, 401, 403, 404 on päringu/identiteedi probleemid; Uuesti proovimine ei lahenda seda ja see raiskab jõupingutusi. Teie kood peab neid kahte rühma eristama.
Samm-sammult: vastupidav kõne
- Esitage taotlus. Kui see õnnestub, jätkake.
- Klassifitseerige veakood. Kas seda saab uuesti proovida?
- Kui proovitav: järgige uuesti proovimist, rakendage eksponentsiaalset taganemist + värinat, proovige piiratud arv kordi (nt kuni 5).
- Kui pole proovitud: Paranda (vorming/võti) ja peata; Ärge korrake tsüklis sama ekslikku päringut.
- Kaaluge loobumist. Kui see ka pärast n katset ebaõnnestub, näidake kasutajale viisakat sõnumit ja logige sündmus (jälgimisüksus 11).
# Tugev väljakutse pseudo-codedene = 0repeat: vastus = request_at(), kui vastus.success: tagastab vastuse, kui vastus.kood on [429, 500, 529] ja proovige < 5: oota = uuesti proovi_after ?? (2^proovi sek + värin) magama (oota); proovi += 1; git uuesti, kui vastus.kood in [400, 401, 403, 404]: save_error(response); return "taotlus tuleb parandada" return "püsiv viga, proovige hiljem"
# Viisakas tagasiside kasutajale (kui korduskatsed on ammendunud) "Olen praegu hõivatud, ma ei saanud teie taotlust töödelda. Proovige varsti uuesti või olen teie taotluse salvestanud, võtan teiega ühendust, kui see on valmis."
Nõrk viip / tugev viip (siin: veateate kujundus)
# NÕRK (kuvab kasutajale töötlemata vea)"Viga 429: rate_limit_error"
# TUGEV (kasutajasõbralik, rahustav, tegevust soovitav) "Süsteemis tekkis ajutine ummik. Saime teie taotluse turvaliselt kätte ja seda proovitakse automaatselt uuesti. Kui tulemust mõne sekundi jooksul ei kuvata, saate lehte värskendada."
Toores tehnilise vea paljastamine lõppkasutajale õõnestab usaldust ja võib olla turvaauku. Kategoriseerige vead sisemiselt ja edastage kasutajale rahulik, tegevusele suunatud sõnum; lihtsalt kirjutage salvestuse tehniline detail.
Kolm miniümbrist
Juhtum 1 – paat kukkus liiklusplahvatuses. Klienditeenindusbot sai kampaaniapäeval liikluse suurenemise 429; Koodis uuesti proovimist ei olnud, iga viga kajastus otse kasutajale "veana". Nad lisasid eksponentsiaalse retracement + uuesti proovimise pärast; sama liiklusega, päringud edastati mitmesekundilise viivitusega, kasutaja ei näinud ühtegi viga.
Juhtum 2 – 400 proovimine. Integratsioon sai vale mudeli ID tõttu 404, kuid käsitles kõiki vigu "mööduvatena" ja proovis lõpmatus tsüklis uuesti; Palk läks paiste ja tekkis tarbetu koormus. Nad lisasid vigade klassifikatsiooni: 404 loetakse püsivaks, silmus peatatakse ja mudeli ID parandatakse. Õppetund: ära proovi iga viga uuesti.
Juhtum 3 – limiidi juhtimine eest. Andmete rikastamise töö töötas pidevalt 429 piirangu juures. Nad järgisid x-ratelimit-jäänud päist ja piirasid liiklust vastavalt kvoodile. Seega hoidsid nad ühtlast tempot veidi alla piiri, võtmata ühtegi 429 sekundit; Töö sai tehtud ettearvatavamalt ja kiiremini.
Levinud vead
- Kiiruse suurendamine 429-s: muudab olukorra hullemaks; Lülitu taganemisele.
- Iga vea uuesti proovimine: 400/401/404 on püsiv; Uuesti proovimine on raiskamine.
- Fikseeritud ootamise kasutamine: loob kokkupõrke; Kasutage eksponentsiaalset + värinat.
- Uuesti proovimise ignoreerimine: kõige täpsem on järgida teenusepakkuja määratud aega.
- Toorvea paljastamine kasutajale: raputab usaldust, tekitab turvaauke; Klassifitseerige sees.
- Piiramatu korduskatse: määrake ülempiir (nt 5 korduskatset); siis anna graatsiliselt alla.
Sügavam: järjekord, samaaegsus ja kaitselülitid
Üksiku soovi vastupidamine on esimene samm; Tõeline küpsus on hallata suurt hulka taotlusi ilma limiite ületamata. Siin tulevad mängu kolm kontseptsiooni.
Järjekord: paned päringud järjekorda, et saata need kontrollitud tempos, mitte kohe. Järjekord silub äkilised liikluspursked: isegi kui korraga saabub 1000 päringut, vabastab järjekord need kiirusega, mis jääb alla limiidi. Nii hoiate ära 429, siis ei pea te selle parandamise pärast muretsema.
Samaaegsuse limiit: piirate korraga õhus olevate taotluste arvu. Piiramatult paralleelsed päringud täidavad kiiresti RPM-i ja TPM-i piirangud. Mõistlik samaaegsuse ülemmäär (nt mitte rohkem kui 10 samaaegset päringut) säilitab piirangud ja muudab süsteemi prognoositavaks.
Kaitselüliti: kui teenusepakkuja tagastab pidevalt 500/529, siis selle asemel, et iga päringu kangekaelselt proovida, katkestate korraks vooluringi ja ebaõnnestute kiiresti, ilma seda kordagi saatmata. Pärast ootamist lülitate vooluringi uuesti sisse ja proovite. See muster takistab teie süsteemi kokkujooksmist ajutise teenusepakkuja tõrke korral.
Need kolm koos loovad süsteemitasemel vastupidavuse, mis ületab ühe kõne korduskatse loogika. Väikeses mahus piisab SDK automaatsest uuesti proovimisest; Kui mastaabi kasvab, muutuvad järjekorrad, samaaegsus ja kaitselüliti asendamatuks. Neil kõigil on sama ühine eesmärk: kajastada kasutajale ajutist probleemi mitte kui krahhi, vaid kui nähtamatut mõnesekundilist viivitust.
Kokkuvõttes
429 tagastab kiirusepiirangute (RPM/ITPM/OTPM) ületamise korral; See on ajutine viga ja seda proovitakse uuesti, kasutades korduskatset ja eksponentsiaalset taganemist + värinat. 500 ja 529 on samuti esialgsed; 400/401/403/404 on päringu/identiteedi probleem ja seda ei saa uuesti proovides lahendada. Tugev voog jaotab vead nendesse kahte rühma, proovib piiratud arv kordi, jälgib piirmäära eestpoolt ja näitab kasutajale rahulikke sõnumeid.
Rakenduse ülesanne
Mõelge oma integratsioonile. (1) Loetlege veakoodid, mis võivad ilmneda, ja eraldage need "uuesti proovitavateks / püsivateks". (2) Kirjutage üles oma eksponentsiaalne tagasitõmbeplaan (esialgne hoidmine, koefitsient, ülempiir, värina). (3) Määrake, kuidas kasutada päist uuesti proovige pärast. (4) Kirjutage viisakas sõnum, mis kuvatakse kasutajale, kui korduskatsed on ammendatud.
kontrollnimekiri
- [ ] Saan selgitada RPM/ITPM/OTPM piiranguid ja 429.
- [ ] Oskan rakendada eksponentsiaalse taganemise + värina + uuesti proovimise loogikat.
- [ ] Võin liigitada veakoodid uuesti proovitavateks/püsivateks.
- [ ] Ma tean, et me ei peaks iga viga proovima.
- [ ] Toorvea asemel saan näidata kasutajale rahulikku, tegevusele suunatud sõnumit.