Redis-Stream

SocketIO4J verwendet den Redisson-Client, um eine Verbindung zu einem Redis-Server herzustellen. Alternative mit Redis kompatible Backends wie Valkey und DragonflyDB könnten ebenfalls unterstützt werden.

Das RedisStreamEventStore bietet einen verteilten, streamingbasierten Ereignisspeicher für socketio4j unter Verwendung von Redis Streams (XADD / XREAD). Es ermöglicht horizontale Skalierung, indem Ereignisse über mehrere Serverinstanzen synchronisiert werden, sodass interner Zustand, Raumzugehörigkeiten und andere verteilte Operationen über Knoten hinweg konsistent bleiben.

Redis Reliable Pub/Sub verwendet intern Streams für Persistenz, exponiert jedoch keine Offsets; Redis Streams stellt Offsets direkt zur Verfügung, was kontrolliertes Replay und Wiederherstellung des Verbindungszustands ermöglicht (für die Entwicklung geplant).

Wesentliche Merkmale

• Verteiltes Streaming — verwendet Redis Streams, um Ereignisse an alle aktiven Knoten zu liefern

• Fortlaufendes Ereignisreplay — speichert kürzliche Ereignisse in der Stream-Historie und ermöglicht kontrolliertes Replay

• Offset-Verfolgung pro Ereignistyp — jeder Ereignistyp verwaltet seinen eigenen zuletzt gesehenen StreamMessageId

• Streaming-Dispatch — Ereignisse werden asynchron verarbeitet, ohne die Netty-Event-Loops zu blockieren

• Duplikatvermeidung — von demselben Knoten erzeugte Ereignisse werden mit nodeId

Funktionsweise

• Jede Veröffentlichung führt ein XADD an einem Redis-Stream durch (ein einzelner Stream oder pro Typ, abhängig vom Modus)

• Jeder Ereignistyp verwaltet seinen eigenen Leseoffset mithilfe von StreamMessageId

• Das Polling wird in dedizierten, geplanten Executor-Threads pro Ereignistyp durchgeführt

• Bei jedem Lesen (XREAD) werden nur Nachrichten mit Offsets, die neuer sind als die zuletzt verarbeitete ID, verarbeitet

• Ereignisse werden Listenern nur zugestellt, wenn sie von einem anderen Knoten stammen

• Bei Fehlern oder Stream-Timeouts werden Wiederholungsversuche automatisch geplant

Modi

Modus	Verhalten	Wann zu verwenden
MULTI_CHANNEL	Separater Redis-Stream pro Ereignistyp	Standard; isoliert Ereignisverkehr und reduziert Konkurrenz
SINGLE_CHANNEL	Alle Ereignisse werden in ALL_SINGLE_CHANNEL	Wenn eine globale Reihenfolge aller Ereignistypen über Knoten hinweg erforderlich ist

Vorteile

👍 Funktioniert gut für Multi-Node-Bereitstellungen 👍 Nachrichten können je nach Stream-Länge vorübergehende Ausfallzeiten von Abonnenten überstehen 👍 Bietet offset-basierte Zustellung 👍 Unterstützt kontrolliertes Replay neuer Ereignisse nach Neustarts (Wiederherstellung des Verbindungszustands wird entwickelt, vorerst erhalten Sie die Nachrichten-Offset) 👍 Verwendet grundlegende Redis-Streams-Primitiven ohne externe Broker

Einschränkungen

ℹ️ Konsumenten verarbeiten Nachrichten unabhängig — die Reihenfolge gilt pro Stream, nicht global ℹ️ Potenzielle doppelte Zustellung bei Neustarts oder Offset-Grenzkonkurrenzen ℹ️ Erfordert Unterstützung für Redis Streams (nicht kompatibel mit dem Legacy-Redis-Pub/Sub-Modus)

Zustellgarantie: Mindestens-einmal-Semantik — Ereignis-Listener müssen idempotent sein, um mögliche doppelte Nachrichten zu verarbeiten.