Az üzenetközvetítők megértése. Az üzenetküldés mechanikájának elsajátítása az ActiveMQ-val és a Kafkával. 1. fejezet

Hello!

Elkezdtem fordítani egy kis könyvet:
«Az üzenetközvetítők megértése”,
szerző: Jakub Korab, kiadó: O'Reilly Media, Inc., megjelenés dátuma: 2017. június, ISBN: 9781492049296.

A könyv bevezetőjéből:
”... Ez a könyv megtanítja Önnek, hogyan gondolkodjon a bróker üzenetküldő rendszerekről, összehasonlítja és szembeállítja a két népszerű brókertechnológiát: az Apache ActiveMQ-t és az Apache Kafkát. Felvázolja azokat a használati eseteket és fejlesztési ösztönzőket, amelyek arra késztették a fejlesztőket, hogy nagyon eltérő megközelítéseket alkalmazzanak ugyanarra a területre – a rendszerek közötti üzenetküldésre egy közbenső közvetítővel. Megvizsgáljuk ezeket a technológiákat az alapoktól, és kiemeljük a különböző tervezési döntések hatását az út során. Mélyen megérti mindkét terméket, megérti, hogyan kell őket használni és hogyan nem, és megérti, mire kell figyelnie, amikor más üzenetküldési technológiákat fontol meg a jövőben. ... "

Eddig lefordított részek:
1. fejezet Bevezetés
3. fejezet Kafka

Az elkészült fejezeteket lefordítva teszem közzé.

1. FEJEZET

Bevezetés

A rendszerek közötti üzenetküldés az IT egyik legkevésbé ismert területe. Fejlesztőként vagy építészként nagyon jól ismerheti a különféle keretrendszereket és adatbázisokat. Valószínű azonban, hogy csak futólag ismeri a brókeralapú üzenetküldési technológiák működését. Ha így érzed, ne aggódj, jó társaságba kerültél.

Az emberek általában nagyon korlátozottan érintkeznek az üzenetküldő infrastruktúrával. Gyakran csatlakoznak egy régen létrehozott rendszerhez, vagy letöltenek egy disztribúciót az internetről, telepítik a PROM-ba, és elkezdenek kódot írni hozzá. Az infrastruktúra PROM-ban való futtatása után az eredmények vegyesek lehetnek: üzenetek vesznek el hibák miatt, a küldés nem úgy működik, ahogyan azt várta, vagy a brókerek „leakasztották” a gyártókat, vagy nem küldenek üzeneteket a fogyasztóknak.

Ismerősen hangzik?

Gyakori forgatókönyv, hogy az üzenetküldő kód egyelőre kiválóan működik. Amíg nem működik. Ez az időszak hamis biztonságérzetbe ringatja az őrt, ami több olyan kódhoz vezet, amely a technológia alapvető viselkedésével kapcsolatos hamis hiedelmeken alapul. Amikor a dolgok kezdenek rosszul menni, egy kényelmetlen igazsággal kell szembenéznie: nem igazán értette a termék mögött meghúzódó viselkedést vagy a szerzők által választott kompromisszumokat, mint például a teljesítmény kontra megbízhatóság, vagy a tranzakciósság és a horizontális méretezhetőség. .

A brókerek működésének mély megértése nélkül az emberek látszólag ésszerű kijelentéseket tesznek üzenetküldő rendszereikről, például:

  • A rendszer soha nem fogja elveszíteni az üzeneteket
  • Az üzenetek feldolgozása sorrendben történik
  • A fogyasztók hozzáadásával a rendszer gyorsabb lesz
  • Az üzeneteket csak egyszer kézbesítjük

Sajnos ezen állítások egy része olyan feltételezéseken alapul, amelyek csak bizonyos körülmények között érvényesülnek, míg mások egyszerűen tévesek.

Ez a könyv megtanítja Önnek, hogyan gondolkodjon a brókeralapú üzenetküldő rendszerekről, összehasonlítja és szembeállítja a két népszerű brókertechnológiát: az Apache ActiveMQ-t és az Apache Kafkát. Felvázolja azokat a használati eseteket és fejlesztési ösztönzőket, amelyek arra késztették a fejlesztőket, hogy nagyon eltérő megközelítéseket alkalmazzanak ugyanarra a területre – a rendszerek közötti üzenetküldésre egy közbenső közvetítővel. Megvizsgáljuk ezeket a technológiákat az alapoktól, és kiemeljük a különböző tervezési döntések hatását az út során. Mélyen megérti mindkét terméket, megérti, hogyan kell őket használni és hogyan nem, és megérti, mire kell figyelnie, amikor más üzenetküldési technológiákat fontolgat a jövőben.

Mielőtt elkezdenénk, nézzük át az alapokat.

Mi az az üzenetküldő rendszer, és miért van rá szükség?

Ahhoz, hogy két alkalmazás kommunikálhasson egymással, először meg kell határozniuk egy interfészt. Ennek az interfésznek a meghatározása magában foglalja az átvitel vagy protokoll, például a HTTP, MQTT vagy SMTP kiválasztását, és a rendszerek között cserélendő üzenetformátumok egyeztetését. Ez lehet egy szigorú folyamat, például egy XML-séma meghatározása az üzenet hasznos terhelési költségére vonatkozó követelményekkel, de lehet, hogy sokkal kevésbé formális, például két fejlesztő megállapodása arról, hogy a HTTP-kérés bizonyos részei tartalmazni fogják az ügyfélazonosítót .

Mindaddig, amíg az üzenetek formátuma és küldési sorrendje konzisztens a rendszerek között, anélkül kommunikálhatnak egymással, hogy aggódnának a másik rendszer megvalósítása miatt. E rendszerek belső elemei, például a használt programozási nyelv vagy keretrendszer idővel változhatnak. Mindaddig, amíg magát a szerződést fenntartják, az interakció a másik oldal változása nélkül folytatódhat. A két rendszert ez az interfész hatékonyan leválasztja (elválasztja).

Az üzenetküldő rendszerek jellemzően egy közvetítőt foglalnak magukban két rendszer között, amelyek együttműködnek a küldő és a címzett vagy címzettek további szétválasztása (elválasztása) érdekében. Ebben az esetben az üzenetküldő rendszer lehetővé teszi a feladó számára, hogy anélkül küldjön üzenetet, hogy tudja, hol van a címzett, aktív-e, vagy hogy hány példánya van.

Nézzünk meg néhány analógiát az üzenetküldő rendszerek által megoldott problémákra, és mutassunk be néhány alapvető kifejezést.

Pontról pontra

Alexandra elmegy a postára, hogy küldjön egy csomagot Ádámnak. Az ablakhoz megy, és átadja az alkalmazottnak a csomagot. Az alkalmazott felveszi a csomagot, és átadja Alexandrának a nyugtát. Ádámnak nem kell otthon lennie, amikor elküldik a csomagot. Alexandra bízik benne, hogy a csomag a jövőben valamikor eljut Ádámhoz, és folytathatja a dolgát. Később Adam egy csomagot kap.

Ez egy példa az üzenetküldési modellre pontról pontra. A posta itt csomagelosztó mechanizmusként működik, biztosítva, hogy minden csomag egyszer kézbesítése megtörténjen. A postahivatal használata elválasztja a csomag feladását a csomag kézbesítésétől.
A klasszikus üzenetküldő rendszerekben a pont-pont modell keresztül valósul meg sorok. A sor FIFO (first in, first out) pufferként működik, amelyre egy vagy több fogyasztó is előfizethet. Minden üzenetet csak kézbesítünk az egyik előfizetett fogyasztóhoz. A sorok általában megpróbálják igazságosan elosztani az üzeneteket a fogyasztók között. Csak egy fogyasztó kapja meg ezt az üzenetet.

A „tartós” kifejezés a sorokra vonatkozik. Megbízhatóság egy szolgáltatástulajdonság, amely biztosítja, hogy az üzenetküldő rendszer megőrizze az üzeneteket aktív előfizetők hiányában mindaddig, amíg a fogyasztó fel nem iratkozik az üzenetkézbesítési sorra.

A megbízhatóságot gyakran összekeverik kitartás és bár a két kifejezést felcserélve használják, más-más funkciót töltenek be. A perzisztencia határozza meg, hogy az üzenetküldő rendszer ír-e üzenetet valamilyen tárolóra a fogadás és a fogyasztónak való elküldés között. A sorba küldött üzenetek lehetnek állandóak vagy nem.
Pont-pont üzenetküldés akkor használatos, ha a használati eset egyszeri műveletet igényel az üzeneten. Ilyen például az összeg befizetése egy számlára vagy a szállítási megrendelés teljesítése. Később megvitatjuk, hogy az üzenetküldő rendszer önmagában miért nem képes egyszeri kézbesítést biztosítani, és a sorok miért nyújthatnak a legjobb esetben is kézbesítési garanciát legalább egyszer.

Kiadó-előfizető

Gabriella tárcsázza a konferencia számát. Amíg csatlakozik a konferenciához, mindent hall, amit az előadó mond, a hívás többi résztvevőjével együtt. Amikor ráhangolódik, hiányzik neki, amit mondanak. Amikor újracsatlakozik, továbbra is hallja, amit mondanak.

Ez egy példa az üzenetküldési modellre közzé-előfizetés. A konferenciahívás sugárzási mechanizmusként működik. A beszélő személyt nem érdekli, hogy éppen hányan vesznek részt a hívásban – a rendszer biztosítja, hogy bárki, aki éppen csatlakozik, hallja, mit mondanak.
A klasszikus üzenetküldő rendszerekben a közzététel-előfizetés üzenetküldési modellt valósítják meg felsők. A Topic ugyanazt a sugárzási módszert kínálja, mint a konferencia-mechanizmus. Ha üzenetet küldenek egy témának, akkor azt szétosztják minden feliratkozott felhasználó számára.

A témák általában megbízhatatlan (nem tartós). Csakúgy, mint egy hallgató, aki nem hallja, mit mondanak a konferenciahívás során, amikor a hallgató megszakítja a kapcsolatot, a téma előfizetői lemaradnak az offline állapotban küldött üzenetekről. Emiatt kijelenthetjük, hogy a témák szállítási garanciát vállalnak legfeljebb egyszer minden fogyasztó számára.

A közzététel-előfizetés üzeneteket általában akkor használják, ha az üzenetek tájékoztató jellegűek, és egy üzenet elvesztése nem különösebben jelentős. Például egy témakör másodpercenként egyszer továbbíthatja a hőmérsékleti értékeket egy érzékelőcsoportról. Egy rendszer, amely érdeklődik az aktuális hőmérséklet iránt, és feliratkozik egy témára, nem fog aggódni, ha kihagy egy üzenetet – a közeljövőben érkezik egy másik.

hibrid modellek

Az áruház webhelye a rendelési üzeneteket "üzenetsorba" helyezi. Ezen üzenetek fő fogyasztója a végrehajtó rendszer. Ezenkívül az audit rendszernek rendelkeznie kell ezen rendelési üzenetek másolatával a későbbi nyomon követéshez. Mindkét rendszer nem engedheti át az üzeneteket, még akkor sem, ha maguk a rendszerek egy ideig nem elérhetők. A webhelynek nem szabad ismernie más rendszereket.

A használati esetek gyakran megkövetelik a közzététel-előfizetés és a pont-pont üzenetküldési modellek kombinációját, például amikor több rendszernek szüksége van egy üzenet másolatára, és mind a megbízhatóság, mind a tartósság szükséges az üzenetvesztés elkerüléséhez.

Ezekben az esetekben szükség van egy célállomásra (a sorok és témák általános kifejezése), amely alapvetően témaként osztja szét az üzeneteket, így minden üzenet egy különálló, az üzenetek iránt érdeklődő rendszerbe kerül, de az egyes rendszerek több fogyasztót is meghatározhatnak, akik fogadják a bejövő üzeneteket. üzeneteket, ami inkább egy sor. Az olvasás típusa ebben az esetben az minden érintett számára egyszer. Ezek a hibrid célállomások gyakran tartósságot igényelnek, így ha egy fogyasztó offline állapotba kerül, akkor az akkor elküldött üzenetek a fogyasztó újracsatlakozása után megérkeznek.

A hibrid modellek nem új keletűek, és a legtöbb üzenetküldő rendszerben használhatók, beleértve az ActiveMQ-t (a témákat és sorokat kombináló virtuális vagy összetett célhelyeken keresztül) és a Kafkát (a célállomás tervezésének alapvető tulajdonságaként).

Most, hogy rendelkezünk néhány alapvető terminológiával, és megértjük, mire használhatjuk az üzenetküldő rendszert, térjünk le a részletekre.

A fordítás elkészült: tele.gg/middle_java

A következő lefordított rész: 3. fejezet Kafka

Folytatás ...

Forrás: will.com

Hozzászólás