Slovník pojmů

Retry

Opakování po chybě pomáhá jen tehdy, když nezvětší výpadek a nemůže vytvořit druhou objednávku, platbu nebo zásilku.

Stručná definice

Stejný požadavek neopakovat slepě.

Retry dává další šanci operaci, kterou přerušil například timeout, krátký síťový výpadek nebo dočasná nedostupnost služby. V integračním workeru může snížit počet ručních zásahů, ale musí mít maximální počet pokusů, časový limit a dohledatelný konečný stav.

Timeout není důkaz, že vzdálená služba nic neprovedla. U změnové operace je výsledek neznámý. Bez idempotency key, externí identity nebo databázového constraintu může další pokus založit duplicitní objednávku či zásilku. Retry řeší časování pokusu; idempotence chrání jeho businessový výsledek.

Použití

Kdy může druhý pokus pomoci

Rozhoduje konkrétní kontrakt a význam operace, ne pouze číslo HTTP odpovědi.

síťový timeout, reset spojení nebo krátká nedostupnost DNS
HTTP 502, 503 nebo 504, pokud to dokumentace služby a operace dovoluje
HTTP 429 se zpožděním podle Retry-After
dočasný deadlock databáze, kdy transakce může bezpečně začít znovu
zpráva z fronty, kterou worker nedokončil kvůli výpadku závislé služby

Praktický příklad

Marketplace API dočasně vrací 503

Importer odešle změnu zásoby s identitou produktu a importní operace. Marketplace vrátí 503. Worker provede druhý pokus až po krátkém backoffu, další později a s jitterem. Jestli služba pošle Retry-After, je to nejdřívější možný termín dalšího requestu.

Při HTTP 422 se job nezkouší znovu — data je třeba opravit. Při timeoutu se opakuje se stejnou identitou, protože vzdálená strana mohla zápis přijmout. Po vyčerpání stanoveného rozpočtu se práce označí jako selhaná pro obsluhu, ne jako tiché nekonečné retry.

Jak funguje

Od klasifikace chyby k řízenému konci

Dobrá politika neprovádí další pokus, dokud nezná hranice a cenu chyby.

Klasifikace Rozliší přechodnou technickou chybu, omezení kapacity, chybný vstup a neznámý výsledek po timeoutu.
Bezpečnost opakování Ověří idempotency key, externí ID nebo jinou ochranu změnové operace.
Instrukce služby Validní Retry-After určuje nejdřívější další pokus; klient jej nesmí obcházet okamžitým requestem.
Backoff a jitter Prodlužované, zastropované intervaly s náhodnou odchylkou brání retry stormu a synchronizované špičce.
Konečný stav Po vyčerpání pokusů se úloha označí jako selhaná, uloží důvod a podle významu jde do DLQ nebo k cílené opravě.

Důležité pojmy

Chyba, prodleva a společná kapacita

Technické označení chyby je vodítko, nikoli univerzální automatické pravidlo.

Přechodná a trvalá chyba

HTTP 400 a 422 obvykle vyžadují opravu vstupu; 401 může vyžadovat řízené obnovení tokenu; 403 bývá otázka oprávnění. 5xx může být dočasné, ale záleží na službě.

Exponential backoff a jitter

Interval postupně roste do horního limitu. Jitter rozptýlí pokusy mnoha workerů, aby společně znovu nezatížily právě obnovenou službu.

Retry-After

HTTP 429 a 503 mohou říct počet sekund nebo datum, před kterým se požadavek nemá opakovat. Lokální backoff může termín prodloužit, ne zkrátit.

Retry budget

Společný limit opakovaných pokusů chrání závislou službu při plošném selhání. Není totéž co limit příchozích požadavků API.

Vztah k podobným pojmům

Retry není ani limit, ani jediná ochrana duplicit.

Tyto mechanismy se doplňují, ale nevzájemně se nenahrazují.

Idempotence: Zajišťuje, aby opakování nezměnilo businessový stav více než první úspěch.
Rate limiting: Určuje tempo požadavků; retry po 429 má limit respektovat.
Fronta zpráv: Může doručit zprávu znovu i bez vlastní retry smyčky; konzument proto potřebuje stejnou ochranu.
Circuit breaker: Při dlouhém výpadku dočasně zastaví nové pokusy; retry sám nemusí být správná reakce.

Výhody a omezení

Méně falešných selhání, ne bezplatná odolnost.

Přínosy

odolnější práce s krátkým výpadkem bez ručního zásahu
jasně stanovené chování HTTP klientů a workerů
nižší riziko okamžitého přetížení obnovené služby
dohledatelnost počtu pokusů a konečné příčiny

Časté chyby

opakovat každý POST bez deduplikace
násobit retry v HTTP klientu, workeru i brokeru současně
okamžitě opakovat 429 nebo 503
nechat úlohu donekonečna v requeue smyčce

Hranice použití

Pokusy řídit na jedné vědomě zvolené vrstvě.

Přechodnou chybu je vhodné opakovat ve vrstvě, která zná kontext, deadline a idempotenci operace. Když stejnou politiku bez koordinace používá klient, frontend, job i broker, několik očekávaných pokusů se snadno změní na desítky skutečných requestů.

Retry nenapraví chybný formát dat, špatnou konfiguraci, chybějící oprávnění ani výpadek trvající déle než obchodně dává smysl. Po konečném selhání musí systém vědět, co se stalo, a ne jen skrytě zahodit práci.

Na co myslet

Politiku testovat i při nejistém výsledku.

Nejdůležitější scénář nastává, když operace možná uspěla, ale odpověď nedorazila.

kategorie chyb podle kontraktu konkrétní služby
idempotency key nebo stabilní businessová identita pro změnové operace
zastropovaný backoff, jitter, počet pokusů a celkový deadline
respektování Retry-After a společný retry budget
logování correlation ID a důvodu chyby bez tokenů a citlivého payloadu

Časté otázky

Kdy opakování nedává smysl

Má se opakovat každá odpověď 5xx?

Ne. 5xx často znamená dočasný problém, ale bezpečnost opakování závisí na operaci, chybovém kódu a dokumentaci poskytovatele.

Je POST automaticky nebezpečné opakovat?

Bez stabilní identity nebo idempotency key může být. Konkrétní POST lze navrhnout tak, aby druhý pokus vytvořil tentýž výsledek.

Je Retry-After totéž co backoff?

Ne. Retry-After je instrukce poskytovatele; backoff je lokální politika klienta. Další pokus nesmí nastat dříve, než říká validní Retry-After.

Je retry totéž co redelivery z fronty?

Ne nutně. Redelivery může vzniknout po pádu konzumenta; v obou případech ale zpracování potřebuje idempotenci.

Jak řeším odolnost integrací v praxi

Nejistý výsledek zpracovávám jako součást návrhu, ne jako výjimku.

U API integrací řeším limity, timeouty, retry, duplicity a možnost bezpečně dohledat či obnovit neúspěšný tok.

Jak pracuji s API a integracemi Nezávazně probrat projekt