Hazelcast Ringpuffer

Die HazelcastPubSubRingBufferEventStore bietet einen verteilten Ereignisspeicher für socketio4j unter Verwendung von Hazelcast ReliableTopic / RingBuffer. Es ermöglicht horizontale Skalierung, indem Ereignisse über Clusterknoten verbreitet werden, sodass Zustandsänderungen, Beitritte, Verlassen, Bestätigungen und andere interne Ereignisse über mehrere Server hinweg synchronisiert werden.

Wesentliche Merkmale

• Verteilt & repliziert — Ereignisse werden über Hazelcast an jeden aktiven Clusterknoten geliefert

• Asynchrone & nicht blockierende Übermittlung — ReliableTopic übernimmt die Zustellung außerhalb der Netty-Event-Loops

• RingBuffer-gestützte Zuverlässigkeit — neuere Nachrichten überleben Knotenneustarts je nach Hazelcast-Konfiguration

• Streaming-Broadcast-Semantik — jeder Knoten erhält alle Ereignisse (nicht lastverteilt)

• Duplikatvermeidung — Ereignisse, die vom selben Knoten stammen, werden mit Hilfe von gefiltert nodeId

Funktionsweise

• Jede Veröffentlichung schreibt das Ereignis in ein Hazelcast ReliableTopic (einzelnes oder pro Typ je nach Modus)

• Abonnierte Ereignistypen hängen Nachrichten-Listener an den zugrundeliegenden RingBuffer

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

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

Modi

Modus	Verhalten	Wann verwenden
MULTI_CHANNEL	Jeder Ereignistyp erhält sein eigenes ReliableTopic	Standard; reduziert Konkurrenz und vermeidet Interferenzen zwischen Ereignissen
SINGLE_CHANNEL	Alle Ereignisse werden an ALL_SINGLE_CHANNEL	Wenn strikte Reihenfolge über alle Ereignistypen erforderlich ist

Vorteile

👍 Funktioniert in Multi-Knoten-Deployments 👍 Synchronisiert socketio4j-Server ohne externe Broker 👍 Verwendet Hazelcast-Primitiven für Clustering, keine Kafka-/Redis-Infrastruktur erforderlich 👍 Einfach zu konfigurieren, wenn Hazelcast bereits Teil des Systems ist

Einschränkungen

ℹ️ Die Kapazität des RingBuffers bestimmt, wie lange Nachrichten erhalten bleiben — Überlauf verwirft die ältesten Daten ℹ️ Keine transaktionale Zustellung oder Deduplizierung für genau-einmal-Semantik ℹ️ Zustellreihenfolge ist pro Partition / pro Topic, nicht global über Topics ℹ️ Cluster-Gesundheit oder Partition-Migrationen können vorübergehende doppelte Zustellung verursachen

Zustellgarantie: Mindestens-einmal-Semantik — Ereignis-Listener sollten idempotent sein, um Duplikate sicher zu verarbeiten.