Jan Mikoláš
Slovník pojmů
RabbitMQ
RabbitMQ je konkrétní broker pro asynchronní předávání a směrování zpráv; neřeší za aplikaci businessovou konzistenci ani exactly once zpracování.
Stručná definice
Prostředník mezi producentem a konzumentem zprávy.
RabbitMQ přijme publish od producenta, předá jej do exchange a podle bindingů a routing key nasměruje zprávu do jedné nebo více front. Konzument ji převezme, vykoná práci a po bezpečném dokončení ji potvrdí. Tento model dovoluje oddělit rychlý checkout od e-mailu, faktury nebo komunikace se skladem.
RabbitMQ je konkrétní message broker, zatímco fronta zpráv je obecný způsob asynchronní komunikace. Broker nenahradí transakci mezi databází a externím API: při pádu mezi voláním dopravce a acknowledgementem může zpráva přijít znovu a konzument musí účinek rozpoznat idempotentně.
Použití
Kde RabbitMQ pomáhá
Broker se hodí, když část práce nemusí skončit v jedné HTTP odpovědi nebo má být zpracována nezávisle.
- odeslání e-mailu, faktury nebo exportu po vytvoření objednávky
- import objednávek, produktů a skladů z marketplace
- rozvedení jedné události k dopravci, účetnictví a analytice
- řízené retry dlouhých a dočasně neúspěšných integračních úloh
- vyrovnání krátké špičky mezi rychlým producentem a pomalejší službou
Praktický příklad
Objednávka aktivuje několik nezávislých kroků
Po zaplacení objednávky e-shop publikuje order.paid do topic exchange commerce.events. Bindingy ji směrují zvlášť do fronty pro e-mail, export do skladu, marketplace a účetní doklad. Checkout tak nečeká na všechny navazující služby.
Konzument dopravce uloží event ID a výsledek exportu před acknowledgementem. Když timeout skryje odpověď dopravce, další doručení pracuje se stejnou identitou a nevytvoří druhou zásilku. Dočasná chyba jde do retry s prodlevou, špatná adresa do DLQ s důvodem pro obsluhu.
Jak funguje
Od publikování po potvrzení konzumentem
Přijetí zprávy brokerem a úspěšné businessové zpracování jsou dvě rozdílné události.
- Publisher Odešle zprávu do exchange spolu s routing key a podle potřeby čeká na publisher confirm.
- Exchange a binding Exchange podle typu a bindingů určí cílové fronty; zpráva nemusí automaticky skončit ve frontě.
- Queue Fronta drží zprávu, dokud ji nepřevezme konzument. Durabilita je provozní vlastnost, nikoli absolutní garance dat.
- Consumer Prefetch omezuje počet rozpracovaných zpráv na konzumenta; ten po práci pošle ack, nebo zvolí řízené odmítnutí.
- Retry a DLQ Dočasná chyba jde do omezeného zpožděného retry, trvalá či opakovaně selhávající zpráva do dead-letter toku pro kontrolu.
Důležité pojmy
Směrování, potvrzení a chybové toky
Každý prvek topologie řeší jinou část doručení.
Exchange
Direct exchange porovnává routing key přesně, topic používá vzory a fanout doručí kopii každé zprávy všem navázaným frontám. Exchange není fronta.
Acknowledgements a confirms
Consumer ack říká, že konzument dokončil svou práci. Publisher confirm říká, že broker převzal publish. Ani jedno není potvrzení úspěchu vzdáleného API.
Redelivery a idempotence
Pád konzumenta před ackem může způsobit další doručení. Zpráva s event ID a businessovým klíčem musí jít bezpečně vykonat vícekrát.
DLX a DLQ
Dead-letter exchange je místo, kam broker směruje vyřazené zprávy podle topologie. Dead-letter queue je obvykle cílová fronta pro jejich analýzu nebo řízený redrive, ne automatické řešení chyby.
Vztah k podobným pojmům
Brokera nelze ztotožnit s každou frontou.
RabbitMQ poskytuje konkrétní AMQP model a provozní schopnosti; obecný návrh toku zůstává odpovědností aplikace.
- Fronta zpráv
- Obecný princip asynchronního předání práce. RabbitMQ je jedna z jeho konkrétních implementací.
- Retry
- Rozhoduje, kdy má smysl zkusit práci znovu. Okamžité requeue při každé chybě vytváří zatěžující smyčku.
- Redis
- Hodí se pro cache, čítače či některé koordinační úlohy, ale automaticky nenahrazuje messaging topologii RabbitMQ.
- Symfony a Laravel
- Framework může práci do brokeru předávat, ale nepřenáší na RabbitMQ návrh identity, transakce a vedlejších účinků.
Výhody a omezení
Řízené doručení za cenu provozní složitosti.
Přínosy
- směrování jedné události do nezávislých zpracování
- oddělení propustnosti producenta a konzumenta
- explicitní confirms, ack, prefetch a dead-letter toky
- možnost sledovat backlog, nepřijaté a znovu doručené zprávy
Rizika
- ztracený confirm nebo ack může vést k duplicitě
- neomezený backlog zatěžuje disk, paměť a obnovu brokeru
- více konzumentů zvyšuje propustnost, ale komplikuje pořadí
- pouhá durable queue neznamená, že se data nikdy neztratí
Hranice použití
Fronta není povinná pro každou operaci.
RabbitMQ se vyplatí, když je možné práci dokončit později, když potřebuje vlastní škálování nebo když má výpadek externí služby zůstat mimo kritickou cestu objednávky. Význam má jen s monitoringem front, pravidly retry, limity a odpovědností za DLQ.
Pokud uživatel bezprostředně potřebuje výsledek, asynchronní předání jej nenahradí. Také jednoduchý lokální proces nemusí získat nic složitou topologií; nejdřív je vhodné vyjasnit obchodní hranici a způsob bezpečného předání změny z databáze.
Na co myslet
Konfigurace je součástí spolehlivosti toku.
Topologie, zprávy i provozní metriky musí odpovídat ceně případné chyby.
- publisher confirms a dohledání neroutovaných publishů tam, kde na nich záleží
- manual ack až po zaznamenaném výsledku, s idempotentním konzumentem
- omezený retry s prodlevou, důvodem chyby a DLQ
- prefetch a limity velikosti fronty podle kapacity konzumentů
- monitoring ready, unacknowledged, redelivered a dead-letter zpráv
Časté otázky
Co RabbitMQ nepotvrzuje
Je publisher confirm potvrzení úspěšného zpracování?
Ne. Znamená, že broker převzal publish. Neříká, že konzument práci vykonal ani že uspěla ve vzdáleném systému.
Jaký je rozdíl mezi DLX a DLQ?
DLX je exchange pro dead-lettering. DLQ je zpravidla fronta, do které jsou vyřazené zprávy směrovány.
Zaručí RabbitMQ exactly once?
Ne. Běžný návrh počítá s opakovaným doručením a idempotentním konzumentem.
Zůstane pořadí vždy zachované?
Ne jako globální garance. Více publisherů, konzumentů, prefetch a redelivery mohou změnit skutečné pořadí zpracování.
Jak řeším integrační toky v praxi
Asynchronní práci navrhuji s ohledem na chybu a dohledatelnost.
U importů, objednávek a synchronizací řeším hranice systémů, retry, duplicity a možnost bezpečně navázat po selhání.