cocoa - 基于时间戳的同步的常见陷阱是什么？

Question

我正在实现我的第一个同步代码。就我而言，我将为每个用户使用 2 种类型的 iOS 客户端，这些客户端将使用 lastSyncTimestamp 将记录同步到服务器。 , 一个 64 位整数，表示最后一次同步的 Unix 纪元(以毫秒为单位)。可以随时在服务器或客户端上创建记录，并通过 HTTP 以 JSON 形式交换记录。

我不担心冲突，因为更新很少，而且总是来自同一个用户。但是，我想知道是否有一些常见的事情我需要注意，基于时间戳的方法可能会出错，例如在夏令时期间同步、与另一个同步或其他问题的同步。

我知道 git 和其他一些版本控制系统避免使用时间戳同步基于内容的协商同步方法。我也可以为我的应用程序设想这样一种方法，其中使用 uuid或 hash在对象中，两个对等方宣布他们拥有哪些对象，然后交换它们，直到两个对等方拥有相同的集合。

如果有人知道基于内容的同步与基于时间戳的同步的优缺点，那也会有所帮助。

编辑 - 以下是我为基于时间戳和内容的同步提出的一些优点/缺点。请挑战/纠正。

备注 - 我将基于内容的同步定义为 2 组对象的简单协商，例如，如果你给他们一堆 2 组相同的棒球卡的每个部分，并在他们查看时告诉他们，2 个 child 将如何交换卡片他们宣布并将发现的任何重复项交给另一个，直到他们都拥有相同的集合。

约翰尼 - “我拿到了这张卡。”

戴维 - “我有这一堆卡片。把那张卡片给我。”

约翰尼 - “这是你的卡片。给我那一堆卡片。”

戴维 - “这是你的一堆卡片。”

....

两者-“我们完成了”

基于时间戳的同步的优点

易于实现

用于同步的单个属性。

基于时间戳的同步的缺点

时间是观察者的相对概念，不同机器的时钟可能不同步。有几种方法可以解决这个问题。在单台机器上生成时间戳，这不能很好地扩展并代表单点故障。或者使用逻辑时钟，例如矢量时钟。对于构建自己系统的普通开发人员来说，矢量时钟可能太复杂而无法实现。

基于时间戳的同步适用于客户端到主同步，但不适用于点对点同步或可以与 2 个主同步的情况。

单点故障，无论生成时间戳。

时间与正在同步的内容并不真正相关。

基于内容同步的优势

不需要维护每个对等时间戳。 2 个对等点可以启动同步 session 并根据内容开始同步。

明确定义的同步端点 - 当双方具有相同的集合时。

允许点对点架构，其中任何点都可以充当客户端或服务器，前提是它们可以托管 HTTP 服务器。

同步处理集合的内容，而不是抽象的概念时间。

由于同步是围绕内容构建的，如果需要，同步可用于进行内容验证。例如。可以对内容计算 SHA-1 哈希值并将其用作 uuid。它可以与同步期间发送的内容进行比较。

更进一步，SHA-1 散列可以基于以前的散列来保持内容的一致历史。

基于内容同步的缺点

可能需要实现对象上的额外属性。

与基于时间戳的同步相比，双方都有更多的逻辑。

稍微啰嗦的协议(protocol)(这可以通过同步集群中的内容来调整)。

Answer 1

部分问题在于时间不是一个绝对的概念。事情发生在其他事情之前还是之后是一个视角问题，而不是遵守挂钟。

阅读一下 relativity of simultaneity了解为什么人们不再尝试使用墙上时间来弄清楚这些事情，而是转向使用 vector clocks 来表示实际因果关系的结构。 (或至少 Lamport clocks )。

如果您想使用时钟进行同步，逻辑时钟可能最适合您。您将避免所有时钟同步问题和东西。