Magasin d'événements

Le EventStore interface définit la couche de synchronisation d'événements distribués de socketio4j. Elle fournit une abstraction unifiée pour publier et s'abonner aux événements internes — tels que les jonctions/les départs de salles, les accusés de réception, les changements de session et la synchronisation entre nœuds — sur une ou plusieurs instances de serveur.

Caractéristiques principales

• API d'événements unifiée — même modèle publication/abonnement pour tous les backends

• Distribution typée — les écouteurs reçoivent des EventMessage objets

• Filtrage conscient du nœud — les implémentations ignorent généralement les événements d'origine locale via nodeId

• Transports modulables — Kafka, Redis Streams, Hazelcast, NATS, repli en mémoire, etc.

• Contrôle du cycle de vie — standardisé publier, s'abonner, se désabonner, arrêt

Comment ça marche

• publier → envoi spécifique au backend via publish0

• s'abonner → enregistrer un écouteur d'événements via subscribe0

• se désabonner → supprimer l'écouteur et nettoyer via unsubscribe0

• arrêt → libérer les ressources du backend via shutdown0

• Les implémentations fournissent le comportement de transport via les *0 méthodes ; l'interface standardise le flux et la gestion des erreurs

Propriétés de routage d'événements

Propriété	Signification
EventStoreMode	MULTI_CHANNEL (flux/sujets par événement) ou SINGLE_CHANNEL (canal unifié)
EventStoreType	Déclare la famille de transport : STREAM, PUBSUB, LOCAL, etc.
PublishMode	Décrit la fiabilité attendue : RELIABLE ou UNRELIABLE
nodeId	Identifie le nœud ; utilisé pour éviter de retraiter les événements locaux

Remarque : getNodeId() fournit un ID aléatoire par défaut. Pour les déploiements distribués, configurez une identité de nœud stable via StoreFactory.

Avantages

👍 Changer les transports distribués sans modifier le code 👍 Journalisation centralisée des erreurs et sémantique de flux 👍 Points d'extension clairs pour les backends personnalisés 👍 Abstrait les différences de transport

Limitations

ℹ️ Les garanties de livraison dépendent de l'implémentation — non imposées par l'interface ℹ️ La persistance, l'ordonnancement et la déduplication sont des responsabilités du backend ℹ️ nodeIdLe filtrage local basé sur - doit être respecté pour éviter les doublons

---

Garanties de livraison

Le L'interface EventStore ne définit pas de garanties de livraison. La fiabilité, la relecture et l'ordonnancement dépendent entièrement du backend choisi (par ex. Redis Streams = au moins une fois ; Redis Pub/Sub = meilleur effort ; Kafka = au moins une fois ; Mémoire = local uniquement).