Ieguvumi:
- Var interpretēt ātruma ierobežojumus (RPM/ITPM/OTPM) un 429 kļūdas
- Ievieš eksponenciālu atkāpšanos un atkārtotu mēģinājumu ar atkārtotu mēģinājumu pēc
- Pareizi klasificē un apstrādā izplatītos HTTP kļūdu kodus (400/401/429/500/529)
Ražošanas vidē neviena API nereaģē perfekti visu laiku. Dažreiz jūs sūtāt pieprasījumus pārāk ātri un sasniedzat ierobežojumu; dažreiz serveris ir īslaicīgi aizņemts; Dažreiz jūsu pieprasījums jau no paša sākuma ir nepareizs. Tas, kas atšķir stabilu integrāciju no amatieru mēģinājuma, ir tas, ka tā šīs situācijas risina paredzami un automātiski. Šajā nodaļā jūs uzzināsit par ātruma ierobežojumiem (RPM/ITPM/OTPM), 429 kļūdu, atkārtotu mēģinājumu ar eksponenciālu atkāpšanos un pareizu parasto HTTP kļūdu kodu klasifikāciju. Mērķis: izveidot plūsmu, kas ir tik spēcīga, ka lietotājs to nekad nepamanīs.
Kas ir ātruma ierobežojumi?
Pakalpojumu sniedzējs ierobežo, cik daudz darba slēdzis var veikt noteiktā laika periodā. Šī aizsardzība; Tas pasargā gan infrastruktūru, gan jūs no pēkšņiem izmaksu sprādzieniem. Pastāv trīs izplatīti ierobežojumu veidi:
- RPM (pieprasījumi minūtē): pieprasījumu skaits minūtē.
- ITPM (Input Tokens Per Minute): ievades marķieris, ko var apstrādāt minūtē.
- OTPM (Output Tokens Per Minute): izvades marķieris, ko var izgatavot minūtē.
Ja pārsniedzat kādu no šiem ierobežojumiem, pakalpojumu sniedzējs noraida pieprasījumu un atgriež kļūdas kodu 429. Ierobežojumi parasti atšķiras atkarībā no jūsu konta līmeņa (līmeņa), un laika gaitā tie var tikt palielināti.
Padoms. Atbilžu galvenēs varat skatīties, kad tuvojas ierobežojumam. Lielākā daļa pakalpojumu sniedzēju ziņo par jūsu atlikušo kvotu ar galvenēm, piemēram, x-ratelimit-remaining-*. Šo vērtību uzraudzība un priekšā esošās satiksmes regulēšana ir vispiemērotākais veids, kā novērst problēmu, neiegūstot 429.
429 un eksponenciālā izsekošana
429 (likmju ierobežojums) ir īslaicīga un atkārtoti izmēģināma kļūda. Pareizā atbilde ir kādu laiku gaidīt pieprasījumu un mēģināt vēlreiz. Bet ar pastāvīgu gaidīšanu nepietiek; Ja visi mēģinās vēlreiz vienlaikus, limits tiks sasniegts vēlreiz. Risinājums ir eksponenciāls atkāpšanās: eksponenciāli palielinot gaidīšanas laiku ar katru neveiksmīgu mēģinājumu.
# Eksponenciālās atkāpšanās loģikas izmēģinājums 1 → 429 → pagaidiet 1 sek. mēģinājums 2 → 429 → nogaidiet 2 sek. mēģinājums 3 → 429 → nogaidiet 4 sek. mēģinājums 4 → 429 → pagaidiet 8 s (+ neliela nejauša nervozitāte)... padodieties un ziņojiet pēc ne vairāk kā N mēģinājumiem
Nedaudz nejaušības (trīces) pievienošana novērš pieprasījumu sadursmi, mēģinot vienlaikus mēģināt vēlreiz. Turklāt 429 atbilde bieži satur galveni "retry-after": "mēģiniet vēlreiz pēc tik daudzām sekundēm". Respektēt šo titulu ir precīzāk nekā akli gaidīt.
Uzmanību! Kad saņemat 429, "piespiežot to, nosūtot vairāk pieprasījumu", situācija pasliktināsies; Limits joprojām tiek aizpildīts, un neviens pieprasījums netiek izpildīts. Pareizā atbilde ir atkāpšanās, nevis paātrinājums. Labas ziņas: lielākā daļa oficiālo SDK automātiski mēģina atkārtoti 429 un servera kļūdas ar atkāpšanos — izmantojiet šo SDK darbību pirms tā manuālas instalēšanas.
HTTP kļūdu kodu klasificēšana
Ne katra kļūda ir vienāda. Būtiska atšķirība: vai to var mēģināt vēlreiz, vai arī tā ir pieprasījuma/identitātes problēma?
Kods
Nozīme
Vai to var mēģināt vēlreiz?
pareiza atbilde
400
Nederīgs pieprasījums (formāta/parametra kļūda)
nē
Labojiet pieprasījumu; nesūti to pašu vēlreiz
401
Autentifikācijas kļūda (atslēga nederīga/trūkst)
nē
Labojiet atslēgu/nosaukumu
403
Nav autorizācijas (nav piekļuves modelim/funkcijai)
nē
Pārbaudiet atļaujas / darbības jomu
404
Nav atrasts (nepareizs modeļa ID/gala punkts)
nē
Pareizs modeļa ID/adrese
429
Pārsniegts ātruma ierobežojums
Jā
Atkāpšanās + atkārtots mēģinājums pēc
500
Servera kļūda
Jā
Mēģiniet vēlreiz ar atkāpšanos
529
Serveris ir pārslogots
Jā
Mēģiniet vēlreiz ar atkāpšanos
Zelta likums: 429, 500 un 529 ir īslaicīgi; Tas tiek mēģināts vēlreiz ar izņemšanu. 400, 401, 403, 404 ir pieprasījuma/identitātes problēmas; Mēģinot vēlreiz, tas netiks atrisināts, un tas liek tērēt pūles. Jūsu kodam ir jānošķir šīs divas grupas.
Soli pa solim: izturīgs zvans
- Iesniedziet pieprasījumu. Ja izdodas, turpiniet.
- Klasificējiet kļūdas kodu. Vai to var mēģināt vēlreiz?
- Ja var mēģināt: sekojiet atkārtošanai pēc, piemērojiet eksponenciālu atkāpšanos + nervozitāti, mēģiniet ierobežotu skaitu reižu (piemēram, ne vairāk kā 5).
- Ja nav mēģināts: Labot (formāts/atslēga) un apturēt; Neatkārtojiet to pašu kļūdaino pieprasījumu cilpā.
- Apsveriet iespēju atteikties. Ja pēc n mēģinājumiem joprojām neizdodas, parādiet lietotājam pieklājīgu ziņojumu un reģistrējiet notikumu (11. izsekošanas vienība).
# Stingrs izsaukums pseido-codedene = 0atkārtot: atbilde = pieprasījums_at(), ja atbilde.success: atgrieziet atbildi, ja atbildes.kods [429, 500, 529] un mēģiniet < 5: gaidiet = retry_after ?? (2^mēģināt sec + nervozēt) miegs (pagaidiet); mēģināt += 1; git vēlreiz, ja atbildes.kods [400, 401, 403, 404]: save_error(response); atgriezties "pieprasījums ir jālabo" return "pastāvīga kļūda, mēģiniet vēlāk"
# Pieklājīga atsauksme lietotājam (kad mēģinājumi ir beigušies) "Šobrīd esmu aizņemts, nevarēju apstrādāt jūsu pieprasījumu. Mēģiniet drīzumā vēlreiz vai arī esmu saglabājis jūsu pieprasījumu, es sazināsimies ar jums, kad tas būs gatavs."
Vāja uzvedne / spēcīga uzvedne (šeit: kļūdas ziņojuma dizains)
# WEAK (lietotājam parāda neapstrādātu kļūdu)"Kļūda 429: rate_limit_error"
# STRONG (lietotājam draudzīgs, nomierinošs, darbību ierosinošs) "Sistēmā bija īslaicīgs sastrēgums. Mēs esam droši saņēmuši jūsu pieprasījumu, un tas tiek automātiski mēģināts vēlreiz. Ja rezultāts neparādās dažu sekunžu laikā, varat atsvaidzināt lapu."
Neapstrādātas tehniskās kļūdas atklāšana gala lietotājam gan grauj uzticību, gan var būt drošības ievainojamība. Kategorējiet kļūdas iekšēji un sniedziet lietotājam mierīgu, uz darbību vērstu ziņojumu; vienkārši ierakstiet ieraksta tehnisko informāciju.
Trīs mini futrāļi
1. gadījums — satiksmes sprādzienā avarēja laiva. Klientu apkalpošanas robots kampaņas dienā saņēma 429 strauju trafiku; Kodā nebija atkārtota mēģinājuma, katra kļūda tika atspoguļota tieši lietotājam kā "kļūda". Viņi pievienoja eksponenciālo izsekošanu + atkārtotu mēģinājumu pēc; ar tādu pašu trafiku, pieprasījumi tika nodoti ar vairāku sekunžu kavēšanos, lietotājs neredzēja nekādas kļūdas.
2. gadījums — 400 izmēģināšana. Integrācija saņēma 404 nederīga modeļa ID dēļ, taču visas kļūdas uzskatīja par "pārejošām" un mēģināja vēlreiz bezgalīgā ciklā; Baļķis uzbriest un radās nevajadzīga slodze. Viņi pievienoja kļūdu klasifikāciju: 404 tiek uzskatīts par pastāvīgu, cilpa tiek apturēta un modeļa ID tiek labots. Mācība: nemēģini katru kļūdu vēlreiz.
3. gadījums — limita pārvaldība no priekšpuses. Datu bagātināšanas darbs nepārtraukti darbojās ar 429 ierobežojumu. Viņi sekoja x-ratelimit-remaining galvenei un ierobežoja trafiku atbilstoši kvotai. Tāpēc viņi turēja vienmērīgu tempu tieši zem robežas, nepaņemot nevienu 429s; Darbs tika paveikts paredzamāk un ātrāk.
Biežas kļūdas
- Ātruma palielināšana 429: pasliktina situāciju; Pārslēdzieties uz atkāpšanos.
- Katras kļūdas mēģinājums vēlreiz: 400/401/404 ir pastāvīga; Mēģināt vēlreiz ir veltīgi.
- Izmantojot fiksēto gaidīšanu: rada sadursmi; Izmantojiet eksponenciālu + nervozitāti.
- Ignorēšana “atkārtoti pēc”: visprecīzāk ir ievērot pakalpojumu sniedzēja norādīto laiku.
- Neapstrādātas kļūdas atklāšana lietotājam: satricina uzticību, rada ievainojamības; Klasificēt iekšā.
- Neierobežots mēģinājumu skaits: iestatiet augšējo ierobežojumu (piem., 5 atkārtojumi); tad graciozi padoties.
Deeper: rindas, vienlaicīgums un ķēdes pārtraucēji
Vienas vēlmes izturība ir pirmais solis; Īstais briedums ir pārvaldīt lielu skaitu pieprasījumu, nepārkāpjot ierobežojumus. Šeit spēlē trīs jēdzieni.
Rinda: jūs ievietojat pieprasījumus rindā, lai tos nosūtītu kontrolētā tempā, nevis nekavējoties. Rindas izveidošana izlīdzina pēkšņus datplūsmas uzliesmojumus: pat ja vienlaikus tiek saņemti 1000 pieprasījumu, rinda tos atbrīvos ar ātrumu, kas ir mazāks par ierobežojumu. Tādā veidā jūs novēršat 429, tad jums nav jāuztraucas par tā labošanu.
Vienlaicības ierobežojums: jūs ierobežojat, cik pieprasījumu vienlaikus ir "gaisā". Neierobežoti paralēli pieprasījumi ātri aizpilda RPM un TPM ierobežojumus. Saprātīgi vienlaicīguma griesti (piemēram, ne vairāk kā 10 vienlaicīgi pieprasījumi) gan uztur ierobežojumus, gan padara sistēmu paredzamu.
Strāvas slēdzis: ja pakalpojumu sniedzējs turpina atdot 500/529, tā vietā, lai neatlaidīgi mēģinātu katru pieprasījumu, jūs uz brīdi "pārraujat ķēdi" un ātri neizdodas izpildīt pieprasījumu, nekad to nenosūtot. Pēc gaidīšanas atkal ieslēdziet ķēdi un mēģiniet. Šis modelis neļauj jūsu sistēmai avarēt pagaidu pakalpojumu sniedzēja kļūmes gadījumā.
Kopā šie trīs nodrošina sistēmas līmeņa noturību, kas pārsniedz viena zvana atkārtošanas loģiku. Mazā mērogā pietiek ar SDK automātisko atkārtotu mēģinājumu; Pieaugot mērogam, rindas, vienlaicīgums un ķēdes pārtraucējs kļūst neaizstājams. Viņiem visiem ir viens kopīgs mērķis: lietotājam atspoguļot īslaicīgu problēmu nevis kā avāriju, bet gan kā neredzamu dažu sekunžu aizkavi.
Rezumējot
429 atgriežas, ja tiek pārsniegti ātruma ierobežojumi (RPM/ITPM/OTPM); Šī ir īslaicīga kļūda, un tā tiks mēģināta vēlreiz, izmantojot atkārtotu mēģinājumu pēc un eksponenciālu atkāpšanos + nervozitāti. 500 un 529 arī ir provizoriski; 400/401/403/404 ir pieprasījuma/identitātes problēma, un to nevar atrisināt, mēģinot vēlreiz. Izturīga plūsma sadala kļūdas šajās divās grupās, mēģina ierobežotu skaitu reižu, uzrauga ierobežojumu no priekšpuses un parāda lietotājam mierīgus ziņojumus.
Lietojumprogrammas uzdevums
Apsveriet savu integrāciju. (1) Uzskaitiet kļūdu kodus, ar kuriem jūs varat saskarties, un sadaliet tos “atkārtoti izmēģināmi/pastāvīgi”. (2) Pierakstiet savu eksponenciālo atvilkšanas plānu (sākotnējā noturēšana, koeficients, ierobežojums, nervozitāte). (3) Norādiet, kā izmantot galveni vēlreiz mēģināt. (4) Uzrakstiet pieklājīgo ziņojumu, kas tiks parādīts lietotājam, kad mēģinājumi ir beigušies.
kontrolsaraksts
- [ ] Es varu izskaidrot RPM/ITPM/OTPM ierobežojumus un 429.
- [ ] Es varu izmantot loģiku eksponenciāla atkāpšanās + nervozitāte + atkārtots mēģinājums pēc.
- [ ] Es varu klasificēt kļūdu kodus kā atkārtoti izmēģināmus/pastāvīgus.
- [ ] Es zinu, ka mums nevajadzētu izmēģināt katru kļūdu.
- [ ] Neapstrādātas kļūdas vietā es varu parādīt lietotājam mierīgu, uz darbību vērstu ziņojumu.