Slovník pojmů

Fronta zpráv

Fronta odděluje okamžitou změnu od pozdější práce. Automaticky ale nezaručuje exactly once, globální pořadí ani businessovou konzistenci.

Stručná definice

Práce může čekat, aniž by blokovala svého odesílatele.

Producent odešle zprávu s jasným významem a identitou do fronty nebo brokeru. Konzument ji převezme později, například vytvoří zásilku, odešle e-mail nebo importuje produkt. Asynchronní zpracování dovolí, aby se uživatel dočkal potvrzení objednávky, aniž by čekal na každou navazující integraci.

Fronta zpráv je obecný koncept. Může ji poskytovat broker jako RabbitMQ, cloudová služba nebo jiný systém. Samotná fronta neodstraní nutnost databázových transakcí, ochrany proti duplicitě a provozního monitoringu.

Použití

Kdy oddělit práci do pozadí

Největší přínos má práce, která může doběhnout později nebo má jiný rytmus než hlavní aplikace.

odeslání e-mailu, dokumentu nebo oznámení po objednávce
import produktového katalogu po dávkách
synchronizace skladu a cen s marketplace či ERP
zpracování události z webhooku bez blokování HTTP endpointu
vyrovnání krátkodobé špičky, když producent pracuje rychleji než konzument

Praktický příklad

Import katalogu bez blokování administrace

Administrátor spustí import produktového katalogu. Aplikace rozdělí soubor na dávky a do fronty vloží zprávy ImportProductBatch s import ID. Konzumenti mohou běžet paralelně, zatímco administrace ukazuje stav importu místo čekání na jeden dlouhý request.

Každá dávka ukládá výsledek podle import ID a pořadí dávky. Dočasný problém externího média se opakuje s prodlevou; vadný produkt neskončí v nekonečné smyčce, ale je dohledatelný pro opravu. Paralelní zpracování nevyžaduje globální pořadí pro různé produkty.

Jak funguje

Předání úlohy bez čekání na konec

Zpráva potřebuje význam, stabilní identitu a dohodnutý způsob reakce na selhání.

Producent Vytvoří command nebo event s ID a nezbytnými daty, pak jej předá do fronty.
Uložení a doručení Fronta nebo broker drží zprávu, dokud ji konzument nepřevezme.
Konzument Provádí samostatnou práci, například volání API dopravce či vytvoření dokladu.
Acknowledgement Po bezpečném dokončení potvrdí zpracování; při pádu před potvrzením může zpráva přijít znovu.
Chybový tok Přechodná chyba má omezený retry, trvalý problém skončí v DLQ nebo ve stavu pro cílené řešení.

Důležité pojmy

Asynchronní tok má vlastní pravidla.

Fronta není jen seznam úloh: ovlivňuje pořadí, propustnost, výpadky i způsob obnovy.

Command a event

Command žádá konkrétní akci, například CreateInvoice. Event oznamuje, co se stalo, například order.paid; může mít více nezávislých konzumentů.

Acknowledgement a redelivery

Potvrzení následuje po zaznamenaném výsledku. Když proces spadne dříve, opakované doručení je očekávaný scénář, ne výjimka.

Backpressure

Délka fronty ukazuje, že konzumenti nestíhají. Limity, autoscaling či zpomalení producenta brání tomu, aby backlog jen přesunul problém do paměti a latence.

DLQ a retry

Dead-letter queue oddělí zprávy, které nemají dál automaticky kolovat. Retry má omezený počet pokusů, prodlevu a dohledatelný důvod.

Vztah k podobným pojmům

Fronta je vzor, ne jméno konkrétního produktu.

Při návrhu je důležitější význam zprávy a bezpečný účinek než volba značky brokeru.

RabbitMQ: Konkrétní message broker s exchange, bindingy a frontami. Implementuje jeden konkrétní model předání.
Webhook: Vnější HTTP oznámení může být po ověření předáno do interní fronty k pozdějšímu zpracování.
Idempotence: Příjemce potřebuje ochranu výsledku, protože doručení vícekrát je běžná provozní realita.
Redis: Může obsloužit některé lehčí fronty či koordinaci, ale není synonymem asynchronního messagingu.

Výhody a omezení

Odolnější tok, ale více stavů k provozování.

Přínosy

oddělení rychlé uživatelské akce od pomalé integrace
postupné odbavení špičky podle kapacity konzumentů
izolace dočasného výpadku závislé služby
možnost nezávisle měřit a škálovat následné zpracování

Časté chyby

spoléhat na exactly once místo idempotentního konzumenta
nechat retry bez limitu a bez pozorovatelného konečného stavu
předpokládat globální pořadí při paralelních konzumentech
zapsat businessovou změnu, ale při selhání publishu po commitu ztratit navazující událost

Hranice použití

Asynchronní zpracování má řešit konkrétní problém.

Fronta pomáhá tam, kde se práce může dokončit později, potřebuje retry nebo má mít nezávislou kapacitu. Pokud uživatel nemůže pokračovat bez okamžitého výsledku, je nutné navrhnout synchronní operaci nebo jasný stav „zpracovává se“.

Předání zprávy nezajistí atomickou změnu přes databázi a broker. U důležité události po uložení objednávky má smysl řešit například outbox pattern; detail vždy závisí na ceně ztracené nebo duplicitní práce.

Na co myslet

Měřit frontu i výsledky konzumentů.

Zpracování na pozadí nemá znamenat, že se chyba ztratí mimo dohled.

jednoznačný typ zprávy, event ID a businessová identita
idempotentní konzument a potvrzení až po bezpečném výsledku
metriku délky fronty, stáří zpráv a počtu neúspěchů
retry s limitem, jitterem a kontrolovanou DLQ
postup pro ruční opravu a cílené opětovné zpracování

Časté otázky

Co fronta zpráv nezaručí

Je fronta zpráv totéž co API?

Ne. API je rozhraní mezi systémy. Fronta je způsob asynchronního předání práce; API může být synchronní i asynchronní.

Zaručí fronta přesně jedno zpracování?

Obvykle ne. Po pádu mezi vedlejším efektem a potvrzením může přijít druhé doručení, proto má být konzument idempotentní.

Zůstane pořadí zpráv zachované?

Jen v omezených scénářích. Více producentů, paralelní konzumenti a redelivery mohou změnit skutečné pořadí zpracování.

Má se opakovat každá chyba?

Ne. Přechodná technická chyba může mít řízený retry. Vadná data nebo zamítnutý požadavek často patří do DLQ a k opravě.

Jak řeším integrační toky v praxi

Odolnost synchronizace navrhuji od přijetí až po dohledání chyby.

U importů, objednávek a API integrací řeším, co se děje po výpadku, retry, duplicitě i při postupném zpracování většího objemu dat.

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