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

Question

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

我仍然很好奇您将如何实施同步解决方案以在多个实体之间进行同步。已经有很多不同的方法，例如比较更改的日期字段或哈希并使用最新数据或让用户选择他想在发生冲突时使用的内容。另一种方法是尝试自动合并有冲突的数据（我认为这不太聪明，因为机器无法猜测用户的意思）。

无论如何，在开始实施同步之前，我们应该回答几个与同步相关的问题：

• 最新数据是什么？我想如何表示它？
• 如果发生冲突，我该怎么办？合并？我是否提示并询问用户该怎么做？
• 当我进入不一致的状态（例如，由于移动网络连接不稳定而断开连接）时，我该怎么办？
• 当我不想进入不一致的状态时，我该怎么做？
• 如何恢复当前被中断的同步？
• 如何处理数据存储（例如 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 数据库、Core iPhone 上的数据；我该怎么做 合并/同步数据没有很多 胶水代码）？

我们在两个应用程序上都使用标准数据库，并在两者之间使用 Java 对象。对象被序列化为 XML（并压缩以加快传输速度）以进行实际同步过程，然后在每一端进行解压缩/反序列化。

• 我应该如何处理同步期间发生的用户编辑 （它在后台运行，所以 UI 没有被屏蔽）？

这些编辑将在同步开始日期之后进行，因此在下一次同步之前不会被另一方拾取。

• 我如何以及在哪个方向传播更改（例如，用户创建 他电脑上的“Foo”条目和 不同步；然后他在旅途中 创建另一个“Foo”条目；什么 当他尝试同步两者时发生 设备）？用户会有两个“Foo”吗 具有不同唯一 ID 的条目？ 用户是否只有一个条目，但是 哪一个？

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

• 当我有分层数据时，我应该如何处理同步？自顶向下？ 自下而上？我是否对待每个条目 原子地还是我只看一个 超级节点？

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

• 过度简单化和投资之间的权衡有多大 实施时间过长？

我不确定您的确切意思，但我想说这完全取决于您的情况以及您要同步的数据类型/数量。设计和实施流程可能需要很长时间，但这是可能的。

希望对您有所帮助或至少给您一些想法！ :)

Answer 2

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

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

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

与此同时，iTunes-iPod 方法是最简单的：您只有一个主库，并且每台设备都从那里提取。显然，single-master-sync 在所有情况下都不是很令人满意（尤其是当涉及多个用户时），但是，如果更多应用程序提供这样的选项，我将不胜感激（讨厌：我有三台 Mac , 安装了三个 iPhoto。如果它们自动从一个专用母版同步，就像照片同步到我的 iPod 一样，那将是一个改进。

Answer 3

虽然在微软生态系统中确实很常用，但你可以学习Mobile Application Blocks。