同步通用分布式数据的最佳实践

根据您希望向用户提供的应用程序语义,您可以选择不同的解决方案。例如,如果您实际上是在谈论使用关键字标记脱机用户创建的对象,并且希望在不同用户创建的多个对象之间共享标记,那么按照您的建议,使用“文本”标记是可以的。一旦每个人的更改被合并,具有相同“文本”的标签,比如说“这太棒了”,将被共享。

还有其他方法可以处理对共享对象的断开连接的更新。SVN、CVS和其他版本控制系统尝试自动解决冲突,当无法解决时,只会告诉用户存在冲突。你也可以这样做,只需告诉用户有并发更新,用户必须处理解决方案。

或者,您也可以将更新记录为更改单元,并尝试将更改组合在一起。例如,如果您的共享对象是画布,并且您的应用程序语义允许在同一画布上共享绘图,则可以组成一个断开连接的更新,从点a到点B绘制一条线,以及另一个断开连接的更新,从点C到点D绘制一条线。在这种情况下,如果将这两个更新保持为两个操作,则可以订购这两个更新,在重新连接时,每个用户都会上载其所有断开连接的操作,并应用其他用户缺少的操作。您可能需要某种排序规则,可能基于版本号。

另一种选择是:如果无法自动协调对共享对象的更新,并且您的应用程序语义不支持通知用户并要求用户解决由于断开连接的更新而导致的冲突,那么您也可以使用版本树来处理此问题。对共享对象的每次更新都会创建一个新版本,旧版本为父版本。当两个不同的用户对共享对象进行断开连接的更新时,同一父版本会产生两个不同的子版本/叶节点。如果应用程序的内部状态表示是这个版本树,那么应用程序的内部状态将保持一致,尽管更新已断开连接,并且您可以通过其他方式处理版本树的两个分支(例如,让用户知道分支,并为它们创建合并分支的工具,如在源代码管理系统中)。

只有几个选择。希望这有帮助。

您的问题与SVN等版本控制系统非常相似。你可以从中吸取教训。

每个用户都将拥有一组个人物品,以及他们需要的任何共享物品。在本地,它们将像拥有所有对象一样工作。

在同步过程中,客户端将首先下载对象中的任何更改,并自动同步显而易见的内容。在您的示例中,如果有一个来自同名服务器的新标记,那么它将在本地系统上相应地更新UUID。

这也是一个很好的地方,可以检测和处理来自另一个客户机但由同一用户提交的数据等情况。

一旦客户机有了数据的更新和合并版本,就可以进行上传。

会有往返,但我认为如果不使数据结构过于复杂,并且在同步的方式中存在潜在的陷阱,就无法做到这一点。

作为一个完全脱离左派的建议,我想知道是否使用 CouchDB 可能适合你的情况。它的 replication features 可以为您处理许多在线/离线同步问题,包括允许应用程序在出现冲突时处理冲突解决的机制。