zisky:
- Dokáže interpretovat rychlostní limity (RPM/ITPM/OTPM) a chyby 429
- Implementuje exponenciální stažení a opakování s retry-after
- Správně klasifikuje a zpracovává běžné chybové kódy HTTP (400/401/429/500/529)
V produkčním prostředí žádné API nereaguje dokonale po celou dobu. Někdy odesíláte požadavky příliš rychle a narazíte na limit; někdy je server dočasně zaneprázdněn; Někdy je váš požadavek od začátku špatný. Solidní integraci od amatérského pokusu odlišuje to, že tyto situace řeší prediktivně a automaticky. V této části se dozvíte o rychlostních limitech (RPM/ITPM/OTPM), chybě 429, opakování pokusu s exponenciálním stažením a správné klasifikaci běžných chybových kódů HTTP. Cíl: vytvořit tok, který je tak robustní, že si ho uživatel nikdy nevšimne.
Co jsou to rychlostní limity?
Poskytovatel omezuje, kolik práce může přepínač za dané časové období udělat. Tato ochrana; Chrání infrastrukturu i vás před náhlou explozí nákladů. Existují tři běžné typy limitů:
- RPM (požadavky za minutu): Počet požadavků za minutu.
- ITPM (Input Tokens Per Minute): Vstupní token, který lze zpracovat za minutu.
- OTPM (Output Tokens Per Minute): Výstupní token, který lze vyrobit za minutu.
Pokud některý z těchto limitů překročíte, poskytovatel odmítne požadavek a vrátí kód chyby 429. Limity se obecně liší v závislosti na úrovni vašeho účtu (úrovni) a mohou se časem zvyšovat.
Tip: V hlavičkách odpovědí můžete sledovat, kdy se blížíte limitu. Většina poskytovatelů hlásí vaši zbývající kvótu pomocí záhlaví jako x-ratelimit-remaining-*. Sledování těchto hodnot a omezení provozu vpředu je nejvyspělejší způsob, jak předejít problému, aniž byste dostali 429.
429 a exponenciální retracement
429 (limit sazby) je dočasná a opakovatelná chyba. Správnou odpovědí je chvíli počkat na požadavek a zkusit to znovu. Neustálé čekání však nestačí; Pokud se všichni pokusí znovu ve stejnou dobu, bude limit znovu dosažen. Řešením je exponenciální ústup: exponenciální prodloužení čekací doby s každým neúspěšným pokusem.
# Zkouška s exponenciální logikou backoff 1 → 429 → počkej 1 sec zkušební 2 → 429 → počkej 2 sec zkušební 3 → 429 → počkej 4 sec zkušební 4 → 429 → počkej 8 s (+ malé náhodné "chvění")... vzdát se a nahlásit po nejvýše N pokusech
Přidání trochu náhodnosti (jitter) k tomu zabrání kolizím požadavků při pokusu o opakování ve stejnou dobu. Odpověď 429 navíc často nese hlavičku `retry-after`: "zkuste to znovu za tolik sekund". Respektovat tento titul je přesnější než slepé čekání.
Upozornění: Když dostanete 429, "vynucení odesláním dalších požadavků" situaci zhorší; Limit se nadále plní a neprocházejí žádné požadavky. Správná reakce je ústup, ne zrychlení. Dobrá zpráva: většina oficiálních sad SDK automaticky zopakuje 429 a chyby serveru s couvnutím – použijte toto chování sady SDK před její ruční instalací.
Klasifikace chybových kódů HTTP
Ne každá chyba je stejná. Kritický rozdíl: lze to zkusit znovu, nebo jde o problém požadavku/identity?
kód
Význam
Dá se to zkusit znovu?
správná odpověď
400
Neplatný požadavek (chyba formátu/parametru)
ne
Opravte žádost; neposílejte znovu totéž
401
Chyba ověření (neplatný/chybějící klíč)
ne
Opravit klíč/titul
403
Žádná autorizace (žádný přístup k modelu/funkci)
ne
Zkontrolujte oprávnění/rozsah
404
Nenalezeno (nesprávné ID modelu/koncový bod)
ne
Správné ID/adresa modelu
429
Rychlostní limit překročen
Ano
Ústup + opakování poté
500
Chyba serveru
Ano
Zkuste to znovu s ústupem
529
Server přetížen
Ano
Zkuste to znovu s ústupem
Zlaté pravidlo: 429, 500 a 529 jsou dočasné; Zkouší se to znovu s odstoupením. 400, 401, 403, 404 jsou problémy se žádostí/totožností; Pokus znovu to nevyřeší a plýtvá úsilím. Váš kód musí tyto dvě skupiny rozlišovat.
Krok za krokem: Trvalé volání
- Odešlete žádost. V případě úspěchu pokračujte.
- Klasifikujte kód chyby. Dá se to zkusit znovu?
- Je-li to možné: opakujte pokus-po, použijte exponenciální ústup + jitter, zkuste omezený počet opakování (např. max. 5).
- Pokud nezkusíte: Opravit (formát/klíč) a zastavit; Neopakujte stejný chybný požadavek ve smyčce.
- Zvažte to vzdát. Pokud se to nezdaří ani po n pokusech, ukažte uživateli zdvořilou zprávu a zaznamenejte událost (sledovací jednotka 11).
# Robustní volání pseudo-codedene = 0repeat: response = request_at() if response.success: return response if response.code in [429, 500, 529] a zkuste < 5: wait = retry_after ?? (2^try sec + jitter) sleep(wait); zkuste += 1; git znovu if response.code v [400, 401, 403, 404]: save_error(response); return "požadavek musí být opraven" return "trvalá chyba, zkuste později"
# Zdvořilá zpětná vazba pro uživatele (když jsou opakované pokusy vyčerpány) "Právě nemám čas, nemohl jsem zpracovat váš požadavek. Zkuste to znovu brzy, nebo jsem váš požadavek uložil, ozvu se vám, až bude připraven."
Slabá výzva / silná výzva (zde: návrh chybové zprávy)
# WEAK (zobrazuje uživateli nezpracovanou chybu)"Chyba 429: rate_limit_error"
# SILNÝ (uživatelsky přívětivý, uklidňující, doporučující akci) "V systému došlo k dočasnému přetížení. Vaši žádost jsme bezpečně přijali a automaticky se zkoušejí znovu. Pokud se během několika sekund neobjeví výsledek, můžete stránku obnovit."
Odhalení surové technické chyby koncovému uživateli podkopává důvěru a může představovat zranitelnost zabezpečení. Interně kategorizujte chyby a poskytněte uživateli klidnou a akční zprávu; stačí napsat technický detail pro záznam.
Tři mini pouzdra
Případ 1 — Loď havarovala při dopravní explozi. Robot zákaznického servisu zaznamenal v den kampaně 429 nárůstu provozu; V kódu nebylo žádné opakování, každá chyba se uživateli projevila přímo jako „chyba“. Přidali exponenciální retracement + retry-after; se stejným provozem, požadavky prošly se zpožděním několika sekund, uživatel nezaznamenal žádné chyby.
Případ 2 — Vyzkoušení 400 ve smyčce. Integrace dostávala 404 kvůli neplatnému ID modelu, ale považovala všechny chyby za "přechodné" a zkoušela to znovu v nekonečné smyčce; Kulatina nabobtnala a vznikla zbytečná zátěž. Přidali klasifikaci chyb: 404 je považováno za trvalé, smyčka je zastavena a ID modelu je opraveno. Ponaučení: nezkoušejte každou chybu znovu.
Případ 3 — Řízení limitu zepředu. Úloha obohacování dat neustále běžela na limitu 429. Sledovali hlavičku x-ratelimit-remaining a omezili provoz podle kvóty. Drželi tedy stabilní tempo těsně pod limitem, aniž by zabírali 429s; Práce byla provedena předvídatelněji a rychleji.
Časté chyby
- Zvýšení rychlosti v 429: Zhorší situaci; Přepnout na ústup.
- Opakování každé chyby: 400/401/404 je trvalé; Zkoušet to znovu je plýtvání.
- Použití pevného čekání: Vytvoří kolizi; Použijte exponenciální + jitter.
- Ignorování „retry-after“: Nejpřesnější je dodržet čas určený poskytovatelem.
- Odhalení hrubé chyby uživateli: Otřese důvěrou, vytváří zranitelnosti; Zařadit dovnitř.
- Neomezený počet opakování: Nastavte horní limit (např. 5 opakování); pak se slušně vzdej.
Hlubší: řazení do fronty, souběžnost a jističe
Vydržení jediné touhy je prvním krokem; Skutečnou vyspělostí je zvládat velké množství požadavků bez narážení na limity. Do hry zde vstupují tři koncepty.
Fronta: Požadavky zařazujete do fronty, abyste je odeslali kontrolovaným tempem, nikoli okamžitě. Zařazení do fronty vyhlazuje náhlé výpadky provozu: I když najednou přijde 1 000 požadavků, fronta je uvolní rychlostí pod limitem. Tímto způsobem zabráníte 429, pak se nemusíte starat o opravu.
Limit souběžnosti: Omezíte, kolik požadavků je „ve vzduchu“ současně. Neomezené paralelní požadavky rychle naplní limity RPM a TPM. Rozumný strop souběžnosti (např. ne více než 10 souběžných požadavků) zachovává limity a činí systém předvídatelným.
Jistič: Pokud poskytovatel neustále vrací 500/529, místo toho, abyste zarputile zkoušeli každý požadavek, na chvíli „přerušíte obvod“ a požadavek rychle selžete, aniž byste jej kdy odeslali. Po čekání obvod znovu zapněte a zkuste to. Tento vzor zabraňuje zhroucení vašeho systému v případě dočasného selhání poskytovatele.
Tyto tři dohromady vytvářejí odolnost na systémové úrovni nad rámec logiky opakování jediného volání. V malém měřítku stačí automatické opakování SDK; Jak roste rozsah, stávají se fronty, souběžnost a jistič nepostradatelné. Všechny mají stejný společný cíl: reflektovat dočasný problém uživateli nikoli jako pád, ale jako neviditelné zpoždění několika sekund.
V souhrnu
429 se vrátí při překročení rychlostních limitů (RPM/ITPM/OTPM); Toto je dočasná chyba a bude zopakována pomocí retry-after a exponenciálního backoff + jitter. 500 a 529 jsou rovněž provizorní; 400/401/403/404 je problém s požadavkem/identitou a nelze jej vyřešit dalším pokusem. Robustní tok rozděluje chyby do těchto dvou skupin, zkouší omezený počet opakování, sleduje limit zepředu a zobrazuje uživateli klidné zprávy.
Aplikační úkol
Zvažte svou integraci. (1) Uveďte chybové kódy, se kterými se můžete setkat, a rozdělte je na „opakovatelné / trvalé“. (2) Zapište si svůj exponenciální plán stahování (počáteční blokování, koeficient, strop, jitter). (3) Určete, jak používat záhlaví opakování. (4) Napište zdvořilou zprávu, která se zobrazí uživateli po vyčerpání pokusů.
kontrolní seznam
- [ ] Dokážu vysvětlit limity RPM/ITPM/OTPM a 429.
- [ ] Mohu použít logiku exponenciálního ústupu + jitter + opakování-poté.
- [ ] Chybové kódy mohu klasifikovat jako opakovatelné/trvalé.
- [ ] Vím, že bychom neměli zkoušet každou chybu.
- [ ] Místo hrubé chyby mohu uživateli ukázat klidnou akční zprávu.