Fitimet:
- Mund të interpretojë kufijtë e shpejtësisë (RPM/ITPM/OTPM) dhe 429 gabime
- Zbaton prapambetje eksponenciale dhe riprovoni me riprovim-pas
- Klasifikon dhe trajton saktë kodet e zakonshme të gabimit HTTP (400/401/429/500/529)
Në një mjedis prodhimi, asnjë API nuk përgjigjet në mënyrë perfekte gjatë gjithë kohës. Ndonjëherë ju dërgoni kërkesa shumë shpejt dhe arrini kufirin; ndonjëherë serveri është përkohësisht i zënë; Ndonjëherë kërkesa juaj është e gabuar që në fillim. Ajo që e dallon një integrim solid nga një përpjekje amatore është se ai i trajton këto situata në mënyrë parashikuese dhe automatike. Në këtë njësi do të mësoni rreth kufijve të normës (RPM/ITPM/OTPM), gabimit 429, riprovoni me prapavijë eksponenciale dhe klasifikimin e duhur të kodeve të zakonshme të gabimit HTTP. Qëllimi: të ndërtohet një rrjedhë që është aq e fuqishme sa përdoruesi nuk do ta vërejë kurrë atë.
Cilat janë kufijtë e shpejtësisë?
Ofruesi kufizon sa punë mund të bëjë një ndërprerës në një periudhë të caktuar kohe. Kjo mbrojtje; Ai mbron si infrastrukturën ashtu edhe ju nga shpërthimet e papritura të kostos. Ekzistojnë tre lloje të zakonshme të kufijve:
- RPM (Kërkesa për minutë): Numri i kërkesave për minutë.
- ITPM (Input Tokens Per Minute): Shenja hyrëse që mund të përpunohet për minutë.
- OTPM (Output Tokens Per Minute): Shenja dalëse që mund të prodhohet për minutë.
Nëse tejkaloni ndonjë nga këto kufij, ofruesi e refuzon kërkesën dhe kthen një kod gabimi 429. Kufijtë në përgjithësi ndryshojnë në varësi të nivelit të llogarisë suaj (niveli) dhe mund të rriten me kalimin e kohës.
Këshillë: Mund të shikoni kur po i afroheni kufirit nga titujt e përgjigjeve. Shumica e ofruesve raportojnë kuotën tuaj të mbetur me tituj si x-ratelimit-remaining-*. Monitorimi i këtyre vlerave dhe frenimi i trafikut përpara është mënyra më e pjekur për të parandaluar problemin pa marrë një 429.
429 dhe Retracement eksponencial
429 (kufiri i normës) është një gabim i përkohshëm dhe i riprovueshëm. Përgjigja e saktë është të prisni për një kohë kërkesën dhe të provoni përsëri. Por një pritje e vazhdueshme nuk mjafton; Nëse të gjithë provojnë përsëri në të njëjtën kohë, kufiri do të arrihet përsëri. Zgjidhja është prapambetja eksponenciale: rritja e kohës së pritjes në mënyrë eksponenciale me çdo përpjekje të dështuar.
# Provë logjike e prapambetur eksponenciale 1 → 429 → prit 1 sekondë provë 2 → 429 → prit 2 sekondë provë 3 → 429 → prit 4 sekondë provë 4 → 429 → prit 8 sek (+ "jitter" e vogël e rastësishme)... hiq dorë dhe raporto pas maksimum 2 provash
Shtimi i një rastësie të vogël (ngacmues) në këtë parandalon përplasjen e kërkesave kur përpiqeni të riprovoni në të njëjtën kohë. Për më tepër, përgjigja 429 shpesh mbart një titull "riprovo-pas": "provo përsëri në kaq shumë sekonda". Të respektosh këtë titull është më i saktë se sa të presësh verbërisht.
Kujdes: Kur merrni një 429, "duke e detyruar duke dërguar më shumë kërkesa" do ta përkeqësojë situatën; Kufiri vazhdon të plotësohet dhe asnjë kërkesë nuk kalon. Përgjigja e saktë është tërheqja, jo nxitimi. Lajm i mirë: shumica e SDK-ve zyrtare riprovojnë automatikisht 429 dhe gabimet e serverit me një prapavijë — përdorni këtë sjellje të SDK-së përpara se ta instaloni manualisht.
Klasifikimi i kodeve të gabimit HTTP
Jo çdo gabim është i njëjtë. Dallimi kritik: a mund të rigjykohet apo është një çështje kërkese/identiteti?
Kodi
Kuptimi
A mund të provohet sërish?
përgjigje e saktë
400
Kërkesë e pavlefshme (gabim formati/parametri)
nr
Korrigjoni kërkesën; mos e dërgoni më të njëjtën gjë
401
Gabim vërtetimi (çelësi i pavlefshëm/mungon)
nr
Rregulloni çelësin/titullin
403
Nuk ka autorizim (pa qasje në model/funksion)
nr
Kontrolloni lejet/fushëveprimin
404
Nuk u gjet (ID/pika e pasaktë e modelit)
nr
ID/adresa e saktë e modelit
429
Kufiri i shpejtësisë u tejkalua
po
Tërheqje + riprovim-pas
500
Gabim serveri
po
Provo sërish me tërheqje
529
Serveri i mbingarkuar
po
Provo sërish me tërheqje
Rregulli i artë: 429, 500 dhe 529 janë të përkohshme; Provohet sërish me tërheqje. 400, 401, 403, 404 janë çështje kërkese/identiteti; Përpjekja përsëri nuk do ta zgjidhë atë dhe humb përpjekjet. Kodi juaj duhet të bëjë dallimin midis këtyre dy grupeve.
Hap pas hapi: Thirrje e qëndrueshme
- Paraqisni kërkesën. Nëse ka sukses, vazhdoni.
- Klasifikoni kodin e gabimit. A mund të provohet sërish?
- Nëse mund të provohet: ndiqni riprovën pas, aplikoni prapambetjen eksponenciale + nervozizëm, provoni një numër të kufizuar herë (p.sh. 5 maksimum).
- Nëse nuk provohet: Rregullo (format/çelës) dhe ndalo; Mos e përsëritni të njëjtën kërkesë të gabuar në lak.
- Konsideroni të hiqni dorë. Nëse ende nuk ka sukses pas n përpjekjesh, tregojini një mesazh të sjellshëm përdoruesit dhe regjistroni ngjarjen (njësia përcjellëse 11).
# Thirrje e fortë pseudo-kodeden = 0përsëritje: përgjigja = request_at() if answer.success: kthe përgjigjen nëse answer.code në [429, 500, 529] dhe provo < 5: pres = riprovo_pas ?? (2^provo sec + nervozizëm) fle (prit); provoni += 1; git përsëri nëse përgjigja.kodi në [400, 401, 403, 404]: save_error(response); kthe "kërkesa duhet rregulluar" kthe "gabim i përhershëm, provo më vonë"
# Reagime të sjellshme për përdoruesin (kur mbarojnë përpjekjet e përsëritura) "Jam i zënë për momentin, nuk mund ta përpunoja kërkesën tënde. Provo sërish së shpejti, ose e kam ruajtur kërkesën tënde, do të të kontaktoj kur të jetë gati."
Prompt i dobët / Prompt i fortë (këtu: dizajni i mesazhit të gabimit)
# I DOBËT (shfaq përdoruesin gabim të papërpunuar)"Gabimi 429: norma_limit_error"
# I FORTË (i përshtatshëm për përdoruesit, qetësues, sugjerues veprimi) "Kishte një bllokim të përkohshëm në sistem. Ne e kemi marrë kërkesën tuaj në mënyrë të sigurt dhe po provohet përsëri automatikisht. Nëse një rezultat nuk shfaqet brenda pak sekondash, mund ta rifreskoni faqen."
Zbulimi i gabimit teknik të papërpunuar tek përdoruesi fundor minon besimin dhe mund të jetë një cenueshmëri sigurie. Kategorizoni gabimet nga brenda dhe jepini përdoruesit një mesazh të qetë, të orientuar drejt veprimit; thjesht shkruani detajet teknike për regjistrim.
Tre Mini Rastet
Rasti 1 - Anija u përplas në një shpërthim trafiku. Një robot i shërbimit ndaj klientit mori 429 trafik në rritje në ditën e fushatës; Nuk kishte asnjë riprovim në kod, çdo gabim u pasqyrua drejtpërdrejt te përdoruesi si një "gabim". Ata shtuan kthimin eksponencial + riprovim-pas; me të njëjtin trafik, kërkesat kaluan me një vonesë prej disa sekondash, përdoruesi nuk pa asnjë gabim.
Rasti 2 - Provoni 400 në lak. Një integrim po merrte një 404 për shkak të një ID-je të pavlefshme të modelit, por po i trajtonte të gjitha gabimet si "kalimtare" dhe po provonte përsëri në një lak të pafund; Regjistri u fry dhe u krijua ngarkesa e panevojshme. Ata shtuan klasifikimin e gabimeve: 404 konsiderohet i përhershëm, cikli është ndalur dhe ID-ja e modelit korrigjohet. Mësimi: mos e provo përsëri çdo gabim.
Rasti 3 - Menaxhimi i kufirit nga përpara. Një punë për pasurimin e të dhënave po funksiononte vazhdimisht në kufirin 429. Ata ndoqën kokën e mbetur x-ratelimit dhe frenuan trafikun sipas kuotës. Kështu ata mbajtën një ritëm të qëndrueshëm pak më poshtë kufirit, pa marrë asnjë 429s; Puna u krye më e parashikueshme dhe më shpejt.
Gabimet e zakonshme
- Rritja e shpejtësisë në 429: Përkeqëson situatën; Kalo në tërheqje.
- Riprovimi i çdo gabimi: 400/401/404 është i përhershëm; Të provosh sërish është humbje.
- Përdorimi i pritjes fikse: Krijon një përplasje; Përdorni eksponencial + nervozizëm.
- Injorimi i "riprovimit pas": Është më e sakta të respektohet koha e specifikuar nga ofruesi.
- Zbulimi i gabimit të papërpunuar te përdoruesi: Shkund besimin, krijon dobësi; Klasifikoni brenda.
- Përsëritjet e pakufizuara: Vendosni një kufi të sipërm (p.sh. 5 riprovime); pastaj hiqni dorë me hijeshi.
Më të thella: Ndërprerësit e radhës, konkurencës dhe qarkut
Durimi i një dëshire të vetme është hapi i parë; Pjekuria e vërtetë është të menaxhosh një numër të madh kërkesash pa arritur kufijtë. Këtu hyjnë në lojë tre koncepte.
Radha: Ju vendosni kërkesat në një radhë për t'i dërguar ato me një ritëm të kontrolluar dhe jo menjëherë. Radha zbut shpërthimet e papritura të trafikut: Edhe nëse mbërrijnë 1000 kërkesa menjëherë, radha do t'i lëshojë ato me një normë nën kufirin. Në këtë mënyrë ju parandaloni 429, atëherë nuk keni pse të shqetësoheni për rregullimin e tij.
Kufiri i konkurencës: Ju kufizoni sa kërkesa janë "në ajër" në të njëjtën kohë. Kërkesat e pakufizuara paralele mbushin shpejt kufijtë e RPM dhe TPM. Një tavan i arsyeshëm përputhshmërie (p.sh. jo më shumë se 10 kërkesa të njëkohshme) ruan kufijtë dhe e bën sistemin të parashikueshëm.
Ndërprerësi: Nëse ofruesi vazhdon të kthejë 500/529, në vend që të provoni me këmbëngulje çdo kërkesë, ju "prisni qarkun" për një kohë dhe shpejt e dështoni kërkesën pa e dërguar kurrë. Pas një pritjeje, ndizni përsëri qarkun dhe provoni. Ky model parandalon që sistemi juaj të rrëzohet në rast të një dështimi të përkohshëm të ofruesit.
Së bashku, këto të treja krijojnë elasticitet në nivel sistemi përtej logjikës së riprovës së një telefonate të vetme. Në një shkallë të vogël, përsëritja automatike e SDK-së është e mjaftueshme; Ndërsa shkalla rritet, radhët, konkurenca dhe ndërprerësi bëhen të domosdoshëm. Të gjithë kanë të njëjtin qëllim të përbashkët: të pasqyrojnë një problem të përkohshëm tek përdoruesi jo si një përplasje, por si një vonesë e padukshme prej disa sekondash.
Në përmbledhje
429 kthehet kur kufijtë e shpejtësisë (RPM/ITPM/OTPM) janë tejkaluar; Ky është një gabim i përkohshëm dhe do të riprovohet duke përdorur riprovën pas dhe prapambetjen eksponenciale + nervozizëm. 500 dhe 529 janë gjithashtu të përkohshme; 400/401/403/404 është një çështje kërkese/identiteti dhe nuk mund të zgjidhet duke u përpjekur përsëri. Një rrjedhë e fuqishme ndan gabimet në këto dy grupe, provon një numër të kufizuar herë, monitoron kufirin nga përpara dhe i tregon përdoruesit mesazhe të qeta.
Detyra e aplikimit
Merrni parasysh integrimin tuaj. (1) Rendisni kodet e gabimit që mund të hasni dhe ndajini ato në "të riprovueshme / të përhershme". (2) Shkruani planin tuaj të tërheqjes eksponenciale (mbajtjen fillestare, koeficientin, kapak, nervozizëm). (3) Specifikoni se si të përdorni titullin e riprovës pas. (4) Shkruani mesazhin e sjellshëm që do t'i shfaqet përdoruesit kur të mbarojnë përpjekjet e përsëritura.
listë kontrolli
- [ ] Mund të shpjegoj kufijtë e RPM/ITPM/OTPM dhe 429.
- [ ] Unë mund të aplikoj logjikën e tërheqjes eksponenciale + nervozizëm + riprovim-pas.
- [ ] Unë mund t'i klasifikoj kodet e gabimit si të riprovueshëm/të përhershëm.
- [ ] E di që nuk duhet të provojmë çdo gabim.
- [ ] Në vend të një gabimi të papërpunuar, unë mund t'i tregoj përdoruesit një mesazh të qetë dhe të orientuar drejt veprimit.