Modèle de synchronisation client / serveur / algorithme ?

Question

J'ai le sentiment qu'il doit y avoir des client-serveur de synchronisation de modèles là-bas. Mais j'ai totalement échoué à google un.

La Situation est assez simple - serveur est le nœud central, qui à plusieurs clients de se connecter et de manipuler les mêmes données. Les données peuvent être divisées dans les atomes, en cas de conflit, ce qui est sur le serveur, a la priorité (pour éviter de se faire de l'utilisateur dans la résolution des conflits). Synchronisation partielle est préféré en raison de potentiellement de grandes quantités de données.

Existe-il des motifs / bonnes pratiques pour ce type de situation, ou si vous ne savez pas de n'importe - quel serait votre approche?

Ci-dessous est comment maintenant, je pense qu'à le résoudre: En parallèle des données, une modification journal sera tenu, après avoir toutes les transactions datées. Lorsque le client se connecte, il reçoit toutes les modifications depuis la dernière vérification, sous forme de synthèse (serveur va par le biais de listes et supprime les ajouts qui sont suivies par des suppressions, fusions mises à jour pour chaque atome, etc.). Et voila, nous sommes à jour.

Alternative serait de garder la date de modification pour chaque enregistrement, et au lieu de l'exercice de données supprime, il suffit de marquer eux aussi supprimés.

Toutes les pensées?

Answer 1

Vous devriez regarder comment répartie de la gestion du changement œuvres. Regardez SVN, CVS et les autres référentiels de gérer les deltas de travail.

Vous disposez de plusieurs cas d'utilisation.

• Synchroniser les modifications. Votre change-log (ou delta de l'histoire) approche semble bon pour cela. Les Clients envoient leurs deltas du serveur; serveur consolide et distribue les deltas pour les clients. C'est le cas typique. Les bases de données d'appel de cette "opération de réplication".

• Le Client a perdu la synchronisation. Soit par le biais d'une sauvegarde/restauration ou à cause d'un bug. Dans ce cas, le client doit obtenir l'état actuel du serveur, sans passer par les deltas. C'est une copie de maître du détail, les deltas et les performances être damné. C'est une chose une seule fois; le client est brisée; ne pas essayer d'optimiser cela, il suffit de mettre en œuvre une copie fiable.

• Client est suspect. Dans ce cas, vous devez comparer client contre le serveur pour déterminer si le client est à jour et les besoins les deltas.

Vous devez suivre la base de données (SVN) modèle de conception de manière séquentielle la numérotation de chaque changement. De cette façon, un client peut faire une demande triviale ("Quelle révision dois-je avoir?") avant de tenter de synchroniser. Et même alors, la requête ("Tous les deltas depuis 2149") est délicieusement simple pour le client et le serveur.

Answer 2

Ce que vous avez vraiment besoin, c’est Transformer opérationnel (OT). Cela peut même accueillir les conflits dans de nombreux cas.

C’est toujours un sujet de recherche active, mais il existe des implémentations de plusieurs algorithmes OT autour. J’ai été impliqué dans ces recherches depuis quelques années maintenant, alors laissez-moi savoir si cette voie vous intéresse, et je serai heureux de vous mettre sur des ressources pertinentes.

Answer 3

La question n'est pas limpide, mais j'aurais l'air dans le verrouillage optimiste , si j'étais vous. Il peut être mis en œuvre avec un numéro de séquence que le serveur renvoie pour chaque enregistrement. Lorsqu'un client essaie de sauver de l'enregistrement, il inclut le numéro de séquence reçue de la part du serveur. Si le numéro de séquence correspond à ce qui est dans la base de données au moment de la mise à jour est reçu, la mise à jour qui est permis et le numéro de séquence est incrémenté. Si la séquence de numéros ne correspondent pas, la mise à jour est rejetée.