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