您必须决定的第一件事是关于在发生冲突更改时将哪一方视为“权威”的一般政策。
即:假设记录#125在1月5日晚上10点在服务器上更改,并且同一记录在1月5日晚上11点在其中一部电话(称为客户A)上更改了。上次同步时间是1月3日。然后,用户在1月8日重新连接。
在客户端和服务器都知道上次同步的日期的意义上,识别需要更改的内容是“容易的”,因此自从上次同步以来,任何创建或更新的内容(请参见下文中的更多信息)都可以协调。
因此,假设唯一更改的记录是#125。您要么确定两个版本之一自动“获胜”,然后覆盖另一个版本,要么需要支持协调阶段,用户可以确定哪个版本(服务器或客户端)是正确的版本,而覆盖另一个版本。
这个决定非常重要,您必须权衡客户的“角色”。特别是如果不仅客户端与服务器之间存在潜在冲突,而且如果不同的客户端可以更改同一条记录,则尤其如此。
[假设#125可以由第二个客户端(客户端B)修改,则尚未同步的客户端B可能会提供同一记录的另一个版本,从而使先前的冲突解决方法无济于事]
关于上面的“已创建或更新的”要点...如果记录源自某个客户端,您如何正确识别该记录(假设这在您的问题域中有意义)?假设您的应用管理一个业务联系人列表。如果客户A说您必须添加一个新创建的约翰史密斯,并且服务器上有一个昨天由客户D创建的约翰史密斯...您是否创建了两个记录,因为不能确定它们不是同一个人?您还会要求用户调解此冲突吗?
客户是否拥有数据子集的“所有权”?即,如果将客户B设置为区域5数据的“权威”,则客户A是否可以修改/创建区域5的记录?(这将使某些冲突的解决变得更容易,但可能对您的情况不可行)。
概括起来,主要问题是:
- 考虑到分离的客户端在创建新记录之前可能尚未访问服务器,如何定义“身份”。
- 以前的情况,无论该解决方案多么复杂,都可能导致数据重复,因此您必须预见到如何定期解决这些问题,以及如何通知客户端他们认为“记录#675”的内容实际上已被/合并。记录#543
- 决定是否通过命令解决冲突(例如,“如果服务器版本自上次同步以来已更新,则服务器版本始终胜过客户端”)或通过手动干预来解决
- 如果是法定命令,尤其是如果您决定让客户端优先,则还必须注意如何处理可能会带来更多变化的其他尚未同步的客户端。
- 前面的项目没有考虑数据的粒度(为了使描述更简单)。只需说一下,而不是像我的示例那样在“记录”级别进行推理,您可能会发现更适合在字段级别记录更改。或者一次处理一组记录(例如,人记录+地址记录+联系人记录),将它们的汇总视为一种“元记录”。
参考书目:
(最后三个来自ACM数字图书馆,不知道您是会员还是可以通过其他渠道获得)。
从Dr.Dobbs网站:
- 使用SQL Server CE和SQL RDA创建应用程序,作者Bill Wagner,2004年5月19日(为台式机和移动PC设计应用程序的最佳做法-Windows / .NET)
来自arxiv.org:
- 无冲突的复制JSON数据类型-本文描述了JSON CRDT的实现(无冲突的复制数据类型-CRDT-是支持并发修改并保证此类并发更新的收敛性的数据结构家族)。