Ereignisspeicher

Die EventStore Schnittstelle definiert die verteilte Ereignissynchronisationsschicht von socketio4j. Sie bietet eine einheitliche Abstraktion zum Veröffentlichen und Abonnieren interner Ereignisse — wie Raumbeitritte, Verlassen, Bestätigungen, Sitzungsänderungen und Knoten-zu-Knoten-Synchronisation — über eine oder mehrere Serverinstanzen.

Wesentliche Merkmale

• Einheitliche Ereignis-API — dasselbe Publish-/Subscribe-Modell für alle Backends

• Typisierte Zustellung — Listener erhalten streng typisierte EventMessage Objekte

• Knotenbewusste Filterung — Implementierungen ignorieren typischerweise selbst erzeugte Ereignisse über nodeId

• Einsteckbare Transportschichten — Kafka, Redis Streams, Hazelcast, NATS, In-Memory-Fallback usw.

• Lebenszyklus-Steuerung — standardisierte publish, subscribe, unsubscribe, shutdown

Funktionsweise

• publish → backend-spezifisches Senden über publish0

• subscribe → Ereignis-Listener registrieren über subscribe0

• unsubscribe → Listener entfernen und Aufräumen über unsubscribe0

• shutdown → Freigabe von Backend-Ressourcen über shutdown0

• Implementierungen liefern Transportverhalten durch die *0 Methoden; die Schnittstelle standardisiert Ablauf und Fehlerbehandlung

Eigenschaften der Ereignisweiterleitung

Eigenschaft	Bedeutung
EventStoreMode	MULTI_CHANNEL (pro-Ereignis Streams/Topics) oder SINGLE_CHANNEL (einheitlicher Kanal)
EventStoreType	Deklariert die Transportfamilie: STREAM, PUBSUB, LOCAL, usw.
PublishMode	Beschreibt die erwartete Zuverlässigkeit: RELIABLE oder UNRELIABLE
nodeId	Identifiziert den Knoten; wird verwendet, um die erneute Verarbeitung lokaler Ereignisse zu vermeiden

Hinweis: getNodeId() liefert standardmäßig eine zufällige ID. Für verteilte Bereitstellungen konfigurieren Sie eine stabile Knotenidentität über StoreFactory.

Vorteile

👍 Verteilenede Transportschichten ohne Codeänderungen austauschbar 👍 Zentralisiertes Fehlerprotokoll und Flusssemantik 👍 Klare Erweiterungspunkte für benutzerdefinierte Backends 👍 Blendet Transportunterschiede aus

Einschränkungen

ℹ️ Zustellungsgarantien hängen von der Implementierung ab — werden nicht durch die Schnittstelle erzwungen ℹ️ Persistenz, Reihenfolge, Deduplizierung sind Aufgaben des Backends ℹ️ nodeIdAuf -Basis beruhende lokale Filterung muss eingehalten werden, um Duplikate zu vermeiden

---

Zustellungsgarantien

Die Die EventStore-Schnittstelle definiert keine Zustellungsgarantien. Zuverlässigkeit, Wiedergabe und Reihenfolge hängen vollständig vom gewählten Backend ab (z. B. Redis Streams = mindestens einmal; Redis Pub/Sub = Best-Effort; Kafka = mindestens einmal; Memory = nur lokal).