zisky:
- Dokáže interpretovať rýchlostné limity (RPM/ITPM/OTPM) a chyby 429
- Implementuje exponenciálne stiahnutie a opakovanie s retry-after
- Správne klasifikuje a spracováva bežné chybové kódy HTTP (400/401/429/500/529)
V produkčnom prostredí žiadne API nereaguje neustále dokonale. Niekedy posielate žiadosti príliš rýchlo a narazíte na limit; niekedy je server dočasne zaneprázdnený; Niekedy je vaša požiadavka od začiatku nesprávna. To, čo odlišuje solídnu integráciu od amatérskeho pokusu, je, že tieto situácie rieši prediktívne a automaticky. V tejto časti sa dozviete o limitoch rýchlosti (RPM/ITPM/OTPM), chybe 429, opakovanom pokuse s exponenciálnym stiahnutím a správnej klasifikácii bežných kódov chýb HTTP. Cieľ: vytvoriť tok, ktorý je taký robustný, že si ho používateľ nikdy nevšimne.
Čo sú to rýchlostné limity?
Poskytovateľ obmedzuje, koľko práce môže prepínač vykonať v danom časovom období. Táto ochrana; Chráni infraštruktúru aj vás pred náhlymi explóziami nákladov. Existujú tri bežné typy limitov:
- RPM (požiadavky za minútu): Počet žiadostí za minútu.
- ITPM (Input Tokens Per Minute): Vstupný token, ktorý je možné spracovať za minútu.
- OTPM (Output Tokens Per Minute): Výstupný token, ktorý je možné vyrobiť za minútu.
Ak prekročíte ktorýkoľvek z týchto limitov, poskytovateľ zamietne požiadavku a vráti chybový kód 429. Limity sa vo všeobecnosti líšia v závislosti od úrovne vášho účtu (úrovne) a môžu sa časom zvyšovať.
Tip: V hlavičkách odpovedí môžete sledovať, kedy sa blížite k limitu. Väčšina poskytovateľov uvádza vašu zostávajúcu kvótu s hlavičkami ako x-ratelimit-remaining-*. Monitorovanie týchto hodnôt a priškrtenie premávky vpredu je najvyspelejší spôsob, ako zabrániť problému bez toho, aby ste dostali 429.
429 a exponenciálny retracement
429 (limit sadzby) je dočasná a opakovateľná chyba. Správna odpoveď je chvíľu počkať na požiadavku a skúsiť to znova. Ale neustále čakanie nestačí; Ak sa všetci pokúsia znova v rovnakom čase, limit sa znova dosiahne. Riešením je exponenciálny ústup: exponenciálne zvýšenie čakacej doby s každým neúspešným pokusom.
# Skúška s exponenciálnou logikou backoff 1 → 429 → počkaj 1 s pokus 2 → 429 → počkaj 2 s pokus 3 → 429 → počkaj 4 s pokus 4 → 429 → počkaj 8 s (+ malé náhodné „chvenie“)... vzdaj sa a nahlás sa po najviac N pokusoch
Pridaním malej náhodnosti (jitter) k tomu zabráni kolíziám požiadaviek pri pokuse o zopakovanie v rovnakom čase. Okrem toho odpoveď 429 často obsahuje hlavičku `retry-after`: „skúste to znova o toľko sekúnd“. Rešpektovať tento titul je presnejšie ako slepé čakanie.
Pozor: Keď dostanete 429, "vynútenie odoslaním ďalších požiadaviek" situáciu zhorší; Limit sa naďalej plní a neprechádzajú žiadne žiadosti. Správna reakcia je ústup, nie zrýchlenie. Dobrá správa: väčšina oficiálnych súprav SDK automaticky zopakuje 429 a chyby servera so stiahnutím – použite toto správanie súpravy SDK pred jej manuálnou inštaláciou.
Klasifikácia chybových kódov HTTP
Nie každá chyba je rovnaká. Kritický rozdiel: možno to skúsiť znova alebo ide o problém so žiadosťou/totožnosťou?
kód
Význam
Dá sa to skúsiť znova?
správna odpoveď
400
Neplatná požiadavka (chyba formátu/parametra)
č
Opravte žiadosť; neposielajte znova to isté
401
Chyba overenia (kľúč je neplatný/chýba)
č
Opravte kľúč/názov
403
Žiadna autorizácia (žiadny prístup k modelu/funkcii)
č
Skontrolujte povolenia/rozsah
404
Nenájdené (nesprávne ID modelu/koncový bod)
č
Správne ID/adresa modelu
429
Prekročená rýchlosť
áno
Ústup + opakovanie po
500
Chyba servera
áno
Skúste to znova s ústupom
529
Server je preťažený
áno
Skúste to znova s ústupom
Zlaté pravidlo: 429, 500 a 529 sú dočasné; Skúša sa to znova s odvolaním. 400, 401, 403, 404 sú otázky týkajúce sa žiadosti/identity; Opätovným pokusom sa to nevyrieši a je to zbytočné úsilie. Váš kód musí rozlišovať medzi týmito dvoma skupinami.
Krok za krokom: Trvanlivý hovor
- Odošlite žiadosť. Ak je to úspešné, pokračujte.
- Klasifikujte kód chyby. Dá sa to skúsiť znova?
- Ak je to možné: opakujte pokus-potom, použite exponenciálny ústup + jitter, skúste obmedzený počet opakovaní (napr. maximálne 5).
- Ak sa nepokúsite: Opravte (formát/kľúč) a zastavte; Neopakujte tú istú chybnú požiadavku v slučke.
- Zvážte, že sa vzdáte. Ak sa to nepodarí ani po n pokusoch, ukážte používateľovi zdvorilú správu a zapíšte udalosť (sledovacia jednotka 11).
# Robustné volanie pseudo-codedene = 0repeat: response = request_at() if response.success: return response if response.code in [429, 500, 529] a skúste < 5: wait = retry_after ?? (2^skús sek + chvenie) spánok (čakať); skúste += 1; git znova if response.code v [400, 401, 403, 404]: save_error(response); return "žiadosť musí byť opravená" return "trvalá chyba, skúste neskôr"
# Zdvorilá spätná väzba pre používateľa (keď sú opakované pokusy vyčerpané) „Momentálne som zaneprázdnený, nemôžem spracovať vašu žiadosť. Skúste to znova čoskoro, alebo som vašu žiadosť uložil, ozvem sa vám, keď bude pripravená.“
Slabá výzva / silná výzva (tu: návrh chybového hlásenia)
# SLABÝ (používateľovi zobrazí nespracovanú chybu)"Chyba 429: rate_limit_error"
# SILNÝ (užívateľsky príjemný, upokojujúci, navrhujúci akciu) "V systéme došlo k dočasnému preťaženiu. Vašu požiadavku sme bezpečne prijali a automaticky sa skúša znova. Ak sa výsledok neobjaví do niekoľkých sekúnd, môžete stránku obnoviť."
Odhalenie surovej technickej chyby koncovému používateľovi podkopáva dôveru a môže predstavovať bezpečnostnú chybu. Interne kategorizovať chyby a poskytnúť používateľovi pokojnú správu zameranú na akciu; len napíšte technické detaily pre záznam.
Tri mini puzdrá
Prípad 1 – Loď havarovala pri dopravnej explózii. Robot služieb zákazníkom v deň kampane zaznamenal nárast návštevnosti o 429; V kóde nebolo žiadne opakovanie, každá chyba sa prejavila priamo užívateľovi ako „chyba“. Pridali exponenciálny retracement + retry-after; pri rovnakej návštevnosti, požiadavky prešli s niekoľkosekundovým oneskorením, používateľ nevidel žiadne chyby.
Prípad 2 – vyskúšanie 400 v slučke. Integrácia dostávala 404 kvôli neplatnému ID modelu, ale všetky chyby považovala za „prechodné“ a skúšala to znova v nekonečnej slučke; Poleno napuchlo a vznikla zbytočná záťaž. Pridali klasifikáciu chýb: 404 sa považuje za trvalé, slučka sa zastaví a ID modelu sa opraví. Ponaučenie: neskúšaj každú chybu znova.
Prípad 3 – Riadenie limitu spredu. Úloha obohatenia údajov neustále bežala na limite 429. Sledovali hlavičku x-ratelimit-remaining a obmedzili návštevnosť podľa kvóty. Udržali si teda stabilné tempo tesne pod limitom, pričom nezaberali žiadne 429; Práca bola vykonaná predvídateľnejšie a rýchlejšie.
Časté chyby
- Zvýšenie rýchlosti v 429: Zhoršuje situáciu; Prepnúť na ústup.
- Opakovanie každej chyby: 400/401/404 je trvalé; Skúšať to znova je plytvanie.
- Použitie pevného čakania: Vytvorí kolíziu; Použite exponenciálne + jitter.
- Ignorovanie „opakovania po“: Najpresnejšie je dodržať čas určený poskytovateľom.
- Odhalenie surovej chyby používateľovi: Otriasa dôverou, vytvára zraniteľné miesta; Zatriediť dovnútra.
- Neobmedzený počet opakovaní: Nastavte horný limit (napr. 5 opakovaní); potom sa slušne vzdať.
Hlbšie: radenie, súbežnosť a ističe
Vydržanie jedinej túžby je prvým krokom; Skutočnou zrelosťou je zvládnuť veľké množstvo požiadaviek bez toho, aby ste narazili na limity. Do hry tu vstupujú tri koncepty.
Fronta: Žiadosti zaraďujete do frontu, aby ste ich odosielali kontrolovaným tempom, nie okamžite. Zaraďovanie do frontu vyhladzuje náhle návaly prevádzky: Aj keď naraz príde 1 000 požiadaviek, rad ich uvoľní rýchlosťou pod limitom. Týmto spôsobom predídete 429, potom sa nemusíte starať o jeho opravu.
Limit súbežnosti: Obmedzíte, koľko žiadostí je súčasne „vo vzduchu“. Neobmedzené paralelné požiadavky rýchlo naplnia limity RPM a TPM. Rozumný strop súbežnosti (napr. nie viac ako 10 súbežných požiadaviek) zachováva limity a robí systém predvídateľným.
Istič: Ak poskytovateľ neustále vracia 500/529, namiesto toho, aby ste tvrdohlavo skúšali každú požiadavku, na chvíľu „prerušíte obvod“ a žiadosť rýchlo zlyháte bez toho, aby ste ju vôbec odoslali. Po čakaní znova zapnite okruh a vyskúšajte. Tento vzor zabraňuje zlyhaniu vášho systému v prípade dočasného zlyhania poskytovateľa.
Tieto tri spoločne vytvárajú odolnosť na systémovej úrovni nad rámec logiky opakovania jediného volania. V malom rozsahu postačuje automatický opakovaný pokus súpravy SDK; Ako sa rozsah zväčšuje, radenie, súbežnosť a istič sa stávajú nepostrádateľnými. Všetky majú rovnaký spoločný cieľ: zobraziť dočasný problém používateľovi nie ako zlyhanie, ale ako neviditeľné oneskorenie niekoľkých sekúnd.
V súhrne
429 sa vráti pri prekročení rýchlostných limitov (RPM/ITPM/OTPM); Ide o dočasnú chybu, ktorá sa zopakuje pomocou opakovaného pokusu a exponenciálneho stiahnutia + jitter. 500 a 529 sú tiež provizórne; 400/401/403/404 je problém so žiadosťou/totožnosťou a nedá sa vyriešiť opätovným pokusom. Robustný tok rozdeľuje chyby do týchto dvoch skupín, skúša obmedzený počet krát, monitoruje limit spredu a zobrazuje používateľovi pokojné správy.
Aplikačná úloha
Zvážte svoju integráciu. (1) Uveďte chybové kódy, s ktorými sa môžete stretnúť, a rozdeľte ich na „opakovateľné / trvalé“. (2) Zapíšte si svoj exponenciálny plán stiahnutia (počiatočné zadržanie, koeficient, strop, jitter). (3) Zadajte, ako sa má použiť hlavička opakovania. (4) Napíšte zdvorilú správu, ktorá sa zobrazí používateľovi po vyčerpaní pokusov.
kontrolný zoznam
- [ ] Viem vysvetliť limity RPM/ITPM/OTPM a 429.
- [ ] Môžem použiť logiku exponenciálneho ústupu + chvenia + opakovania.
- [ ] Chybové kódy môžem klasifikovať ako opakovateľné/trvalé.
- [ ] Viem, že by sme nemali skúšať každú chybu.
- [ ] Namiesto surovej chyby môžem používateľovi ukázať pokojnú správu zameranú na akciu.