1. Közzététel-előfizetés

  • A Pub/Sub (vagy Publish/Subscribe) egy architekturális "tervezési minta", amelyet elosztott rendszerekben használnak a különböző összetevők vagy szolgáltatások közötti aszinkron kommunikációra.
  • Ennek kulcsa az, hogy a Pub/Sub lehetővé teszi az üzenetek mozgását a rendszer különböző komponensei között anélkül, hogy a komponensek tudatában lennének egymás kilétének (lekapcsolódnak).
  • A Pub/Sub keretet biztosít a kiadók (üzeneteket létrehozó és küldő komponensek) és az előfizetők (üzeneteket fogadó és fogyasztó komponensek) közötti üzenetcseréhez.

2. Napló összesítés

  • Nagy mennyiségű napló strukturált esemény kezelése, amelyeket jellemzően az alkalmazások vagy az infrastruktúra összetevői bocsátanak ki. A naplók olyan sorozatfelvételi sebességgel állíthatók elő, amely jelentősen meghaladja az adatbázisok azon képességét, hogy lépést tartsanak a naplófeldolgozással és az indexeléssel, ami általában „drága” művelet.
  • A Kafka pufferként működhet, köztes, tartós adattárolót kínálva. A feldolgozási folyamat elnyelőként fog működni, és végül a naplókat egy olvasásra optimalizált adatbázisba rendezi (például "Elasticsearch").
  • A naplóösszesítési folyamat tartalmazhat közbenső lépéseket is, például a naplók kanonikus formába történő normalizálására vagy a naplók fertőtlenítésére – megtisztítva őket a személyazonosításra alkalmas adatoktól.

3. Napló szállítás

  • Jóllehet a rönkök összesítéséhez hasonlóan hangzik, a rönkök szállítása merőben más fogalom. Ez lényegében a naplóbejegyzések valós idejű másolását jelenti egy fő rendszerből egy vagy több replikába.
  • Feltételezve, hogy a szakaszban bekövetkezett változásokat teljes mértékben rögzítik a naplórekordok, ezeknek a rekordoknak az újrajátszása lehetővé teszi, hogy a replikák pontosan utánozzák a fő állapotát, bár némi késéssel.

4. Staged Event-Driven Architecture (SEDA) csővezetékek

  • A Stage Event-Driven Architecture (SEDA) „folyamatkezelést” alkalmaz az eseményorientált adatokra. Az események egyirányban haladnak át a témakörök által összekapcsolt feldolgozási szakaszok sorozatán, amelyek mindegyike leképezési műveletet hajt végre, mielőtt egy átalakított eseményt közzétenne a következő témakörben.
  • A közbülső fokozatok egyszerre működnek fogyasztóként és termelőként, és önállóan és egymástól függetlenül skálázhatnak egyedi terhelési igényeiknek megfelelően. Egy összetett probléma szakaszokra bontásával a SEDA javítja a rendszer modularitását. Mint például, a SEDA könnyen megtalálható az adattárházakban, az adattókban, a jelentéskészítésben, az analitikában és más üzleti intelligencia alkalmazásokban, és gyakran a Big Data alkalmazások eleme.

5. Komplex eseményfeldolgozás (CEP)

  • A Complex Event Processing (CEP) értelmes információkat és mintákat bont ki különálló események folyamában vagy diszjunkt eseményfolyamok halmazában.
  • A CEP processzorok általában állapotfüggőek, mivel képesnek kell lenniük a korábbi események hatékony visszahívására, hogy azonosítsák azokat a mintákat, amelyek a kontextustól függően ezredmásodpercektől napokig terjedhetnek széles időkereten keresztül.
  • A CEP-et széles körben alkalmazzák olyan alkalmazásokban, mint az algoritmikus tőzsdei kereskedés, a biztonsági fenyegetéselemzés, a valós idejű csalásészlelés és az ellenőrző rendszerek.

6. Eseményforrás – CQRS

  • A CQRS messze a legelterjedtebb módja annak, hogy az eseménybeszerzés valós alkalmazásokban valósuljon meg. A CQRS rendszernek mindig két oldala van, egy írási és egy olvasási oldal:
  • Az írási oldalon (a diagram bal oldalán látható) parancsokat vagy eseményeket küld, amelyek megbízhatóan tárolódnak. Az olvasási oldalon (amely a diagram jobb oldalán látható) az adatok lekérésére szolgáló lekérdezések futtatása. (Ha Apache Kafkát használ, ez biztosítja a két oldal elkülönítését.) Tehát a vanília eseményforrástól eltérően a CQRS-ben az eseményformátum és a táblázatformátum közötti fordítás írási időben történik, bár aszinkron módon.
  • Az olvasás és az írás elválasztásának van néhány figyelemre méltó előnye: az eseményszintű tárolás előnyeit élvezheti, de sokkal nagyobb teljesítményt is élvezhet, mivel az írási és olvasási rétegek szét vannak választva. Természetesen van egy kompromisszum is: a rendszer végül konzisztenssé válik, így előfordulhat, hogy az olvasás nem lehetséges azonnal az esemény megírása után. Ezt a rendszer tervezésénél figyelembe kell venni.

Ha pedig összefoglaló cikkeket keres az Apache Kafkáról, akkor megtekintheti korábbi cikkeimet is, például: A Kafka alapfogalmai és kulcsfontosságú elvei, Témanapló tömörítése Apache-ban Kafka, Kafka – az adatok tartóssági és elérhetőségi garanciái és Miért gyors az Apache Kafka?

Ne felejtsd el megnyomni a Taps és Kövesd gombokat, hogy segítsenek még több ehhez hasonló cikket írni.

Referenciák