nNATS Pub/Sub

Die NatsEventStore bietet einen Event-Store für socketio4j unter Verwendung von NATS Core Pub/Sub. Es ermöglicht die Ereignissynchronisation über mehrere Serverinstanzen, indem Nachrichten gesendet werden, aber Ereignisse sind ephemer und werden nicht gespeichert, wodurch es sich für leichte, latenzarme Bereitstellungen eignet, bei denen dauerhafte Wiedergabe nicht erforderlich ist.

Wesentliche Merkmale

  • Niedrige Latenz beim Broadcast — NATS Core liefert Nachrichten schnell an alle verbundenen Knoten

  • Ephemere Ereignisse — Nachrichten werden nicht gespeichert; Abonnenten erhalten Ereignisse nur, solange sie online sind

  • Asynchron und nicht blockierend — Dispatcher laufen außerhalb der Netty-Ereignisschleifen

  • Subject-pro-Event-Routing — Ereignistypen werden direkt auf Subjects abgebildet

  • Duplikatvermeidung — Ereignisse, die vom selben Knoten stammen, werden über nodeId

Funktionsweise

  • publish0 serialisiert das Ereignis und sendet es an ein NATS-Subject

  • subscribe0 registriert einen Dispatcher, der auf das relevante Subject hört

  • Nachrichten werden an Listener zugestellt nur wenn sie von einem anderen Knoten stammen

  • Unsubscribe räumt sowohl Subscriptions als auch Dispatcher auf

  • Shutdown entfernt alle aktiven Subscriptions, tut aber nicht die gemeinsame NATS-Verbindung schließen

Modi

Modus
Verhalten
Wann verwenden

MULTI_CHANNEL

Jeder Ereignistyp wird einem eigenen Subject zugewiesen

Standard; kleinere Subjects, bessere Trennung

SINGLE_CHANNEL

Alle Ereignisse werden an ALL_SINGLE_CHANNEL

Wenn eine einheitliche Reihenfolge über Ereignistypen erforderlich ist

Vorteile

👍 Ultra-niedrige Latenz bei der Zustellung 👍 Ideal, wenn Ereignisse nicht Dauerhaftigkeit oder Wiedergabe erfordern 👍 Sehr leichtgewichtig — minimale Abhängigkeiten und Konfiguration 👍 Gut geeignet, wenn NATS bereits für Messaging verwendet wird

Einschränkungen

ℹ️ Ereignisse werden nicht persistiert — verpasste Nachrichten können nicht wiedergegeben werden ℹ️ Abonnenten müssen verbunden sein, um Ereignisse zu empfangen ℹ️ Duplikate können bei Neuerstellung von Dispatchern oder Wiederverbindung auftreten ℹ️ Unterstützt keine Consumer-Offsets, Backpressure oder Stream-Trimming (dafür ist JetStream erforderlich, das derzeit geplant ist)

Zustellgarantie: At-most-once-Semantik. Best-Effort-Zustellung mit möglichem Nachrichtenverlust — Event-Listener sollten fehlende oder außer Reihenfolge auftretende Ereignisse tolerieren.

Zuletzt aktualisiert

War das hilfreich?