Seriál Message brokery

Dalším nástrojem, kterým se v seriálu o message brokerech budeme zabývat, je známý a široce nasazovaný projekt Apache Kafka. Dnes si řekneme základní informace a ukážeme si implementaci producentů a konzumentů zpráv.

Na článek popisující implementaci front zpráv představených poprvé v Systemu V a od té doby používaných i v dalších unixech i v Linuxu dnes navážeme. Popíšeme si alternativní implementaci front, tentokrát podle normy POSIX.

V seriálu jsme se již seznámili s řadou technologií implementujících fronty zpráv. Ovšem již v samotné základní instalaci Linuxu nalezneme hned dvě implementace: jedna vznikla v Systemu V, druhá je definována v POSIXu.

Ve druhém článku o nástroji NSQ si ukážeme některé možné konfigurace používané v praxi. Zaměříme se i na ty, které do značné míry vylučují existenci SPOF, tedy jednoho uzlu (počítače, služby, procesu).

V další části seriálu (nejenom) o message brokerech se seznámíme se systémem zpráv nazvaným NSQ. Je mimochodem vyvinut v jazyce Go a je založen na myšlence decentralizace a navíc tak, aby neobsahoval centrální uzel.

Minulý článek byl věnován projektu Dramatiq určenému především pro vývojáře používající jazyk Python. Dnes se pro změnu budeme věnovat jinému jazyku, konkrétně jazyku Clojure a knihovně nazvané příznačně Durable Queue.

V dnešní části seriálu o message brokerech si popíšeme projekt nazvaný Dramatiq. Podobně jako v případě projektů RQ a Celery se jedná o systém pro správu front a úloh určený pro použití v aplikacích naprogramovaných v jazyku Python.

V závěrečném článku o knihovně nanomsg se seznámíme s použitím této knihovny z dalších jazyků, zejména z Pythonu. Taktéž si ukážeme, že některé operace je možné provádět přímo z příkazové řádky.

V dnešní části seriálu o message brokerech dokončíme popis základních komunikačních strategií poskytovaných knihovnou nanomsg. Všechny strategie budou pochopitelně implementovány i v demonstračních příkladech.

V seriálu o message brokerech a k nim přidružených technologiích jsme se mj. seznámili i s knihovnou ZeroMQ. Ideovým následovníkem této knihovny je projekt nazvaný nanomsg s jehož základními možnostmi se seznámíme v dnešním článku.

V předchozí části seriálu jsme se seznámili s nástrojem nazvaným NATS, který lze použít ve funkci výkonného brokera zpráv. Nad tímto nástrojem je postavený NATS Streaming Server, jehož popisem se budeme zabývat dnes.

V dnešní části seriálu o message brokerech se seznámíme se základními možnostmi nabízenými systémem NATS. Ukážeme si jak instalaci a spuštění serveru NATS, tak i komunikaci s ním s využitím klientů naprogramovaných v jazyce Go.

Seriál o message brokerech by nebyl úplný, pokud bychom se neseznámili s implementací klientů v jazyku Go. Proto si ukážeme balíčky stomp a rmq. Taktéž se seznámíme se systémem NATS, který je naprogramován právě v Go.

Dnes si nejdříve ukážeme, jaký je možné komunikovat se systémem Apache ActiveMQ při použití protokolu AMQP. Druhá část článku je věnována spolupráci mezi Apache ActiveMQ a aplikacemi naprogramovanými v jazyku Go.

Dnes si ukážeme některé praktické příklady naprogramované v Pythonu, které komunikují s message brokerem Apache ActiveMQ (AMQ) s využitím protokolu STOMP. Vysvětlíme si potvrzování zpráv, použití transakcí i posílání binárních zpráv.

Další implementací message brokeru, s níž se seznámíme, je nástroj nazvaný Apache ActiveMQ. Dnes si ukážeme jeho instalaci, základní metody komunikace s ním a také utility pro sledování a ovládání tohoto nástroje.

Dnes si ukážeme některé další použití knihovny ØMQ. Nejprve dokončíme popis komunikační strategie PUSH-PULL, ukážeme si zařízení PyZMQ a pak si řekneme, jak je možné použít knihovnu ØMQ v programovacím jazyce Java.

V další části seriálu o knihovně ØMQ a rozhraní PyZMQ se budeme zabývat využitím takzvaných zařízení (device), která se poměrně často používají při implementaci systémů se složitější architekturou a s větším počtem uzlů.

Ve druhém článku o knihovně ØMQ a rozhraní PyZMQ si ukážeme, jak korektně zavírat připojení s využitím správců kontextu, popř. dekorátorů. Dále si popíšeme přenos strukturovaných dat a komunikační strategii PUSH-PULL.

V šesté části seriálu o nástrojích pro asynchronní posílání a zpracování zpráv se seznámíme se základními vlastnostmi knihovny ØMQ, která je též známá pod jmény 0MQ, ZMQ či ZeroMQ.

Ve druhé části článku o RabbitMQ si ukážeme další možnosti, které lze při nasazení tohoto systému využít. Popíšeme si způsob konfigurace tzv. rozvětvení (fanout), použití směrovačů či konfiguraci front s prioritami zpráv.

Třetím nástrojem implementujícím fronty zpráv a popř. i asynchronní fronty úloh, s nímž se na stránkách Rootu seznámíme, je nástroj nazvaný RabbitMQ. Dnes si ukážeme základní vlastnosti tohoto systému a jeho použití v Pythonu a Clojure.

Ve druhém článku o projektu Celery si nejprve ukážeme dva nástroje určené pro sledování stavu workerů, úloh a front. Dále si popíšeme tvorbu periodických úloh, použití plánovače a na závěr se též zmíníme o signálech.

Druhým systémem pro správu úloh psaných v Pythonu a spouštěných asynchronně s využitím front je nástroj Celery, s jehož základním nastavením a vlastnostmi se dnes seznámíme.

Po popisu základních vlastností databáze Redis si ukážeme užitečný nástroj, který je na Redisu postaven. Ten se jmenuje RQ (Redis Queue) a slouží pro správu úloh, které jsou (většinou paralelně) spouštěny na pozadí.