database - 同步公共(public)分布式数据的最佳实践

Question

我有一个支持离线模式的 Internet 应用程序，用户可以在其中创建数据，当用户恢复在线时，这些数据将与服务器同步。因此，正因为如此，我在我的数据库中使用 UUID 作为身份，这样断开连接的客户端就可以生成新对象，而不必担心使用另一个客户端使用的 ID 等。但是，虽然这对于该用户拥有的对象非常有效是由多个用户共享的对象。例如，用户使用的标签可能是全局的，远程数据库不可能保存整个宇宙中所有可能的标签。

如果离线用户创建了一个对象并为其添加了一些标签。假设这些标签不存在于用户的本地数据库中，因此软件会为它们生成一个 UUID。现在，当这些标签同步时，将需要解决过程来解决任何重叠问题。将远程数据库中的任何现有标签与本地版本相匹配的某种方法。

一种方法是使用一些过程，全局对象通过自然键(在标记的情况下是名称)解析，本地数据库必须用全局数据库中的对象替换它的现有对象。当与其他对象有很多连接时，这可能会很困惑。有些东西告诉我要避免这种情况。

另一种处理方法是使用两个 ID。一个全局 ID 和一个本地 ID。我希望使用 UUID 可以帮助避免这种情况，但我一直在使用单个 UUID 和使用两个拆分 ID 之间来回切换。使用此选项让我想知道我是否让问题失控了。

另一种方法是通过非共享对象跟踪所有更改。在这个例子中，对象被用户分配了标签。当用户同步他们的离线更改时，服务器可能会用全局标签替换他的本地标签。下次此客户端与服务器同步时，它会检测到非共享对象中的更改。当客户端拉下该对象时，他将收到全局标记。该软件将简单地重新保存非共享对象，将其指向服务器的标签并孤立他的本地版本。一些问题是完全同步的额外往返，以及本地数据库中刚刚孤立的额外数据。当系统处于同步状态之间时，是否还有其他问题或错误可能发生？ (即尝试与服务器对话并向其发送对象的本地 UUID 等)。

另一种选择是避免常见对象。在我的软件中，这可能是一个可以接受的答案。我没有在用户之间进行大量对象共享，但这并不意味着我将来不会这样做。这意味着如果我需要添加这些类型的功能，选择此选项可能会使我的软件在未来瘫痪。这个选择会产生一些后果，我不确定我是否已经完全探索过它们。

所以我正在寻找任何类型的最佳实践、处理此类系统的现有算法、选择指南等。

Answer 1

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

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

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

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

只有几个选项。希望这会有所帮助。