Flux Redis

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

Le RedisStreamEventStore fournit un magasin d'événements distribué et en streaming pour socketio4j en utilisant Redis Streams (XADD / XREAD). Il permet une mise à l'échelle horizontale en synchronisant les événements entre plusieurs instances de serveur afin que l'état interne, l'appartenance aux salons et autres opérations distribuées restent cohérents entre les nœuds.

Le Pub/Sub fiable de Redis utilise les Streams en interne pour la durabilité, mais n'expose pas les offsets ; Redis Streams expose directement les offsets, permettant la lecture contrôlée et la récupération de l'état de connexion (fonctionnalité prévue pour le développement).

Caractéristiques clés

• Streaming distribué — utilise Redis Streams pour livrer les événements à tous les nœuds actifs

• Continuité de la relecture d'événements — stocke les événements récents dans l'historique du stream, permettant une relecture contrôlée

• Suivi des offsets par type d'événement — chaque type d'événement maintient son propre dernier StreamMessageId

• Diffusion en streaming — les événements sont traités de manière asynchrone sans bloquer les boucles d'événements Netty

• Prévention des doublons — les événements produits par le même nœud sont filtrés avec nodeId

Comment ça fonctionne

• Chaque publication effectue XADD vers un stream Redis (unique ou par type selon le mode)

• Chaque type d'événement maintient son propre offset de lecture en utilisant StreamMessageId

• Le sondage est effectué dans des threads d'exécution planifiés dédiés par type d'événement

• Pour chaque lecture (XREAD), seuls les messages avec des offsets plus récents que le dernier identifiant traité sont pris en charge

• Les événements sont livrés aux écouteurs uniquement s'ils provenaient d'un autre nœud

• En cas d'erreurs ou de délais d'attente du stream, des tentatives sont planifiées automatiquement

Modes

Mode	Comportement	Quand l'utiliser
MULTI_CHANNEL	Stream Redis séparé par type d'événement	Par défaut ; isole le trafic d'événements et réduit la contention
SINGLE_CHANNEL	Tous les événements sont envoyés dans ALL_SINGLE_CHANNEL	Lorsque l'ordre global de tous les types d'événements est requis entre les nœuds

Avantages

👍 Fonctionne bien pour les déploiements multi-nœuds 👍 Les messages peuvent survivre à des interruptions temporaires des abonnés selon la longueur du stream 👍 Fournit livraison basée sur les offsets 👍 Prend en charge la relecture contrôlée des nouveaux événements après les redémarrages (la fonctionnalité de récupération de l'état de connexion est en cours de développement, pour l'instant vous obtiendrez l'offset du message) 👍 Utilise les primitives de base de Redis Streams sans brokers externes

Limitations

ℹ️ Les consommateurs traitent les messages indépendamment — l'ordre est par stream, pas global ℹ️ Risque de livraison en double lors des redémarrages ou des courses aux frontières d'offset ℹ️ Nécessite la prise en charge de Redis Streams (non compatible avec le mode Pub/Sub Redis legacy)

Garantie de livraison : Sémantique au moins une fois — les écouteurs d'événements doivent être idempotents pour gérer d'éventuels messages en double.