Hazelcast Pub/Sub

Le HazelcastPubSubEventStore fournit un magasin d'événements distribué pour socketio4j utilisant Hazelcast ITopic. Il permet une mise à l'échelle horizontale en diffusant les événements à travers les nœuds du cluster afin que les jointures/entrées et sorties de salles, les changements d'état, les accusés de réception et autres événements internes soient synchronisés entre plusieurs instances de serveur.

Caractéristiques principales

• Diffusion d'événements distribuée — tous les nœuds reçoivent tous les événements publiés

• Distribution asynchrone non bloquante — Hazelcast gère la livraison en dehors des boucles d'événements Netty

• Prise en charge d'un topic par type d'événement — permet la séparation multi-canaux des types d'événements

• Intégration simple — utilise les fonctionnalités de base de Hazelcast sans configuration de ring buffer

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

Comment ça marche

• Les événements sont publiés dans des instances Hazelcast ITopic (une ou plusieurs selon le mode)

• Chaque serveur abonné enregistre des listeners de messages Hazelcast pour la livraison des événements

• Les listeners locaux ne reçoivent que les événements d'origine externe (nodeId décalage)

• Les enregistrements de listeners sont suivis par type d'événement pour permettre un désabonnement et un arrêt contrôlés

Modes

Mode	Comportement	Quand l'utiliser
MULTI_CHANNEL	Chaque type d'événement correspond à son propre topic Hazelcast	Par défaut ; isole le trafic d'événements
SINGLE_CHANNEL	Tous les événements routés vers ALL_SINGLE_CHANNEL	Lorsque l'ordonnancement entre types est souhaité

Avantages

👍 Fonctionne dans des déploiements multi-nœuds 👍 Aucun broker supplémentaire requis si Hazelcast est déjà utilisé pour le clustering 👍 Facile à configurer et à intégrer 👍 Gestion propre du désabonnement et de l'arrêt 👍 Idéal pour les applications utilisant déjà Hazelcast pour l'état distribué

Limitations

ℹ️ Aucune persistance des messages au-delà du buffering du topic Hazelcast — les messages peuvent être perdus au redémarrage ℹ️ L'ordonnancement est par topic, pas global à tous les types d'événements ℹ️ Pas de rejouage historique — les listeners ne reçoivent que les messages après l'abonnement ℹ️ Livraison en double possible lors d'événements de basculement

Garantie de délivrance : Semantique au moins une fois — les listeners d'événements doivent être idempotents pour gérer en toute sécurité les messages dupliqués.