RabbitMQ - implementace message brokera

1. 7. 2021
rabbitMQ logo
RabbitMQ

Message broker

Message broker je software, který dovoluje, jak už název vypovídá, různým aplikacím či službám komunikovat a vyměňovat si mezi sebou informace. Tyto brokery využívají ke komunikaci různých protokolů (např. AMQP), což dovoluje aplikacím být na sobě nezávislé a komunikovat mezi sebou i přes to, že jsou napsány v různých jazycích či běží na rozdílných strojích.

Message brokery tvoří tzv. prostředníka mezi ostatními aplikacemi a poskytují možnost odeslat jakoukoliv zprávu bez nutné znalosti komu je zpráva odeslána, jestli a jak bude zpracována či kolik takových příjemců existuje.

Jednou z hlavních částí těchto brokerů je message queue, která ukládá a řadí příchozí zprávy, dokud je cílová aplikace není schopna přijmout. Zprávy si tedy zachovávají přesně takové pořadí, v jakém je zdrojová aplikace odeslala.

RabbitMQ

Jednou z implementací message brokera je RabbitMQ, který aktuálně podporuje několik komunikačních protokolů, jako například AMQP, MQTT, STOMP aj.

RabbitMQ je vysoce dostupný, škálovatelný a lze jej dostatečně nakonfigurovat ke splnění požadavků na službu. Též nabízí vlastní management rozhraní, díky kterému lze celého brokera ovládat či monitorovat. Pro práci s brokerem existují různé knihovny pro mnoho programovacích jazyků. My se budeme v dnešním článku zabývat hlavně komunikací přes samostatné queue a následně přes exchange.

Jako první si vysvětlíme jednotlivé pojmy, které budeme dále používat.

  • Message – balík informací, který se skládá z hlavičky (header) nesoucí metadata zprávy a samotného obsahu zprávy (body).
  • Producer – aplikace, která vytváří a odesílá message.
  • Consumer – aplikace, která přijímá a zpracovává message.
  • Queue – komunikační kanál mezi producerem a consumerem.
  • Exchange – odděluje queue od producera. V takovém případě producer neví o cílových frontách, pouze message odešle právě do exchange, který na základě určitého klíče předá zprávu všem potřebným frontám.
  • Routing key – díky tomuto klíči je schopen exchange odeslat message těm správným consumerům.
  • Binding key – definuje vazbu mezi consumerem a exchange. Těchto klíčů může být 0 – N, a na základě kombinace tohoto klíče s routing key exchange rozhodne, zda má být message předána právě tomuto consumerovi.

Pro názorovou ukázku dále uvažujme, že je naše aplikace rozdělena na jednotlivé mikroslužby, které musí mezi sebou komunikovat. Následně si proto popíšeme, jak by taková komunikace probíhala v případě využití právě queue a exchange.

Queue

Nejjednodušším způsobem komunikace je využití „holé“ fronty. Princip spočívá v tom, že jedna ze služeb (v tomto případě producer) vytvoří zprávu a odešle ji do fronty. Na stejnou frontu je napojená druhá služba (consumer), která čeká na jakoukoliv zprávu přijatou z této fronty, a tu poté zpracuje.

RabbitMQ - Queue

Samotné fronty lze různě konfigurovat. Můžeme například nastavit ukládání zpráv takovým způsobem, dokud některý z consumerů tuto zprávu neoznačí za přijatou, resp. zpracovanou. Tímto nastavením se vyvarujeme případné ztrátě zpráv v případě, kdy dojde k neočekávanému výpadku některé ze služeb.

Stejně tak, jako může do fronty posílat zprávy více producerů, může i více consumerů tyto zprávy zpracovávat. Na základě toho můžeme nastavit různá chování těchto consumerů.

RabbitMQ - Queue

Ať už jde o zpracování jedné zprávy odeslané do fronty všemi consumery nebo dále možnost mezi všechny consumery rozložit zátěž zpracování zpráv - tzn., že pokud první consumer již zprávu zpracovává a ve frontě se objeví zpráva další, je tato předána jinému volnému consumerovi.

Exchange

Pokud nám komunikace za pomoci jednoduchých front nestačí, můžeme využít již zmíněných služeb exchange. Co si ale pod pojmem exchange představit?

V reálném světě jej lze přirovnat k často využívanému odběru novinek, které nabízí všemožné portály. Tzn. že my jako odběratelé se zavážeme k odběru těchto novinek na základě určitých preferencí. Následně dojde ke vzniku novinky s určitou povahou (typem), kterou portál (můžeme si jej představit jako producer) odešle na jiný server a dále neřeší, komu má jaký email odeslat. Tento server zastává tedy roli exchange a na základě našich preferencí (consumer preferencí) nám patřičné emaily rozešle.

Existuje několik typů exchange:

  1. Fanout
    Je nejjednodušším typem exchange, který všechny do něj odeslané zprávy předá každé frontě (consumerovi) bez ohledu na nějaká pravidla. Zde jako consumer stačí vytvořit tzv. binding key mezi vytvořenou frontou a exchange.
    RabbitMQ - Fanout
  2. Direct
    Tento typ, na rozdíl od předchozího, bude při vytváření spojení mezi frontou consumera a exchange využívat jak binding key, tak routing key. Jako routing key si můžeme představit právě typ vyprodukované zprávy. V případě producera je routing key předáváno vždy. Tzn., že je zpráva předána pouze těm frontám (consumerům), kteří uvedli totožný klíč.RabbitMQ - DirectZ obrázku si můžeme povšimnout, že druhý consumer naslouchá na dva routing keys (black, green). Tzn., že při provádění bindingu můžeme uvádět až N-klíčů.
  3. Topic
    Dle mého nejzajímavějším typem exchange je topic 🙂 Funguje na podobném principu jako typ direct, ale s tím rozdílem, že routing key je rozdělen na logické části oddělené tečkou (např. news.sport.football). Binding key může pak představovat buď kompletní routing key nebo může využívat tzv. wildcards, které dokáží nahrazovat části routing key.

    *
    (hvězdička) – nahrazuje přesně jedno slovo
    # (hashtag) – nahrazuje žádné nebo N-slovRabbitMQ - TopicJak je znázorněno na obrázku výše, pokud routing key bude color.orange.new, bude zpráva předána prvnímu consumerovi (Q1). A to proto, že tento routing key splňuje formát s wildcards uvedený právě v binding key. Naopak, pokud routing key bude lazy.create.center.employee, půjde zpráva do druhého consumera (Q2).
  4. Headers
    Pokud nám nevyhovují routing keys, můžeme využít typ headers. Ten routing key ignoruje a namísto toho při rozhodování, kterým consumerům zprávu předá, využívá hlaviček ze zprávy.
    • type = error
    • application = web
    • x-match = all
    Hlavička x-match může nabývat dvou hodnot – all nebo any. V případě "all" je potřeba, aby všechny hlavičky seděly s hlavičkami uvedenými při bindování fronty consumera. Jakmile alespoň jedna nesedí, consumer zprávu nedostane.
    Naopak v případě "any" stačí, aby se shodovala alespoň jedna z hlaviček. V takovém případě pak consumer zprávu obdrží.

Závěr

Cílem tohoto článku bylo se primárně seznámit s message brokery jako takovými, a také si přiblížit základní prvky implementace s RabbitMQ.

Samozřejmě způsobů, jak využít message brokery je mnoho. Proto se v dalším pokračování zaměříme na možnosti využití již zmiňovaného exchange, a přiblížíme si ještě o něco více právě užití typu topic.

Sledujte nás i nadále! 🙂

Zdroj: www.rabbitmq.com

< Zpět na VÝPIS AKTUALIT

Další články z kategorie

23. 12. 2021
Úspěšný vstup do nového roku a svátky plné pohody, klidu a odpočinku přeje celý tým B2A!

Přejeme všem obchodním partnerům i dalším příznivcům vánoční svátky přesně takové, jaké máte nejraději. Plné pohody, odpočinku, dobrého jídla a společnosti těch nejbližších. Děkujeme za perfektní spolupráci v roce 2021 a přejeme šťastný a úspěšný vstup do roku 2022!

PŘEČÍST
6. 12. 2021
První krůčky k digitalizaci zdravotnictví probíhají i u nás v ČR

Dříve trávili novorozenci na oddělení týdny, někdy i měsíce. A rodiče v permanentním stresu pendlovali mezi nemocnicí, domovem a prací. A dnes. Dnes jsme pokročili tak daleko, že pokud to zdravotní stav alespoň trochu dovolí, miminko můžou rodiče po pár dnech vzít domů. Sžívat se a užívat si společné chvíle. A hlavně – být v […]

PŘEČÍST
6. 11. 2021
Proč cílíme na User Centric Approach

Zastáváme názor, že spokojení zaměstnanci jsou těmi největšími tahouny firemního rozvoje. Při vylaďování našich aplikací hrál proto „user centric approach„ vždy zásadní roli… Správně pojmenovat nám jej ale pomohla až společnost Apple. Místo zaměření na procesy, které ještě nefungují, se zaměřujeme právě na přání a priority konkrétních lidí na konkrétních pozicích a stavíme softwarové vrstvy, které přesně odpovídají […]

PŘEČÍST
30. 10. 2021
Petr Kubíček jako host v novém díle podcastu #salesbooster

O tom, proč je metoda „user centric approach“ základním stavebním kamenem úspěšné digitalizace nebo jak se za posledních sedm let změnit náš mindset v B2A, hovořil Petr Kubíček (CEO v B2A) s Petrem Sobotkou v novém díle podcastu SalesBooster. „S Petrem Sobotkou se znám už od dob vysokoškolského studia… a tak jsem jeho nabídku zúčastnit se jako […]

PŘEČÍST
30. 9. 2021
Tři fáze designování komponent – 3.díl

V této závěrečné fázi designování komponent se zaměříme na použitelnost CSS, zamyslíme se nad možným rozšířením o tabulkové direktivy a uvedeme si jejich hlavní výhody. Pro ty z vás, které předchozí dva díly minuly, uvádím níže odkazy k přiblížení tématu: Tři fáze designování komponent – 1.díl Tři fáze designování komponent – 2.díl CSS Vstup do […]

PŘEČÍST
19. 5. 2021
Fastlane z trochu jiného úhlu pohledu

Zřejmě všichni iOS vývojáři již slyšeli o nástroji Fastlane, který se využívá k automatizaci činností v průběhu celého vývoje nejen iOS aplikací. Jako první nás nejspíše napadne jejich generování, testování a vydávání. My se dnes ale podíváme na jiné - možná ne tolik rozšířené - využití, které tento nástroj rovněž poskytuje. Fastlane Fastlane umí podat […]

PŘEČÍST
29. 4. 2021
Tři fáze designování komponent – 2.díl

V předchozím díle jsme si názorně ukázali design tabulkové komponenty tzv. “from scratch” jen za pomocí HTML a CSS. Markup jsme rozčlenili do komponent za pomocí BEM konvence pojmenování CSS tříd, a tímto jsme si předchystali půdu pro pokračování, které je uvedeno v tomto 2.dílu. Celá tato třídílná série je do jisté míry na sobě nezávislá […]

PŘEČÍST
17. 3. 2021
Přínosy digitalizace výroby pro oblast kvality

Společnost Intemac Solutions, s.r.o. - zabývající se poradenstvím českým firmám v oblasti implementace digitálních technologií - nás pozvala, abychom se zúčastnili prvního studiového webináře, který se konal 3.března 2021 v Kuřimi.  Webinář byl zaměřený na téma „Zlepšování kontroly kvality díky digitálním nástrojům“, a to konkrétně na přínosy digitalizace ve výrobních firmách. V rámci webináře jsme […]

PŘEČÍST
16. 3. 2021
Přínosy digitalizace výroby pro oblast kvality
PŘEČÍST
4. 3. 2021
Tři fáze designování komponent - 1.díl

Dnešní článek je první částí z třídílné série o designování komponent ve třech doporučených krocích (fázích). Nenechte si tedy ujít ani následující dvě části, které budou po vydání tohoto článku následovat, abyste mohli finální výsledek zhodnotit jako celek! Fáze první (CSS first approach) Dnes si na konkrétním příkladu tabulkového layoutu ukážeme první fázi, kterou by designování komponent […]

PŘEČÍST

Hledáme lidi s talentem a zapálením pro věc.

Zobrazit pracovní nabídky
menu-circlecross-circle
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram