Considérez la situation suivante:
Les informations peuvent donc être publiées à partir de S1 et S2.
Supposons qu'un utilisateur porte initialement le nom N1.
Au moment t1, le commercial met à jour le nom de N1 à N3.
À présent, S1 consomme l'événement de S3 et met à jour le nom en N3. S2 consomme l'événement de S1 et met à jour le nom en N2.
Dans S3, le nom peut être n'importe quoi N2 OU N3 selon l'événement qui est consommé en premier.
Cela a entraîné une grande cohérence des données entre les différents systèmes.
Dans le système idéal, il n'y a qu'un seul éditeur, mais en raison de l'exigence, nous avons dû ajouter des événements de publication à partir du panneau des ventes. Que peut-on faire pour minimiser l'incohérence des données?
3 Réponses :
Permettez-moi de le reformuler une fois de plus ..
Dans ce scénario, j'irais avec Master DB / System qui sera un point unique de source de données pour chaque système.
Si un système souhaite modifier les données, les données doivent d'abord être mises à jour sur Master Db / system, puis elles doivent se propager à un autre système pour refléter les changements.
pour Pub-Sub, je suivrai la méthode Fan-IN et Fan-out.
De cette manière, vous pouvez obtenir la cohérence des données entre les systèmes. La seule chose dont vous devez faire attention est un retard dans ce processus, qui pourrait survenir si un système échoue.
J'espère avoir répondu à votre question.
Le problème semble être de décider qui est le maître des données utilisateur, car pour le moment, S3 essaie de servir deux maîtres.
S1 --> S3 S2 --> S1 --> S3
Faisons de S1 le maître des données utilisateur, donc que tout autre système qui accepte ces données (par exemple S2) est uniquement responsable de la mise à jour du maître. De cette façon, S3 obtient les données utilisateur d'une seule source (le maître des données utilisateur).
S1 --> S3 S2 --> S3
Le maître est responsable à la fois de la consommation et de la production des données qui lui appartiennent. Un autre système peut consommer (et même stocker) les mêmes données, mais il ne peut produire que pour le maître . Aucun système ne peut produire des données qu'il ne possède à aucun autre système que le maître de ces données.
Le système qui est le maître n'a pas vraiment d'importance, tant qu'il n'y en a qu'un. Le nombre de systèmes qui stockent des copies des données n'a pas vraiment d'importance, tant qu'il n'y a qu'un seul maître. Le fait d'avoir chaque système maître d'un type de données est probablement plus évolutif qu'un seul maître pour toutes les données.
Gardez un tableau pour garder une trace de toutes les dernières mises à jour (Dernières mises à jour d'un jour). En supposant que toutes les mises à jour peuvent être propagées à tous les autres systèmes via pub / sous-système en quelques minutes.
Tous les systèmes doivent contacter cette source principale avant de mettre à jour l'entrée (pour les champs tels que le nom, l'adresse e-mail et le numéro de contact)
S'il existe déjà une entrée dans cette table source principale, vous devez vérifier que qui est le dernier. Si leur entrée est plus récente, vous devez alerter l'utilisateur qu'il y a certaines mises à jour récentes sont arrivées au même enregistrement, avez-vous toujours souhaitez le mettre à jour.
S'il n'y a pas d'entrée, vous pouvez facilement mettre à jour les données avec le nouveau data et insérez une entrée dans cette table source principale.
Chaque fois qu'un système traite des mises à jour via pub-sub, il ne doit se mettre à jour que s'il n'y a pas de nouvelles mises à jour pour le même enregistrement.
S3 est-il un éditeur ou un consommateur ou les deux? La déclaration, " les informations peuvent être publiées à partir de S1 et S2 " semble entrer en conflit avec " S1 consomme un événement de S3 ".