Tampon circulaire Hazelcast

Le HazelcastPubSubRingBufferEventStore fournit un magasin d'événements distribué pour socketio4j utilisant Hazelcast ReliableTopic / RingBuffer. Il permet la mise à l'échelle horizontale en diffusant des événements entre les nœuds du cluster afin que les changements d'état, les connexions, les déconnexions, les accusés de réception et autres événements internes soient synchronisés entre plusieurs serveurs.

Caractéristiques principales

• Distribué et répliqué — les événements sont livrés à chaque nœud actif du cluster via Hazelcast

• Envoi asynchrone et non bloquant — ReliableTopic gère la livraison en dehors des boucles d'événements Netty

• Fiabilité basée sur RingBuffer — les messages récents survivent aux redémarrages de nœuds selon la configuration Hazelcast

• Sémantique de diffusion en streaming — chaque nœud reçoit tous les événements (pas d'équilibrage de charge)

• Prévention des doublons — les événements provenant du même nœud sont filtrés en utilisant nodeId

Comment ça marche

• Chaque publication écrit l'événement dans un Hazelcast ReliableTopic (unique ou par type selon le mode)

• Les types d'événements abonnés attachent des écouteurs de message au ring buffer sous-jacent

• Les messages sont livrés aux écouteurs locaux uniquement s'ils proviennent d'un nœud différent

• Les enregistrements d'écouteurs sont suivis par type d'événement pour permettre une désinscription et un arrêt propres

Modes

Mode	Comportement	Quand l'utiliser
MULTI_CHANNEL	Chaque type d'événement reçoit son propre ReliableTopic	Par défaut ; réduit la contention et évite les interférences entre événements
SINGLE_CHANNEL	Tous les événements routés vers ALL_SINGLE_CHANNEL	Lorsque l'ordre strict entre tous les types d'événements est requis

Avantages

👍 Fonctionne dans des déploiements multi-nœuds 👍 Synchronise les serveurs socketio4j sans brokers externes 👍 Utilise les primitives Hazelcast pour le clustering, aucune infrastructure Kafka/Redis requise 👍 Simple à configurer lorsque Hazelcast fait déjà partie du système

Limitations

ℹ️ La capacité du RingBuffer détermine la durée de conservation des messages — le débordement supprime les données les plus anciennes ℹ️ Pas de livraison transactionnelle ni de déduplication pour une sémantique exactly-once ℹ️ L'ordre de livraison est par partition / par topic, pas global entre les topics ℹ️ La santé du cluster ou les migrations de partition peuvent provoquer des livraisons dupliquées temporaires

Garantie de délivrance : Sémantique au moins une fois — les écouteurs d'événements doivent être idempotents pour gérer les duplicatas en toute sécurité.