Redis Pub/Sub fiable

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

Le RedissonPubSubReliableEventStore fournit un magasin d'événements distribué, capable de rejouer pour socketio4j utilisant Des topics fiables Redis basés sur Redis Streams. Il prend en charge la synchronisation multi-nœuds avec un éventuel rognage de flux pour contrôler l'empreinte mémoire, permettant la durabilité après les redémarrages du serveur tout en délivrant les événements en quasi temps réel.

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

Caractéristiques principales

• Livraison fiable via Redis Streams — conserve les messages récents pour une relecture contrôlée

• Topics basés sur des streams — RReliableTopic assure que les messages sont persistés et livrés aux abonnés tardifs

• Rognage automatique optionnel — empêche la croissance illimitée du stream en utilisant XTRIM

• Dispatch asynchrone — les callbacks de livraison se produisent hors des boucles d'événements Netty

• Prévention des doublons — filtre les événements d'origine locale via nodeId

Comment ça marche

• publish0 écrit des événements dans un topic fiable, qui en interne ajoute au stream Redis

• subscribe0 enregistre un écouteur sur le topic fiable ; les événements sont extraits du stream sous-jacent même après reconnexion

• Les entrées du stream sont périodiquement rognées en fonction de streamMaxLength et trimEvery

• Le rognage est effectué de manière asynchrone dans un thread démon pour éviter de bloquer les E/S

• Métadonnées du stream (activePubTopics, activeSubTopics, trimTopics) sont suivies par type d'événement

Modes

Mode	Comportement	Quand l'utiliser
MULTI_CHANNEL	Streams par type d'événement + topics fiables	Par défaut ; isole le trafic et maintient l'ordre par type d'événement
SINGLE_CHANNEL	Tous les événements routés vers un seul stream fiable	Lorsque l'ordre global strict est requis

Avantages

👍 Messages persistés dans le stream Redis — récupérables jusqu'aux limites de rognage 👍 Adapté pour la synchronisation multi-nœuds avec durabilité 👍 Le rognage optionnel empêche l'utilisation mémoire illimitée 👍 Peut rejouer les messages récents après reconnexions (dans la plage rognée) 👍 Modèle de déploiement Redis familier, pas besoin de Kafka/NATS

Limitations

ℹ️ Pas entièrement exactement une seule fois — des doublons peuvent survenir après un redémarrage ou des reconnexions ℹ️ L'ordre est par stream — l'ordre entre événements nécessite le mode canal unique ℹ️ Nécessite la prise en charge de Redis Streams (Redis 5+) ℹ️ La fiabilité dépend de la configuration de rétention du stream et de la stratégie de rognage

Garantie de délivrance : Sémantique au moins une fois — les écouteurs doivent être idempotents pour gérer les livraisons potentielles en double.