Redis Pub/Sub

SocketIO4J utilise le client Redisson pour se connecter à un serveur Redis. D'autres backends compatibles Redis tels que Valkey et DragonflyDB peuvent également être pris en charge.

Le RedissonPubSubEventStore fournit un magasin d'événements pour socketio4j en utilisant Redis Pub/Sub. Il permet le transfert d'événements de base entre instances de serveur en diffusant des messages sur des canaux Redis, permettant des opérations de salle distribuées et la synchronisation interne — mais sans garanties de durabilité ou de relecture.

Caractéristiques clés

• Messagerie de diffusion éphémère — les événements sont livrés uniquement aux abonnés actuellement connectés

• Rappels d'écoute asynchrones — la distribution Redis Pub/Sub s'exécute en dehors des boucles d'événements Netty

• Synchronisation légère multi-nœuds — configuration minimale lorsque Redis est déjà présent

• Routage par sujet par événement — les types d'événements correspondent directement aux canaux Pub/Sub

• Prévention des doublons — filtre les événements provenant du même nœud (nodeId)

Comment ça fonctionne

• publish0 envoie l'événement à un canal Redis Pub/Sub basé sur le type d'événement

• subscribe0 enregistre un écouteur typé sur le canal correspondant

• La livraison est uniquement par push — les abonnés doivent être en ligne pour recevoir les messages

• Lors de la désinscription ou de l'arrêt, les écouteurs de sujet sont supprimés mais les clients Redis restent ouverts

Modes

Mode	Comportement	Quand l'utiliser
MULTI_CHANNEL	Chaque événement correspond à son propre canal Pub/Sub	Par défaut ; réduit les interférences entre événements
SINGLE_CHANNEL	Tous les événements routés vers ALL_SINGLE_CHANNEL	Lorsque l'on souhaite un ordonnancement complet de tous les types d'événements

Avantages

👍 Extrêmement simple à configurer 👍 Aucun overhead de persistance — sémantique pure de diffusion 👍 Idéal pour des déploiements centrés sur Redis ou des prototypes 👍 Fonctionne immédiatement pour la communication multi-nœuds de base

Limitations

ℹ️ Les événements sont non persistés — les abonnés manquent des événements lorsqu'ils sont déconnectés ℹ️ Pas de mécanisme de relecture — les nœuds qui se reconnectent repartent de « maintenant » ℹ️ Des messages en double sont possibles lors de la reconnexion ℹ️ L'ordonnancement ne s'applique que par canal ; un ordonnancement global nécessite SINGLE_CHANNEL le mode

Garantie de livraison : Semantique au plus une fois. Livraison au mieux, éphémère — les écouteurs doivent tolérer la perte de messages et la livraison hors d'ordre.