Redis Pub/Sub

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

Das RedissonPubSubEventStore bietet einen Event-Store für socketio4j unter Verwendung von Redis Pub/Sub. Es ermöglicht grundlegendes Weiterleiten von Events zwischen Serverinstanzen durch das Senden von Nachrichten über Redis-Kanäle, wodurch verteilte Raum-Operationen und interne Synchronisation möglich werden — jedoch ohne Dauerhaftigkeits- oder Wiedergabegarantie.

Wesentliche Merkmale

• Ephemeres Broadcast-Messaging — Events werden nur an aktuell verbundene Abonnenten zugestellt

• Asynchrone Listener-Callbacks — Die Redis Pub/Sub-Weiterleitung läuft außerhalb der Netty-Event-Loops

• Leichtgewichtige Multi-Node-Synchronisation — minimale Konfiguration, wenn Redis bereits vorhanden ist

• Subject-pro-Event-Routing — Ereignistypen werden direkt auf Pub/Sub-Kanäle abgebildet

• Duplikatvermeidung — filtert Ereignisse heraus, die vom selben Knoten stammen (nodeId)

Wie es funktioniert

• publish0 sendet das Event an einen Redis Pub/Sub-Kanal basierend auf dem Ereignistyp

• subscribe0 registriert einen typensicheren Listener auf dem entsprechenden Kanal

• Zustellung ist nur Push — Abonnenten müssen online sein, um Nachrichten zu empfangen

• Beim Abbestellen oder Herunterfahren werden Themen-Listener entfernt, aber die Redis-Clients bleiben geöffnet

Modi

Modus	Verhalten	Wann zu verwenden
MULTI_CHANNEL	Jedes Event wird einem eigenen Pub/Sub-Kanal zugeordnet	Standard; reduziert Event-Interferenzen
SINGLE_CHANNEL	Alle Events werden weitergeleitet an ALL_SINGLE_CHANNEL	Wenn eine vollständige Reihenfolge aller Ereignistypen gewünscht ist

Vorteile

👍 Extrem einfach zu konfigurieren 👍 Kein Persistenz-Overhead — reine Broadcast-Semantik 👍 Ideal für Redis-zentrierte Deployments oder Prototypen 👍 Funktioniert sofort für grundlegende Multi-Node-Kommunikation

Einschränkungen

ℹ️ Ereignisse werden nicht persistiert — Abonnenten verpassen Ereignisse während der Trennung ℹ️ Kein Replay-Mechanismus — wiederverbundene Knoten starten ab „jetzt" ℹ️ Duplikate möglich während der Wiederverbindung ℹ️ Reihenfolge gilt nur pro Kanal; globale Reihenfolge erfordert SINGLE_CHANNEL Modus

Zustellgarantie: At-most-once-Semantik. Best-Effort, ephemere Zustellung — Listener müssen Nachrichtenverlust und Auslieferung außerhalb der Reihenfolge tolerieren.