Event sourcing: az eseménynapló mint igazság forrása
Célok
A lecke végére el tudod magyarázni, hogyan működik az event sourcing, mit ad, és milyen nehézségeket hoz, különösen a visszajátszás és a sémaváltozás terén.
Miért kell?
Egy hagyományos adattárban csak az aktuális állapot látszik: az, hogy egy érték hogyan jutott idáig, elvész. Ha az előzmény is fontos — mert ellenőrizni, visszajátszani vagy más nézetet építeni kell belőle —, érdemes az állapot helyett a változásokat tárolni.
Mi az event sourcing?
Martin Fowler leírása szerint az event sourcing az alkalmazás állapotának minden változását rendezett eseménysorozatként tárolja, és az aktuális állapot bármikor újra előállítható az események lejátszásával. A tartós eseménysor az elsődleges igazságforrás; a lekérdezésekhez használt „működő másolat” ebből származik.
flowchart LR
P["Parancs"] --> D["Szabályok"]
D -->|"új esemény"| L[("Eseménynapló")]
L -->|"lejátszás"| S["Aktuális állapot"]
L -->|"projekció"| R[("Olvasási nézet")]
Fontos megkülönböztetés: az event sourcing esetén az események az állapotot írják le (ez a tárolás módja), míg a 4.1 lecke event notificationje egy kommunikációs módszer. Egy rendszer használhat az egyiket a másik nélkül is.
Mit ad?
Fowler a következő előnyöket sorolja:
- Auditnapló: az események pontosan megmutatják, mi történt és milyen sorrendben.
- Újraépítés: az aktuális állapot eldobható és az eseményekből újraépíthető.
- Időbeli lekérdezés: az események egy adott pontig való lejátszásával az akkori állapot visszaállítható.
- Visszajátszás hiba javításához: ha egy esemény hibás volt vagy rossz sorrendben érkezett, a következmények újraszámíthatók.
- Tesztelés és hibakeresés: valós események lejátszhatók tesztkörnyezetben.
Milyen nehézségeket hoz?
Fowler szerint a legfontosabbak:
- Külső hatások: a külső rendszerek nem tudják, hogy valódi feldolgozás vagy visszajátszás történik; a hívásokat olyan átjárókon kell vezetni, amelyek visszajátszáskor kikapcsolhatók. Egy régi eseményből ezért nem szabad újra e-mailt vagy fizetést indítani.
- Külső lekérdezések: a visszajátszáskor az eseményhez az akkori adatra van szükség, nem a mostanira.
- Kódváltozás: egy hibajavítás újrafeldolgozást igényelhet; az időtől függő szabályokat a doménmodellben kell kezelni.
- Visszafordítás költsége: az eseménynek az előző értéket vagy a különbséget kell tárolnia.
- Sémaváltozás: az események hosszú ideig élnek, ezért a formátumuk változását kezelni kell. Fowler cikke ezt közvetlenül nem tárgyalja; a konkrét technikák ennek a leckének nem tárgyai.
Az esemény kiolvasása után az eseménynapló nem törlődik; a megőrzés a rendszer része. Ha az eseménynaplót teljes újraépítéshez használják, a megőrzést erre kell méretezni.
Szempontok szerint
| Szempont |
Event sourcing |
| Csatolás |
A napló sémája a rendszer legfontosabb szerződése |
| Adatkezelés |
Az események az igazság forrása; az olvasási nézetek származtatottak |
| Konzisztencia |
A nézetek késhetnek (végső konzisztencia) |
| Hibakezelés |
Visszajátszással javítható, de a mellékhatások veszélyesek |
| Költség |
Magas: új gondolkodásmód, séma- és megőrzési kérdések |
Gyakori tévhitek
| Állítás |
Pontosítás |
| „Az event sourcing azonos az üzenetküldéssel.” |
Az event sourcing állapottárolási mód; az üzenetküldés kommunikációs mód. |
| „Az esemény módosítható, ha hibás.” |
Az eseménynapló rendszerint hozzáfűzéses; a javítás újabb esemény vagy újrafeldolgozás. |
| „Az event sourcing mindig jobb, mert nincs adatvesztés.” |
Ára van: séma, visszajátszás, komplexitás. |
| „A visszajátszás ismét lefuttatja az eredeti hatásokat.” |
Csak ha így tervezték; külső hatásoknál ez hiba lenne. |
Röviden
- Az event sourcing az állapotváltozásokat eseményként tárolja; az eseménynapló az igazság forrása.
- Előnye: audit, újraépítés, időbeli lekérdezés, visszajátszás.
- Nehézsége: külső hatások, sémaváltozás, kódváltozás, költség.
- A visszajátszás és az üzleti reakció szerepét el kell választani.
Ellenőrző kérdések
- Miben különbözik az event sourcing az „értesítő” eseményektől (4.1)?
- Miért veszélyes a visszajátszás külső hatásokkal?
- Mit ad, és mit követel az eseménynapló?
Források
Event sourcing: az eseménynapló mint igazság forrása
Célok
A lecke végére el tudod magyarázni, hogyan működik az event sourcing, mit ad, és milyen nehézségeket hoz, különösen a visszajátszás és a sémaváltozás terén.
Miért kell?
Egy hagyományos adattárban csak az aktuális állapot látszik: az, hogy egy érték hogyan jutott idáig, elvész. Ha az előzmény is fontos — mert ellenőrizni, visszajátszani vagy más nézetet építeni kell belőle —, érdemes az állapot helyett a változásokat tárolni.
Mi az event sourcing?
Martin Fowler leírása szerint az event sourcing az alkalmazás állapotának minden változását rendezett eseménysorozatként tárolja, és az aktuális állapot bármikor újra előállítható az események lejátszásával. A tartós eseménysor az elsődleges igazságforrás; a lekérdezésekhez használt „működő másolat” ebből származik.
flowchart LR P["Parancs"] --> D["Szabályok"] D -->|"új esemény"| L[("Eseménynapló")] L -->|"lejátszás"| S["Aktuális állapot"] L -->|"projekció"| R[("Olvasási nézet")]Fontos megkülönböztetés: az event sourcing esetén az események az állapotot írják le (ez a tárolás módja), míg a 4.1 lecke event notificationje egy kommunikációs módszer. Egy rendszer használhat az egyiket a másik nélkül is.
Mit ad?
Fowler a következő előnyöket sorolja:
Milyen nehézségeket hoz?
Fowler szerint a legfontosabbak:
Az esemény kiolvasása után az eseménynapló nem törlődik; a megőrzés a rendszer része. Ha az eseménynaplót teljes újraépítéshez használják, a megőrzést erre kell méretezni.
Szempontok szerint
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források