Mga Limitasyon sa Bilis at Nababanat na Pamamahala ng Error

Mga nadagdag:

• Maaaring bigyang-kahulugan ang mga limitasyon ng bilis (RPM/ITPM/OTPM) at 429 na mga error
• Nagpapatupad ng exponential backoff at retry na may retry-after
• Tamang inuri at pinangangasiwaan ang mga karaniwang HTTP error code (400/401/429/500/529)

Sa isang kapaligiran ng produksyon, walang API na perpektong tumutugon sa lahat ng oras. Minsan nagpapadala ka ng mga kahilingan nang masyadong mabilis at naabot ang limitasyon; minsan ang server ay pansamantalang abala; Minsan mali ang hiling mo sa simula. Ang pinagkaiba ng solidong pagsasama sa isang baguhan na pagtatangka ay ang paghawak nito sa mga sitwasyong ito nang predictively at awtomatiko. Sa unit na ito matututunan mo ang tungkol sa mga limitasyon sa rate (RPM/ITPM/OTPM), 429 error, subukang muli nang may exponential backoff, at tamang pag-uuri ng mga karaniwang HTTP error code. Ang layunin: upang bumuo ng isang daloy na napakatatag na hindi ito mapapansin ng isang user.

Ano ang mga Speed ​​Limit?

Nililimitahan ng provider kung gaano karaming trabaho ang magagawa ng switch sa isang partikular na yugto ng panahon. Ang proteksyon na ito; Pinoprotektahan nito pareho ang imprastraktura at ikaw mula sa biglaang pagsabog ng gastos. May tatlong karaniwang uri ng mga limitasyon:

• RPM (Requests Per Minute): Bilang ng mga kahilingan kada minuto.
• ITPM (Input Token Per Minute): Input token na maaaring iproseso kada minuto.
• OTPM (Output Token Per Minute): Output token na maaaring gawin kada minuto.

Kung lalampas ka sa alinman sa mga limitasyong ito, tatanggihan ng provider ang kahilingan at magbabalik ng 429 error code. Karaniwang nag-iiba-iba ang mga limitasyon depende sa antas ng iyong account (tier) at maaaring tumaas sa paglipas ng panahon.

Tip: Maaari kang manood kapag lumalapit ka na sa limitasyon mula sa mga header ng tugon. Iniuulat ng karamihan sa mga provider ang iyong natitirang quota na may mga header tulad ng x-ratelimit-remaining-*. Ang pagsubaybay sa mga halagang ito at i-throttle ang trapiko sa harap ay ang pinaka-matandang paraan upang maiwasan ang problema nang hindi nakakakuha ng 429.

429 at Exponential Retracement

Ang 429 (limit sa rate) ay isang pansamantalang at maaaring muling subukang error. Ang tamang tugon ay maghintay ng ilang sandali sa kahilingan at subukang muli. Ngunit ang patuloy na paghihintay ay hindi sapat; Kung susubukan muli ng lahat sa parehong oras, maaabot muli ang limitasyon. Ang solusyon ay exponential backoff: pagpapalaki ng oras ng paghihintay sa bawat nabigong pagtatangka.

# Exponential backoff logic trial 1 → 429 → wait 1 sec trial 2 → 429 → wait 2 sec trial 3 → 429 → wait 4 sec trial 4 → 429 → wait 8 sec (+ small random "jitter")... sumuko at mag-ulat pagkatapos ng karamihan sa N trials

Ang pagdaragdag ng kaunting randomness (jitter) dito ay pumipigil sa mga kahilingan na magkabangga kapag sinusubukang muling subukan sa parehong oras. Bukod pa rito, ang 429 na tugon ay kadalasang may `retry-after` na header: "subukang muli sa loob ng maraming segundong ito." Ang paggalang sa pamagat na ito ay mas tumpak kaysa bulag na paghihintay.

Pag-iingat: Kapag nakakuha ka ng 429, "pagpipilitan ito sa pamamagitan ng pagpapadala ng higit pang mga kahilingan" ay magpapalala sa sitwasyon; Ang limitasyon ay patuloy na pinupunan at walang mga kahilingan na dumaan. Ang tamang tugon ay retreat, hindi acceleration. Magandang balita: karamihan sa mga opisyal na SDK ay awtomatikong muling sumusubok sa 429 at mga error sa server na may backoff — gamitin ang gawi na ito ng SDK bago ito manu-manong i-install.

Pag-uuri ng HTTP Error Codes

Hindi lahat ng pagkakamali ay pare-pareho. Kritikal na pagkakaiba: maaari ba itong muling subukan o ito ba ay isang kahilingan/isyu sa pagkakakilanlan?

Code

Ibig sabihin

Maaari ba itong subukan muli?

tamang tugon

400

Di-wastong kahilingan (error sa format/parameter)

hindi

Itama ang kahilingan; huwag nang magpadala muli

401

Error sa pagpapatunay (hindi wasto/nawawala ang key)

hindi

Ayusin ang susi/pamagat

403

Walang pahintulot (walang access sa modelo/tampok)

hindi

Suriin ang mga pahintulot/saklaw

404

Hindi Natagpuan (maling ID/endpoint ng modelo)

hindi

Tamang ID/address ng modelo

429

Lumampas sa limitasyon ng bilis

Oo

Retreat + retry-after

500

Error sa server

Oo

Subukang muli gamit ang retreat

529

Overloaded ang server

Oo

Subukang muli gamit ang retreat

Golden rule: 429, 500 at 529 ay pansamantala; Sinubukan itong muli sa withdrawal. 400, 401, 403, 404 ay mga isyu sa kahilingan/pagkakakilanlan; Ang pagsubok na muli ay hindi malulutas ito, at ito ay nag-aaksaya ng pagsisikap. Ang iyong code ay dapat na makilala sa pagitan ng dalawang pangkat na ito.

Hakbang sa Hakbang: Matibay na Tawag

1. Isumite ang kahilingan. Kung matagumpay, magpatuloy.
2. Uriin ang error code. Maaari ba itong subukan muli?
3. Kung masusubukan: sundin ang retry-after, ilapat ang exponential backoff + jitter, subukan ang limitadong bilang ng beses (hal. 5 max).
4. Kung hindi sinubukan: Ayusin (format/key) at ihinto; Huwag ulitin ang parehong maling kahilingan sa loop.
5. Isaalang-alang ang pagsuko. Kung hindi pa rin matagumpay pagkatapos ng n pagtatangka, magpakita ng magalang na mensahe sa user at i-log ang kaganapan (tracking unit 11).

# Matatag na tawag na pseudo-codedene = 0repeat: response = request_at() if response.success: return response if response.code sa [429, 500, 529] at subukan < 5: wait = retry_after ?? (2^try sec + jitter) sleep(wait); subukan ang += 1; git muli kung response.code sa [400, 401, 403, 404]: save_error(response); ibalik "dapat ayusin ang kahilingan" ibalik ang "permanenteng error, subukan mamaya"

# Magalang na feedback sa user (kapag naubos na ang mga muling pagsubok) "Abala ako ngayon, hindi ko maproseso ang iyong kahilingan. Subukang muli sa lalong madaling panahon, o na-save ko na ang iyong kahilingan, babalikan kita kapag handa na ito."

Mahinang prompt / Malakas na prompt (dito: disenyo ng mensahe ng error)

# WEAK (nagpapakita ng hilaw na error sa user)"Error 429: rate_limit_error"

# STRONG (user-friendly, reassuring, action-suggesting) "Nagkaroon ng pansamantalang pagsisikip sa system. Natanggap namin nang ligtas ang iyong kahilingan at awtomatiko itong sinusubok muli. Kung ang isang resulta ay hindi lumabas sa loob ng ilang segundo, maaari mong i-refresh ang pahina."

Ang pagsisiwalat ng hilaw na teknikal na error sa end user ay parehong nagpapahina sa tiwala at maaaring maging isang kahinaan sa seguridad. I-categorize ang mga error sa loob at bigyan ang user ng isang mahinahon, aksyon-oriented na mensahe; isulat lamang ang teknikal na detalye para sa talaan.

Tatlong Mini Case

Kaso 1 — Bangka ay bumagsak sa pagsabog ng trapiko. Nakatanggap ang isang customer service bot ng 429 sa surge traffic sa araw ng campaign; Walang muling pagsubok sa code, ang bawat error ay direktang ipinapakita sa user bilang isang "error". Nagdagdag sila ng exponential retracement + retry-after; na may parehong trapiko, lumipas ang mga kahilingan nang may pagkaantala ng ilang segundo, walang nakitang mga error ang user.

Case 2 — Sinusubukan ang 400 sa loop. Ang isang pagsasama ay nakakakuha ng 404 dahil sa isang di-wastong ID ng modelo, ngunit tinatrato ang lahat ng mga error bilang "lumilipas" at sinusubukang muli sa isang walang katapusan na loop; Ang log ay namamaga at ang hindi kinakailangang pagkarga ay nalikha. Nagdagdag sila ng pag-uuri ng error: 404 ay itinuturing na permanente, ang loop ay itinigil at ang modelong ID ay naitama. Aral: huwag mo nang ulitin ang bawat pagkakamali.

Case 3 — Pamamahala ng limitasyon mula sa harap. Ang isang data enrichment job ay patuloy na tumatakbo sa 429 na limitasyon. Sinundan nila ang x-ratelimit-remaining header at pina-throttle ang trapiko ayon sa quota. Kaya't pinananatili nila ang isang matatag na bilis sa ibaba lamang ng limitasyon, nang hindi kumukuha ng anumang 429s; Ang trabaho ay ginawa nang mas predictably at mas mabilis.

Mga karaniwang pagkakamali

• Pagtaas ng bilis sa 429: Pinapalala ang sitwasyon; Lumipat sa retreat.
• Sinusubukang muli ang bawat error: 400/401/404 ay permanente; Ang pagsubok muli ay isang pag-aaksaya.
• Paggamit ng nakapirming paghihintay: Lumilikha ng banggaan; Gumamit ng exponential + jitter.
• Hindi pinapansin ang 'retry-after': Ito ay pinakatumpak na sumunod sa oras na tinukoy ng provider.
• Pagbubunyag ng hilaw na error sa user: Naiinis ang tiwala, lumilikha ng mga kahinaan; Uriin sa loob.
• Walang limitasyong muling pagsubok: Magtakda ng pinakamataas na limitasyon (hal. 5 muling pagsubok); pagkatapos ay sumuko nang maganda.

Mas Malalim: Pagpila, Concurrency, at Mga Circuit Breaker

Ang pagtitiis ng isang pagnanais ay ang unang hakbang; Ang tunay na kapanahunan ay upang pamahalaan ang isang malaking bilang ng mga kahilingan nang hindi naabot ang mga limitasyon. Tatlong konsepto ang pumapasok dito.

Queue: Inilalagay mo ang mga kahilingan sa isang queue upang ipadala ang mga ito sa isang kontroladong bilis sa halip na kaagad. Pinapabilis ng pagpila ang mga biglaang pagsabog ng trapiko: Kahit na dumating ang 1,000 kahilingan nang sabay-sabay, ilalabas ng pila ang mga ito sa rate na mas mababa sa limitasyon. Sa ganitong paraan mapipigilan mo ang 429, pagkatapos ay hindi mo kailangang mag-alala tungkol sa pag-aayos nito.

Concurrency limit: Nililimitahan mo kung gaano karaming mga kahilingan ang "nasa hangin" sa parehong oras. Mabilis na pinupunan ng mga walang limitasyong parallel na kahilingan ang mga limitasyon ng RPM at TPM. Ang isang makatwirang concurrency ceiling (hal. hindi hihigit sa 10 sabay na kahilingan) ay parehong nagpapanatili ng mga limitasyon at ginagawang predictable ang system.

Circuit breaker: Kung patuloy na ibinabalik ng provider ang 500/529, sa halip na maingat na subukan ang bawat kahilingan, "masira mo ang circuit" nang ilang sandali at mabilis na nabigo ang kahilingan nang hindi ito ipinapadala. Pagkatapos ng paghihintay, i-on mo muli ang circuit at subukan. Pinipigilan ng pattern na ito ang iyong system mula sa pag-crash sa kaganapan ng isang pansamantalang pagkabigo ng provider.

Magkasama, ang tatlong ito ay nagtatatag ng katatagan sa antas ng system na higit sa retry logic ng isang tawag. Sa maliit na sukat, sapat na ang awtomatikong muling pagsubok ng SDK; Habang lumalaki ang sukat, ang pagpila, pagkakatugma, at circuit breaker ay nagiging kailangang-kailangan. Lahat sila ay may parehong karaniwang layunin: upang ipakita ang isang pansamantalang problema sa user hindi bilang isang pag-crash, ngunit bilang isang hindi nakikitang pagkaantala ng ilang segundo.

Sa buod

429 ay bumabalik kapag ang mga limitasyon ng bilis (RPM/ITPM/OTPM) ay lumampas; Ito ay pansamantalang error at susubukang muli gamit ang retry-after at exponential backoff + jitter. Ang 500 at 529 ay pansamantala rin; Ang 400/401/403/404 ay isang kahilingan/isyu sa pagkakakilanlan at hindi malulutas sa pamamagitan ng pagsubok muli. Ang isang matatag na daloy ay naghihiwalay ng mga error sa dalawang pangkat na ito, sumusubok ng limitadong bilang ng beses, sinusubaybayan ang limitasyon mula sa harapan at nagpapakita ng mga mahinahong mensahe sa user.

Gawain ng aplikasyon

Isaalang-alang ang iyong pagsasama. (1) Ilista ang mga error code na maaari mong makaharap at paghiwalayin ang mga ito sa "retryable / permanent". (2) Isulat ang iyong exponential pullback plan (initial hold, coefficient, cap, jitter). (3) Tukuyin kung paano gamitin ang retry-after header. (4) Isulat ang magalang na mensahe na ipapakita sa gumagamit kapag naubos na ang mga muling pagsubok.

checklist

• [ ] Maaari kong ipaliwanag ang mga limitasyon ng RPM/ITPM/OTPM at 429.
• [ ] Maaari kong ilapat ang lohika ng exponential retreat + jitter + retry-after.
• [ ] Maaari kong i-classify ang mga error code bilang retryable/permanent.
• [ ] Alam kong hindi natin dapat subukan ang bawat pagkakamali.
• [ ] Sa halip na isang hilaw na error, maaari kong ipakita sa user ang isang kalmado, aksyon-oriented na mensahe.