如果离线用户创建一个对象并向其添加一些标签.假设这些标签在用户的本地数据库中不存在,所以软件为它们生成一个UUID.现在当这些标签被同步时,需要进行解析过程来解决任何重叠.使用本地版本匹配远程数据库中的任何现有标签的一些方法.
一种方法是使用一些通过自然键(标签的名称来解析)全局对象的过程,并且本地数据库必须用全局数据库替换现有对象.当与其他对象有很多连接时,这可能是凌乱的.有人告诉我要避免这种情况.
另一种处理方式是使用两个ID.一个全局ID和一个本地ID.我希望使用UUID将有助于避免这种情况,但是我会使用单个UUID和使用两个分割ID来继续前进.使用这个选项让我想知道我是否让问题失控了.
另一种方法是通过非共享对象跟踪所有更改.在这个例子中,用户分配了标签的对象.当用户同步其脱机更改时,服务器可能会用全局替换本地标签.下次客户端与服务器同步时,会检测非共享对象的更改.当客户端拉下该对象时,他将收到全局标签.该软件将简单地重新保存指向服务器标签的非共享对象,并清除其本地版本.一些这样的问题是完全同步的额外的回程,以及刚刚孤立的本地数据库中的额外数据.系统处于同步状态之间是否还有其他可能发生的问题或错误？ (即尝试与服务器通话并发送对象的本地UUID等).
另一个选择是避免常见的对象.在我的软件中可能是一个可以接受的答案.我不是在大量的用户共享对象,但这并不意味着我将来不会这样做.这意味着如果我需要添加这些类型的功能,选择此选项可能会使我的软件在将来瘫痪.对这种选择有后果,我不知道我是否已经完全研究了这些选择.
所以我正在寻找任何最佳实践,现有的算法来处理这种类型的系统,选择指南等.
解决方法
还有其他方法可以处理对共享对象的断开更新. SVN,CVS等版本控制系统试图自动解决冲突,何时不能,只会告诉用户有冲突.您可以做同样的事情,只需告诉用户有并发更新,用户必须处理解决方案.
或者,您还可以将更新记录为更改的单位,并尝试一起组合更改.例如,如果您的共享对象是画布,并且您的应用程序语义允许在同一画布上进行共享绘图,则断开连接的更新,从A点绘制到B点,另一个断开连接的更新绘制从C点到D,可以组成.在这种情况下,如果将这两个更新仅保留两个操作,则可以对两个更新进行排序,并重新连接,每个用户上传所有断开连接的操作,并应用其他用户的缺少操作.你可能想要一些订购规则,也许是基于版本号.
另一个选择：如果不能自动对对共享对象的更新,并且您的应用程序语义不支持通知用户,并要求用户解决由于断开更新而导致的冲突,那么您还可以使用版本树来处理此问题.对共享对象的每次更新都会创建一个新版本,其中过去版本为父级.当来自两个不同用户的共享对象有断开连接的更新时,两个独立的子版本/叶节点来自相同的父版本.如果您的应用程序的内部状态表示是此版本树,那么您的应用程序的内部状态仍然保持一致,尽管断开更新,您可以以其他方式处理版本树的两个分支(例如让用户知道分支并为其创建工具合并分支,如源控制系统).
只是几个选项.希望这可以帮助.
