Synchronisation entre deux systèmes utilisant MongoDB comme journal des modifications

Nous développons deux systèmes liés. L'un d'eux (A) sera installé sur les machines de nos clients. Le reste (B) sera utilisé par mon organisation.

Chaque système possède sa propre base de données (relationnelle) et leurs schémas diffèrent. Cependant, les deux systèmes doivent être synchronisés. De plus, certaines modifications de B doivent être exportées vers tous les systèmes de classe A et d'autres uniquement vers un système spécifique.

Certains clients n'ayant pas de connexion Internet, la synchronisation, dans certains cas, doit être effectuée via l'échange de fichiers.

Nous prévoyons donc de résoudre ce problème comme suit:

1. Chaque système tient un journal des modifications de sa base de données. Nous prévoyons de l'implémenter avec MongoDB.
2. Lorsqu'un système initialise un processus de synchronisation, il récupère toutes les modifications apportées à partir d'un journal. Si le système est B, les modifications récupérées dépendent de la destination. Ensuite, le système les sérialise au format XML et, enfin, les envoie (via un fichier ou un réseau).
3. Lorsque l'autre noeud final reçoit l'ensemble de modifications, il les désérialise. Ensuite, le système effectue des transformations sur les données, ce qui peut être nécessaire, et enfin, enregistre les modifications. Dans cette étape, si cela est nécessaire, le système doit résoudre les conflits qui pourraient exister.
4. Enfin, le système récepteur envoie ses modifications (et d'autres produits de résolution de conflits).

Cette approche est-elle faisable, évolutive et élégante? Quels changements ou ajouts apporteriez-vous?

Si vous ne l'avez pas déjà fait, vous trouverez peut-être intéressant de vous renseigner sur les systèmes événementiels, la recherche d'événements et la cohérence éventuelle. Le système que vous décrivez présente de nombreux parallèles avec ces modèles, ce qui est une bonne chose.

Votre approche sonne bien, en particulier:

• L'utilisation d'un journal des modifications ordonné signifie que le processus de synchronisation est capable de récupérer uniquement les modifications apportées depuis la dernière modification vue. Cela réduira le temps de traitement, ce qui contribuera à l'évolutivité et vous permettra de créer une synchronisation en temps quasi réel dans les cas où la connectivité Internet est disponible.
• Les clients sans connexion Internet vous obligent à penser à gérer la synchronisation retardée et hors service maintenant, plutôt que de compter sur une synchronisation rapide et de vous retrouver par inadvertance avec des problèmes d'évolutivité.

Sans en savoir plus sur le modèle de domaine, je suppose que la résolution des conflits est la partie qui vous causera le plus de problèmes. Je passerais un certain temps à réfléchir à la manière dont chaque type de conflit serait résolu. En particulier:

• Certains conflits nécessiteront-ils une résolution utilisateur?
• Le système client sera-t-il toujours le bon endroit pour résoudre les conflits?
• Est-il possible qu'il y ait des conflits dans le système B après l'étape 4 lorsque le système client envoie ses modifications?

Chaque système tient un journal des modifications de sa base de données. Nous prévoyons de l'implémenter avec MongoDB.

Vous pouvez utiliser un magasin d' événements . Là, toute mise à jour des données créera un nouvel événement dans le magasin.

Lorsqu'un système initialise un processus de synchronisation, il récupère toutes les modifications apportées à partir du journal. Si le système est B, les modifications récupérées dépendent de la destination. Ensuite, le système les sérialise au format XML et, enfin, les envoie (via un fichier ou un réseau).

Vous pouvez utiliser n'importe quel mécanisme pour envoyer des événements, mais il serait plus facile d'utiliser un bus si possible où vous n'avez pas à traiter de fichiers. En règle générale, ceux-ci peuvent être configurés pour conserver les messages jusqu'à ce que la connectivité soit disponible pour les envoyer.

Lorsque l'autre noeud final reçoit l'ensemble de modifications, il les désérialise. Ensuite, le système effectue des transformations sur les données, ce qui peut être nécessaire, et enfin, enregistre les modifications. Dans cette étape, si cela est nécessaire, le système doit résoudre les conflits qui pourraient exister.

Appliquez simplement les événements à vos objets de domaine.

Enfin, le système récepteur envoie ses modifications (et d'autres produits de résolution de conflits).

Utilisez la même approche.