Speicherfabrik

Das StoreFactory definiert, wie socketio4j pro Sitzung Stores und geteilte Maps erstellt und verwaltet, und stellt gleichzeitig ein EventStore für die verteilte Ereignissynchronisation bereit. Speicherung und Ereignisweitergabe sind entkoppelt, wodurch jeder Daten-Store-Backend mit jedem kompatiblen Ereignisverteilungsmechanismus kombiniert werden kann.

Dies ermöglicht flexible Kombinationen wie:

• Speicher im Arbeitsspeicher + Kafka-basierte Ereignissynchronisation

• Redis-Speicher + NATS Pub/Sub

• Hazelcast-Speicher + Redis Streams

• Speicher im Arbeitsspeicher + keine Verteilung (MemoryEventStore) …oder jede andere deploymentspezifische Paarung.

Wesentliche Merkmale

• Erstellung von pro-Sitzungs-Stores — jede Client-Verbindung erhält ihren eigenen Datenspeicher

• Erstellung geteilter Maps — stellt benannte Maps für Namespaces, Adapter und Plugins bereit

• Exponierung des EventStore — liefert ein Ereignis-Backend, unabhängig von der Speicherwahl

• Komponierbares Design — Speicherung und Ereignisweitergabe können aus unterschiedlichen Systemen stammen

• Konfigurierbares Verhalten — tausche die Ereignisverteilung aus, ohne den Speicher zu ersetzen

Wie es funktioniert

• createStore(sessionId) → gibt ein sitzungsbezogenes zurück Store an das Speicher-Backend gebunden

• createMap(name) → gibt eine benannte, geteilte Map für den internen Sitzungsaustausch zurück

• eventStore() → gibt das konfigurierte zurück EventStore (Standard oder benutzerdefiniert)

• init(...) → bereitet Speicherung und Ereignissynchronisation vor dem Serverstart vor

• shutdown() → räumt während des Herunterfahrens zugewiesene Ressourcen auf

Mischen und Anpassen

Speicher-Backend (StoreFactory)	Ereignis-Backend (EventStore)	Gültig	Beispiel-Deployment
Arbeitsspeicher	Kafka	✔️	lokale Sitzungsdaten + globale Ereignisweitergabe
Redis	NATS	✔️	Redis-Maps + latenzarme Nachrichtenübermittlung
Hazelcast	Redis Streams	✔️	Hazelcast-Clustering + dauerhafte Stream-Synchronisation
Arbeitsspeicher	Arbeitsspeicher	✔️	Einzelknoten, keine Verteilung
Hazelcast	Kafka	✔️	Hazelcast-Sitzungsreplikation + Kafka-Synchronisation

Design-Zusammenfassung

• StoreFactory entscheidet wo pro-Sitzungs-Metadaten leben

• EventStore entscheidet wie Ereignisse über Server verteilt werden

• Beide sind unabhängig und austauschbar zur Laufzeit

Vorteile

👍 Hybride Deployments und schrittweise Migrationspfade 👍 Speicher- und Ereignisschichten können sich unabhängig weiterentwickeln 👍 Vermeidet Kopplung von verteilt gespeichertem Zustand mit Ereignistransport 👍 Funktioniert gleichermaßen für Einzelknoten- und Cluster-Setups