Üzenetsor, publish–subscribe és eseménynapló

Célok

A lecke végére meg tudod különböztetni a munkasort, a publish–subscribe modellt és a tartós eseménynaplót kézbesítés és megőrzés szerint, és a hét szempont mentén jellemezni tudod őket.

Miért kell?

Aszinkron szolgáltatáskapcsolatban a küldő üzenetet bocsát ki, a fogyasztó később dolgozza fel. A közöttük levő közvetítő (broker) az átvitelt, tárolást és kézbesítést szervezi. Három alapmodell létezik, és a különbségük a kézbesítésben és a megőrzésben van, nem a terméknévben.

Üzenetsor (munkasor)

Az Azure „competing consumers” (versengő fogyasztók) mintája szerint az alkalmazás a kéréseket üzenetként teszi sorba, és több fogyasztópéldány veszi ki őket; minden üzenetet egy fogyasztó kap meg. Így a sor pufferként is működik a változó terhelés és a feldolgozás között (queue-based load leveling), és az üzenetek legalább egyszer kézbesítődnek.

Publish–subscribe

Az Azure megkülönböztetése szerint a versengő fogyasztóknál egy fogyasztó kapja meg az üzenetet, a publish–subscribe modellben pedig minden előfizetett fogyasztó megkapja minden üzenetet. Így egy tényt (például „kiállítottak egy számlát”) több önálló fogyasztó is megkaphat, és mindegyik a saját felelősségéhez tartozó eredményt állítja elő. Az előfizetésnek önálló feldolgozási állapota van; ugyanazon előfizetés több példánya általában megosztja a munkát, a másik előfizetés függetlenül megkapja ugyanazt a tényt.

flowchart LR
  P["Termelő"] --> T["Téma (topic)"]
  T --> S1["Előfizetés 1"]
  T --> S2["Előfizetés 2"]
  S1 --> W1["Fogyasztó A (több példány)"]
  S2 --> W2["Fogyasztó B"]

Tartós eseménynapló

A Kafka bemutatója szerint az esemény rögzíti, hogy „valami történt”; a termelők és a fogyasztók teljesen különállnak. A téma (topic) több termelőt és több feliratkozót is kiszolgál, partíciókra oszlik, és az azonos kulcsú események ugyanabba a partícióba kerülnek; a fogyasztó egy partíció eseményeit pontosan a megírás sorrendjében olvassa. Az esemény kiolvasás után nem törlődik: a megőrzés témánként állítható, a régi események az idő letelte után törlődnek. Így a naplót a fogyasztó újraolvashatja, és saját pozícióját követi; több fogyasztói csoport függetlenül haladhat ugyanazon az adatfolyamon.

A queue és a log különbségét ne terméknév alapján értelmezzük: a kézbesítési modell, a megőrzés, a pozíciókezelés és a visszajátszás a fontos. Egy infrastruktúra többféle mintát támogathat.

Összehasonlítás

Szempont	Munkasor	Pub/sub	Eseménynapló
Irány	Egyirányú: termelő → fogyasztó	Egyirányú: termelő → többen	Egyirányú: termelő → többen, újraolvashatóan
Kezdeményező	A termelő küld; a fogyasztó kivesz	A termelő	A termelő ír; a fogyasztó a saját ütemében olvas
Kapcsolat tartóssága	Nincs közvetlen kapcsolat; a közvetítő köztes	Ugyanaz	Ugyanaz
Késleltetés	A sor hosszától és a fogyasztóktól függ	A legkésőbb fogyasztóé számít feldolgozás szempontjából	Pozíció szerinti, lehet késő olvasás
Terhelés	A sor pufferel; a hossz nőhet	Előfizetésenként feldolgozás	A megőrzés tárhelyet igényel
Hibatűrés	Nem nyugtázott üzenet újrakézbesül	Előfizetésenként saját állapot	A fogyasztó pozíciója alapján folytatható
Mikor jó?	Munka elosztása, terheléskiegyenlítés	Egy tény több önálló reakciója	Visszajátszás, új fogyasztó utólagos felzárkózása, nézet újraépítése
Mikor nem?	Ha minden fogyasztónak kell az üzenet	Ha azonnali válasz kell a hívónak	Ha a megőrzés felesleges vagy költséges

Az eseményszerződés

Az eseménynek legyen stabil típusa, azonosítója, sémaverziója és üzleti jelentése. Az időbélyeg nem garantál globális sorrendet. A tény tartalmazhat elegendő adatot a fogyasztóhoz, vagy csak azonosítót, amelyből lekérdezés kell (4.4). Az esemény nem a belső adatbázis nyilvános másolata.

Gyakori tévhitek

Állítás	Pontosítás
„A queue és a pub/sub ugyanaz.”	Az egyik egy fogyasztóhoz, a másik minden előfizetőhöz juttat.
„Az üzenetsorban minden üzenet pontosan egyszer dolgozódik fel.”	Legalább egyszeri kézbesítés a jellemző (8.2).
„A napló olvasás után törlődik.”	A megőrzési idő szerint marad (Kafka).
„Az üzenetsor végtelen kapacitás.”	Ha az érkezés tartósan meghaladja a feldolgozást, a sor nő (8.4).

Röviden

• A munkasorban egy üzenetet egy fogyasztó kap; a pub/sub minden előfizetőnek juttat.
• A tartós napló az eseményeket megőrzi, a fogyasztó saját pozíciót követ.
• A modell kiválasztása a megőrzés, a kézbesítés és a visszajátszás igénye alapján történik.
• Az eseményszerződés közös függőség.

Ellenőrző kérdések

1. Mi a különbség a versengő fogyasztók és a pub/sub között?
2. Miben tér el a tartós napló a munkasortól a megőrzés szempontjából?
3. Mikor választanál naplót sor helyett?

Források

• Competing Consumers pattern (Azure Architecture Center)
• Queue-Based Load Leveling pattern (Azure Architecture Center)
• Apache Kafka: Introduction — esemény, téma, partíció, megőrzés.