Hazelcast Pub/Sub

Die HazelcastPubSubEventStore bietet einen verteilten Ereignisspeicher für socketio4j unter Verwendung von Hazelcast ITopic. Es ermöglicht horizontale Skalierung, indem Ereignisse über Cluster-Knoten ausgestrahlt werden, sodass Raumbeitritte, -verlassen, Zustandsänderungen, Bestätigungen und andere interne Ereignisse zwischen mehreren Serverinstanzen synchronisiert werden.

Wesentliche Merkmale

• Verteilte Ereignisverbreitung — alle Knoten erhalten alle veröffentlichten Ereignisse

• Asynchrone nicht-blockierende Zustellung — Hazelcast verwaltet die Zustellung außerhalb der Netty-Ereignisschleifen

• Topic-pro-Ereignis-Unterstützung — ermöglicht mehrkanalige Trennung von Ereignistypen

• Einfache Integration — verwendet Kernfunktionen von Hazelcast ohne Konfiguration eines Ringpuffers

• Duplikatvermeidung — Ereignisse vom selben Knoten werden mithilfe von nodeId Filterung

Funktionsweise

• Ereignisse werden in Hazelcast ITopic-Instanzen veröffentlicht (eine oder mehrere, abhängig vom Modus)

• Jeder abonnierte Server registriert Hazelcast-Nachrichtenlistener für die Ereigniszustellung

• Lokale Listener erhalten nur extern erzeugte Ereignisse (nodeId Nichtübereinstimmung)

• Listener-Registrierungen werden pro Ereignistyp verfolgt, um kontrolliertes Abbestellen und Herunterfahren zu ermöglichen

Modi

Modus	Verhalten	Wann verwenden
MULTI_CHANNEL	Jeder Ereignistyp wird einem eigenen Hazelcast-Topic zugeordnet	Standard; isoliert Ereignisverkehr
SINGLE_CHANNEL	Alle Ereignisse werden an ALL_SINGLE_CHANNEL	Wenn eine Reihenfolge über Typen hinweg gewünscht ist

Vorteile

👍 Funktioniert in Multi-Knoten-Deployments 👍 Keine zusätzlichen Broker erforderlich, wenn Hazelcast bereits für Clustering verwendet wird 👍 Einfach zu konfigurieren und zu integrieren 👍 Sauberes Abbestellen und Herunterfahren 👍 Ideal für Anwendungen, die Hazelcast bereits für verteilten Zustand nutzen

Einschränkungen

ℹ️ Keine Nachrichtenpersistenz über das Hazelcast-Topic-Puffern hinaus — Nachrichten können beim Neustart verloren gehen ℹ️ Reihenfolge gilt pro Topic, nicht global über alle Ereignistypen ℹ️ Kein historisches Replay — Listener erhalten nur Nachrichten nach der Subscription ℹ️ Doppelte Zustellung möglich bei Failover-Ereignissen

Zustellgarantie: Mindestens-einmal-Semantik — Ereignislistener müssen idempotent sein, um doppelte Nachrichten sicher verarbeiten zu können.