在多个实体之间同步数据最聪明,最简单的方法是什么？

Question

在当今世界,许多计算机,移动设备或Web服务共享数据或充当集线器,同步变得更加重要.众所周知,同步的解决方案并不是最舒适的解决方案,最好不要同步.

我仍然很好奇你将如何实现同步解决方案以在多个实体之间进行同步.已经存在许多不同的方法,例如比较更改的日期字段或散列并使用最新数据或让用户在冲突的情况下选择他想要使用的内容.另一种方法是尝试自动合并冲突的数据(在我看来,这并不是那么聪明,因为机器无法猜出用户的意思).

无论如何,在开始实现同步之前,我们应该回答几个与同步有关的问题:

• 最新数据是什么？我该如何表示呢？
• 如果发生冲突,我该怎么办？合并？我是否提示并询问用户该怎么做？
• 当我进入不一致状态(例如由于移动网络连接断开而断开连接)时,我该怎么办？
• 当我不想进入不一致状态时,我该怎么办？
• 如何恢复被中断的当前同步？
• 我如何处理数据存储(例如,Web服务上的MySQL数据库,iPhone上的Core Data;以及如何在没有大量胶水代码的情况下合并/同步数据)？
• 如何处理同步期间发生的用户编辑(在后台运行,因此UI不被阻止)？
• 如何以及在哪个方向传播更改(例如,用户在其计算机上创建"Foo"条目并且不同步;然后他在旅途中创建另一个"Foo"条目;当他尝试同步两个设备时会发生什么)？用户是否会有两个具有不同唯一ID的"Foo"条目？用户是否只有一个条目,但是哪个条目？
• 当我有分层数据时,我该如何处理同步？自顶向下？自下而上？我是否以原子方式处理每个条目,还是仅查看超级节点？在过度简化事物和投入太多时间进行实施之间进行权衡有多大？
• ...

还有很多其他问题,我希望我能够激励你.同步是一个相当普遍的问题.一旦找到了一个好的,多功能的同步方法,它应该更容易应用于具体的应用程序,而不是从头开始思考.我意识到已经有很多应用程序尝试解决(或成功解决)同步,但它们已经相当具体,并且通常不能给出足够的同步方法答案.

Answer 1

在我工作的地方,我们开发了一个主要(网络)应用程序的"离线"版本,用户可以在他们没有互联网访问权限的地方使用他们的笔记本电脑(我不确定这些地方中有多少实际存在这些天,但我被告知他们这样做;)).当用户返回主站点时,他们需要将他们离线输入的数据与我们的主应用程序同步.

那么,回答你的问题:

• 最新数据是什么？我该如何表示呢？

我们在每个表上都有一个LAST_UPDATED_DATE列.服务器会跟踪同步发生的时间,因此当脱机应用程序请求同步时,服务器会说"嘿,只给我自此日期以来的数据更改".

• 如果发生冲突,我该怎么办？合并？我是否提示并询问用户该怎么做？

在我们的例子中,离线应用程序只能更新所有数据的相对较小的子集.当每个记录同步时,我们检查它是否是这些情况之一,如果是,那么我们比较在线和离线记录的LAST_UPDATED_DATE.如果日期不同,那么我们也会检查这些值(因为如果它们都更新为相同值,则不会发生冲突).如果存在冲突,我们会记录差异,设置一个标志,表示至少存在一个冲突,并继续检查其余的细节.一旦完成该过程,则如果设置了"isConflict"标志,则用户能够转到显示差异的特殊页面并确定哪个数据是"正确"版本.然后将此版本保存在主机上,并重置"isConflict"标志.

• 当我不想进入不一致状态时,我该怎么办？
• 如何恢复被中断的当前同步？

好吧,我们试图避免首先陷入不一致的状态.如果由于任何原因中断了同步,则last_synchronisation_date不会更新,因此下次启动同步时,它将从与先前(中断)同步的开始日期相同的日期开始.

• 我如何处理数据存储(例如,Web服务上的MySQL数据库,iPhone上的Core Data;以及如何在没有大量胶水代码的情况下合并/同步数据)？

我们在两个应用程序上使用标准数据库,在其间使用Java对象.对象被序列化为XML(并进行gzip以加速传输)以用于实际的同步过程,然后在每一端进行解压缩/反序列化.

• 如何处理同步期间发生的用户编辑(在后台运行,因此UI不被阻止)？

这些编辑将在同步开始日期之后进行,因此在下一次同步之前不会在另一侧进行拾取.

• 如何以及在哪个方向传播更改(例如,用户在其计算机上创建"Foo"条目并且不同步;然后他在旅途中创建另一个"Foo"条目;当他尝试同步两个设备时会发生什么)？用户是否会有两个具有不同唯一ID的"Foo"条目？用户是否只有一个条目,但是哪个条目？

这取决于你决定如何处理这个特殊的Foo ...即取决于Foo的主键是什么以及你如何确定一个Foo是否与另一个相同.

• 当我有分层数据时,我该如何处理同步？自顶向下？自下而上？我是否以原子方式处理每个条目,还是仅查看超级节点？

同步是原子的,因此如果一个记录失败,则整个过程被标记为不完整,类似于subversion提交事务.

• 在过度简化事物和投入太多时间进行实施之间进行权衡有多大？

我不确定你的意思,但我说这一切都取决于你的情况和你想要同步的数据的类型/数量.设计和实施该过程可能需要很长时间,但这是可能的.

希望能帮到你或至少给你一些想法!:)

Answer 2

可能“不是真正的问题”，这不是真正的答案：

我认为分布式版本控制系统（例如 Mercurial 或 git）已经解决了其中的很大一部分问题。然而，它们要求人们接受可以有多个“最新”版本，并且有时冲突的更新需要手动解决才能解决。另外，如果您对保留整个更改历史记录不感兴趣，那么这些系统中会有相当多的开销（但当然，最近的历史记录对于找到共同的祖先以确定两个版本如何关联是必要的）。

但我同意你的观点，在每个人的数据都分布在多个设备和服务的世界中，自动跟踪和分发更新的需求将变得如此迫切，以至于应用程序使用的通用文件格式将包含足够的元数据促进某种智能合并行为。但这种行为可能必须发生在应用程序级别，因为没有通用的方法来解决冲突的更新。

同时，iTunes-iPod 方法是最简单的：您只有一个主库，每个设备都从那里获取。显然，单主同步在所有情况下都不是很令人满意（特别是当涉及多个用户时），但如果有更多应用程序提供像这样工作的选项，我将不胜感激（小气：我有三台 Mac） ，安装了三个 iPhoto。如果它们能够从一个专用主​​控自动同步，就像照片同步到我的 iPod 一样，那将是一个改进）。