Üzenetbrókerek megértése. Az üzenetek cseréjének mechanikájának tanulmányozása az ActiveMQ és a Kafka segítségével. 1. fejezet

Mindenkinek szia!

Elkezdtem fordítani egy kisebb könyvet:
«Üzenetkezelő rendszerek megértése«,
szerző: Jakub Korab, kiadó: O’Reilly Media, Inc., kiadás dátuma: 2017 június, ISBN: 9781492049296.

A könyv bevezetőjéből:
«… Ez a könyv megtanít arra, hogy hogyan gondolkodj a brokers alapú üzenetkezelő rendszerekről, összehasonlítva és szembeállítva két népszerű broker technológiát: az Apache ActiveMQ-t és az Apache Kafkát. Példákat fogunk bemutatni és olyan fejlesztési ösztönzőket, amelyek eltérő megközelítésekhez vezettek a kommunikáció ezen területén — üzenetek közvetítésére rendszerek között egy köztes broker segítségével. Ezeket a technológiákat a nulláról fogjuk vizsgálni, és kiemeljük a különböző tervezési lehetőségek hatását ezen az úton. Mélyreható megértést fogsz kapni mindkét termékről, arról, hogy miként kell és nem kell őket használni, és arról is, hogy mire érdemes figyelni más üzenetkezelő technológiák vizsgálatakor a jövőben. …»

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

Ahogy haladok a fordítással, publikálni fogom a kész fejezeteket.

FEJEZET 1

Bevezetés

A rendszerek közti üzenetváltás az egyik legkevésbé megértett IT terület. Fejlesztőként vagy architektaként nagyon jól ismerheted a különböző keretrendszereket és adatbázisokat. Ugyanakkor valószínű, hogy csak felületes ismereteid vannak arról, hogyan működnek a broker alapú üzenetkezelő technológiák. Ha te is így érzed, ne aggódj, jó társaságban vagy.

Az emberek általában nagyon korlátozott mértékben érintkeznek az üzenetkezelő infrastruktúrával. Gyakran csatlakoznak egy régen létrehozott rendszerhez, vagy töltenek le egy disztribúciót az internetről, telepítik azt a PROM-ba, és elkezdenek alá kódot írni. Miután a PROM-ban elindították az infrastruktúrát, az eredmények vegyesek lehetnek: üzenetek elvesztése leállások esetén, az üzenetküldés nem működik úgy, ahogy elvártad, vagy a broker-ek „felfüggesztik” a producerjeidet, vagy nem küldenek üzeneteket a fogyasztóidnak.

Ismerősül hangzik?

Gyakori forgatókönyv, amikor a üzenetküldő kódod remekül működik egy ideig. Amíg egyszer csak meg nem áll. Ez az időszak álmossá teszi a figyelmet, és hamis biztonságérzetet ad, ami további kódhoz vezet, amely hamis elképzeléseken alapul a technológia alapvető viselkedéséről. Amikor valami elkezd nem stimmelni, szembesülsz a kellemetlen igazsággal: valójában nem értetted meg a termék alapvető viselkedését vagy az írók által választott kompromisszumokat, mint például a teljesítmény a megbízhatóság ellen, vagy a tranzakcionalitás a horizontális skálázhatóság ellen.

Mély megértés nélkül arról, hogyan működnek a brókerek, az emberek látszólag ésszerű állításokat tesznek üzenetküldő rendszereikről, mint például:

  • A rendszer soha nem veszít el üzeneteket
  • Az üzeneteket soronként dolgozzák fel
  • Fogyasztók hozzáadása gyorsabbá teszi a rendszert
  • Az üzeneteket csak egyszer fogják kézbesíteni

Sajnos ezek közül néhány állítás feltételezéseken alapul, amelyek csak bizonyos körülmények között érvényesek, míg mások egyszerűen tévesek.

Ez a könyv megtanít arra, hogy a brókerek alapú üzenetküldő rendszerekről gondolkodj, összehasonlítva és szembeállítva két népszerű bróker technológiát: az Apache ActiveMQ-t és az Apache Kafka-t. Itt esettanulmányokat és fejlesztési ösztönzőket ismertetünk, amelyek miatt a fejlesztők teljesen különböző megközelítéseket alkalmaztak ugyanarra a területre – az üzenetek közvetítésére a rendszerek között egy közvetítő bróker segítségével. Ezért ezeket a technológiákat nulláról fogjuk megvizsgálni, és kiemeljük a különböző tervezési lehetőségek hatását ezen az úton. Mély megértést nyújt mindkét termékről, megértve, hogyan kell és nem kell őket használni, valamint azt, hogy mire érdemes figyelni más üzenetküldő technológiák vizsgálatakor a jövőben.

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

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

Ahhoz, hogy két alkalmazás kommunikálhasson egymással, először meg kell határozniuk az interfészt. Ezen interfész definiálása magában foglalja a szállítás vagy protokoll kiválasztását, mint például a HTTP, MQTT vagy SMTP, valamint a rendszer által cserélt üzenetek formátumának összehangolását. Ez lehet szigorú folyamat, például egy XML séma meghatározása a payload üzenetre vonatkozó követelményekkel, vagy sokkal kevésbé formális, például két fejlesztő közötti megállapodás arról, hogy egy HTTP-kérés bizonyos része tartalmazni fogja az ügyfél azonosítóját.

Amíg az üzenetek formátuma és a küldés sorrendje a rendszerek között összehangolt, addig képesek lesznek egymással kölcsönhatásba lépni anélkül, hogy aggódniuk kellene a másik rendszer megvalósítása miatt. Ezeknek a rendszereknek a belső felépítése, mint például a programozási nyelv vagy a használt keretrendszer idővel változhat. Amíg a szerződés fennmarad, a kölcsönhatás változatlan maradhat a másik oldalról. Ezek a két rendszer hatékonyan el vannak választva (szétválasztva) ezzel az interfésszel.

A levelező rendszerek általában közvetítőt igényelnek a két kölcsönhatásban lévő rendszer között, amely lehetővé teszi a küldő és a címzett vagy címzettek közötti további szétválasztást. Ezzel a levelező rendszer lehetővé teszi a küldő számára, hogy üzenetet küldjön, anélkül hogy tudná, hol van a címzett, aktív-e, vagy hányszor van példány.

Tekintsünk meg néhány analógiát a levelezési rendszerek által megoldott problémák különböző típusairól, és vezessünk be néhány alapvető kifejezést.

Point-to-Point

Alexandra a postára megy, hogy Adamnak elküldjön egy csomagot. Odamegy az ablakhoz, és átadja az alkalmazottnak a csomagot. Az alkalmazott elveszi a csomagot, és átad Alexndrának egy nyugtát. Adamnek nem kell otthon lennie a csomag feladásának pillanatában. Alexandra biztos abban, hogy a csomag valamikor a jövőben Adamhoz fog érkezni, és folytathatja a teendőit. Később, valamikor Adam megkapja a csomagot.

Ez egy példa az üzenetek átadásának modelljére pont-pont. A posta itt a csomagok elosztó mechanizmusaként működik, biztosítva, hogy minden csomag egyszer kerüljenek átadásra. A posta használata elválasztja a csomag feladásának aktusát a csomag kézbesítésétől.
A klasszikus üzenetküldő rendszerekben a "pont-pont" modell megvalósítása történik sorrendben. A sorozat FIFO (first in, first out) pufferként működik, amelyre egy vagy több fogyasztó feliratkozhat. Minden üzenet csak egy feliratkozott fogyasztónak kerül kézbesítésre. A sorok általában arra törekednek, hogy méltányosan elosszák az üzeneteket a fogyasztók között. Csak egy fogyasztó kapja meg az adott üzenetet.

A sorokra a "megbízható" ("durable") kifejezés alkalmazható. Megbízhatóság Ez a szolgáltatás olyan tulajdonsága, amely garantálja, hogy az üzenetküldő rendszer megőrzi az üzeneteket aktív feliratkozók hiányában, amíg a fogyasztó fel nem iratkozik a sorra az üzenetek kézbesítésére.

A megbízhatóságot gyakran összekeverik a perzisztenciával , és bár e két kifejezés felcserélhető, eltérő funkciókat látnak el. A perzisztencia határozza meg, hogy az üzenet rögzítésre kerül-e az üzenetküldő rendszer által valamilyen tárolóban a fogyasztóhoz való eljuttatás előtt. A sorba küldött üzenetek lehetnek perzisztens vagy nem perzisztens.
A "pont-pont" típusú üzenetküldés akkor használatos, amikor a felhasználási eset egyetlen műveletet igényel az üzenettel. Egy példa lehet a pénzeszközök befizetése egy számlára vagy egy rendelés teljesítése. Később megvitatjuk, miért nem képes önállóan biztosítani az üzenetküldő rendszer az egyszeri kézbesítést, és hogy a sorok a legjobb esetben miért tudnak legalább egyszerű kézbesítést garantálni legalább egyszer.

Kiadó-Feliratkozó

Gabriella tárcsázza a konferenciát. Amíg csatlakozik a konferenciához, hallja, amit a szónok mond, a hívás többi résztvevőjével együtt. Amikor lecsatlakozik, kihagyja, ami elhangzik. Amikor újra csatlakozik, folytatja a hallgatást.

Ez egy példa az üzenetek átadásának modelljére kiadás-feliratkozás. A konferenciaszolgáltatás széles körű mechanizmusként működik. A beszélő nem törődik azzal, hány ember csatlakozott jelenleg a híváshoz — a rendszer garantálja, hogy bárki, aki jelenleg csatlakozik, hallani fogja, amit mondanak.
A klasszikus üzenetküldő rendszerekben a "kiadás-feliratkozás" üzenetküldési modell a témákon keresztül valósul megA téma ugyanazt a széles körű terjesztést biztosítja, mint a konferencia-hívás mechanizmusa. Amikor egy üzenetet küldenek a témába, az elosztódik minden feliratkozott felhasználónak..

A témák általában nem megbízhatóak (nondurable).Hasonlóan ahhoz, ahogy a hallgató nem hallja, amit a konferencia-híváson mondanak, amikor a hallgató lecsatlakozik, a téma feliratkozói elengednek minden üzenetet, ami abban az időben érkezik, amikor offline állapotban vannak. Emiatt elmondható, hogy a témák a kézbesítés garanciáját biztosítják legfeljebb egyszer minden felhasználó számára.

A publikálás-feliratkozás típusú üzenetváltásokat általában akkor használják, amikor az üzenetek tájékoztató jellegűek, és egy üzenet elvesztése nem különösebben jelentős. Például a téma egy másodpercenként továbbíthatja a hőmérséklet-adatait egy érzékelőcsoporttól. A rendszer, amely érdekli az aktuális hőmérsékletet, és amely feliratkozik a témára, nem fogja aggódni, ha elmulaszt egy üzenetet — egy másik hamarosan érkezik.

Hibrid modellek.

A bolt weboldala üzeneteket helyez el a "üzenetek sorában" a rendelésekről. Ezen üzenetek fő fogyasztója a végrehajtó rendszer. Emellett az auditáló rendszernek másolatokkal kell rendelkeznie ezekről a rendelési üzenetekről a későbbi nyomon követéshez. Mindkét rendszernek nem szabad elmulasztania az üzeneteket, még akkor sem, ha maguk a rendszerek ideiglenesen nem elérhetők. A weboldalnak nem szabad tudomást szereznie más rendszerekről.

A felhasználási forgatókönyvek gyakran megkövetelik a publikálás-feliratkozás és a pont-pont üzenetváltási modellek kombinálását, például amikor több rendszernek szüksége van egy üzenet másolatára, és az üzenet elvesztésének megakadályozásához mind megbízhatóságra, mind pedig tartósságra van szükség.

Ezekben az esetekben egy címzett (destination) szükséges (az üzenetsorok és témák általános kifejezése), amely működését főleg mint téma osztja el az üzeneteket, így minden egyes üzenet egy külön rendszerhez kerül, amely érdeklődik ezek iránt az üzenetek iránt, de mindegyik rendszer meghatározhat több fogyasztót is, akik megkapják a beérkező üzeneteket, ami inkább a sorhoz hasonlít. Itt az olvasási típus — egyszer minden érdekelt fél számára.Ezek a hibrid címzettek gyakran megbízhatóságot igényelnek, így ha a felhasználó megszakítja a kapcsolatot, az ilyenkor küldött üzenetek a felhasználó újbóli csatlakozása után érkeznek meg.

A hibrid modellek nem újak, és a legtöbb üzenetküldési rendszerben alkalmazhatók, beleértve az ActiveMQ-t (virtuális vagy összetett címzetteken keresztül, amelyek összekapcsolják a témákat és a sorokat), valamint a Kafkát (implicit, mint a címzeteinek alapvető terve).

Most, hogy van némi alapvető terminológiánk és megértésünk arról, hogy mire lehet szükségünk egy üzenetküldő rendszer kapcsán, térjünk át a részletekre.

Fordítás befejezve: tele.gg/middle_java

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

Folytatás következik…

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster