Usine de magasins

Le StoreFactory définit comment socketio4j crée et gère des magasins par session et des maps partagées, tout en exposant un EventStore pour la synchronisation d'événements distribuée. Le stockage et la propagation des événements sont découplés, permettant à n'importe quel backend de magasin de données d'être associé à n'importe quel mécanisme de distribution d'événements compatible.

Cela permet des combinaisons flexibles telles que :

• Stockage en mémoire + synchronisation d'événements basée sur Kafka

• Stockage Redis + pub/sub NATS

• Stockage Hazelcast + Redis Streams

• Stockage en mémoire + pas de distribution (MemoryEventStore) …ou toute autre association spécifique au déploiement.

Caractéristiques principales

• Création de Store par session — chaque connexion cliente obtient son propre magasin de données

• Création de map partagée — fournit des maps nommées pour les namespaces, les adapters et les plugins

• Exposition d'EventStore — fournit un backend d'événements, indépendant du choix de stockage

• Conception composable — le stockage et la propagation des événements peuvent provenir de systèmes différents

• Comportement configurable — échangez la distribution d'événements sans remplacer le stockage

Comment ça marche

• createStore(sessionId) → renvoie un scoped à la session Magasin lié au backend de stockage

• createMap(name) → renvoie une map nommée et partagée pour l'état inter-session

• eventStore() → renvoie le EventStore (par défaut ou personnalisé)

• init(...) → prépare le stockage et la synchronisation d'événements avant le démarrage du serveur

• shutdown() → nettoie les ressources allouées lors de l'arrêt

Mélange et correspondance

Backend de stockage (StoreFactory)	Backend d'événements (EventStore)	Valide	Exemple de déploiement
Mémoire	Kafka	✔️	données de session locales + propagation d'événements globale
Redis	NATS	✔️	Maps Redis + messagerie à faible latence
Hazelcast	Redis Streams	✔️	Clustering Hazelcast + synchronisation durable via stream
Mémoire	Mémoire	✔️	nœud unique, pas de distribution
Hazelcast	Kafka	✔️	Réplication de session Hazelcast + synchronisation Kafka

Résumé de la conception

• StoreFactory décide où vivent les métadonnées par session

• EventStore décide comment les événements sont distribués entre les serveurs

• Les deux sont indépendants et remplaçables à l'exécution

Avantages

👍 Déploiements hybrides et voies de migration progressive 👍 Les couches de stockage et d'événements peuvent évoluer indépendamment 👍 Évite de coupler l'état distribué au transport d'événements 👍 Fonctionne aussi bien pour les configurations mono‑nœud que pour les clusters