rRedis Reliable Pub/Sub

circle-info

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 TopicsRReliableTopic stellt sicher, dass Nachrichten persistiert und an spät beitretende Abonnenten geliefert werden

  • Optionales Auto-Trimming — verhindert unbegrenztes Stream-Wachstum durch geplantes XTRIM

  • Asynchrone Zustellung — Zustellungs-Callbacks erfolgen außerhalb der Netty-Event-Loops

  • Duplikatvermeidung — filtert selbst erzeugte Ereignisse über nodeId

Funktionsweise

  • publish0 schreibt Ereignisse in ein zuverlässiges Topic, das intern an einen Redis-Stream anhängt

  • subscribe0 registriert einen Listener am zuverlässigen Topic; Ereignisse werden aus dem zugrunde liegenden Stream gezogen, sogar nach einer Wiederverbindung

  • Stream-Einträge werden periodisch basierend auf streamMaxLength und trimEvery

  • Das 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

Modus
Verhalten
Wann verwenden

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?