Redis Reliable 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.
Die RedissonPubSubReliableEventStore bietet einen verteilten, wiederabspielbaren Ereignisspeicher für socketio4j unter Verwendung von Redis Reliable Topics, unterstützt durch Redis Streams. Es unterstützt die Synchronisation über mehrere Knoten mit optionalem Stream-Trimming zur Kontrolle des Speicherbedarfs, ermöglicht Dauerhaftigkeit über Serverneustarts hinweg und liefert Ereignisse dennoch nahezu in Echtzeit.
Redis Reliable Pub/Sub verwendet intern Streams zur Dauerhaftigkeit, legt jedoch keine Offsets offen; Redis Streams macht Offsets direkt zugänglich und ermöglicht so kontrollierte Wiedergabe und eine Wiederherstellungsfunktion für Verbindungszustände (in Planung).
Wesentliche Merkmale
Zuverlässige Zustellung via Redis Streams — behält kürzlich gesendete Nachrichten für kontrolliertes Replay
Stream-gestützte Topics —
RReliableTopicstellt sicher, dass Nachrichten persistiert und an spät beitretende Abonnenten geliefert werdenOptionales Auto-Trimming — verhindert unbegrenztes Stream-Wachstum durch geplantes
XTRIMAsynchrone Zustellung — Zustellungs-Callbacks erfolgen außerhalb der Netty-Event-Loops
Duplikatvermeidung — filtert selbst erzeugte Ereignisse über
nodeId
Funktionsweise
publish0schreibt Ereignisse in ein zuverlässiges Topic, das intern an einen Redis-Stream anhängtsubscribe0registriert einen Listener am zuverlässigen Topic; Ereignisse werden aus dem zugrunde liegenden Stream gezogen, sogar nach einer WiederverbindungStream-Einträge werden periodisch basierend auf
streamMaxLengthundtrimEveryDas Trimmen wird asynchron in einem Daemon-Thread durchgeführt, um blockierende I/O zu vermeiden
Stream-Metadaten (
activePubTopics,activeSubTopics,trimTopics) werden pro Ereignistyp nachverfolgt
Modi
MULTI_CHANNEL
Pro-Ereignistyp-Streams + zuverlässige Topics
Standard; isoliert den Traffic und bewahrt die Reihenfolge pro Ereignistyp
SINGLE_CHANNEL
Alle Ereignisse werden an einen einzigen zuverlässigen Stream geleitet
Wenn strikte globale Reihenfolge erforderlich ist
Vorteile
👍 Nachrichten im Redis-Stream persistiert — wiederherstellbar bis zu den Trim-Grenzen 👍 Geeignet für Multi-Node-Synchronisation mit Dauerhaftigkeit 👍 Optionales Trimmen verhindert unbegrenzte Speicherverwendung 👍 Kann kürzlich gesendete Nachrichten nach Wiederverbindungen wiedergeben (innerhalb des getrimmten Bereichs) 👍 Bekanntes Redis-Deployment-Modell, kein Kafka/NATS erforderlich
Einschränkungen
ℹ️ Nicht vollständig genau-einmal — Duplikate können nach Neustart oder Wiederverbindungen auftreten ℹ️ Reihenfolge ist pro Stream — Cross-Event-Reihenfolge erfordert den Single-Channel-Modus ℹ️ Erfordert Redis Streams-Unterstützung (Redis 5+) ℹ️ Die Zuverlässigkeit hängt von der Konfiguration der Stream-Retention und der Trimming-Strategie ab
Zustellgarantie: Mindestens-einmal-Semantik — Listener müssen idempotent sein, um mögliche doppelte Zustellungen zu verarbeiten.
Zuletzt aktualisiert
War das hilfreich?