基于时间戳的同步的常见缺陷是什么？

Question

我正在实现我的第一个同步代码.在我的情况下,我将为每个用户提供两种类型的iOS客户端,它们将使用lastSyncTimestamp一个64位整数将记录同步到服务器,该整数表示上一次同步的毫秒时间内的Unix时期.可以随时在服务器或客户端上创建记录,并通过HTTP将记录作为JSON进行交换.

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

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

如果有人知道基于内容的同步与基于时间戳的同步的任何优点或缺点,那么这也是有帮助的.

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

注意 - 我将基于内容的同步定义为两组对象的简单协商,例如,如果你给两个孩子们交换卡片的每个部分,那两个相同的两组棒球卡,并告诉他们看起来像他们一样通过他们宣布并将他们找到的任何副本交给另一方,直到他们都有相同的集合.

• 约翰尼 - "我拿到了这张卡片."
• 戴维 - "我收到了一堆卡片.给我那张卡片."
• 约翰尼 - "这是你的卡片.给我一堆卡片."
• 戴维 - "这是你的一堆牌."
• ....
• 两者 - "我们完成了"

基于时间戳的同步的优点

• 易于实施
• 用于同步的单个属性.

基于时间戳的同步的缺点

• 时间是观察者的相对概念,不同机器的时钟可能不同步.有几种方法可以解决这个问题.在单台机器上生成时间戳,该机器不能很好地扩展并表示单点故障.或者使用矢量时钟等逻辑时钟.对于构建自己的系统的普通开发人员来说,矢量时钟可能太复杂而无法实现.
• 基于时间戳的同步适用于客户端以进行主同步,但对于对等同步或两个主服务器可能发生同步的情况也不起作用.
• 单点故障,无论生成时间戳.
• 时间与正在同步的内容并不真正相关.

基于内容的同步的优点

• 不需要维护每个对等时间戳.2个对等体可以开始同步会话并基于内容开始同步.
• 定义明确的端点 - 当双方都有相同的集合时.
• 允许对等体系结构,任何对等体都可以充当客户端或服务器,只要它们可以托管HTTP服务器.
• 同步与集合的内容一起使用,而不是抽象的概念时间.
• 由于同步是围绕内容构建的,因此如果需要,可以使用同步进行内容验证.例如,可以对内容计算SHA-1哈希并将其用作uuid.它可以与同步期间发送的内容进行比较.
• 更进一步,SHA-1哈希可以基于以前的哈希值来维护内容的一致历史记录.

基于内容的同步的缺点

• 可能需要实现对象的额外属性.
• 与基于时间戳的同步相比,双方的逻辑更多.
• 稍微繁琐的协议(可以通过同步群集中的内容来调整).

Answer 1

部分问题在于时间不是绝对的概念.事物之前或之后发生的事情是一个透视问题,而不是遵守挂钟.

阅读一下同时性的相对性,以了解为什么人们已经停止尝试使用墙壁时间来解决这些问题,并且已经转向使用矢量时钟(或至少Lamport时钟)代表实际因果关系的构造.

如果您想使用时钟进行同步,逻辑时钟可能最适合您.您将避免所有时钟同步问题和内容.

Answer 2

我不知道它是否适用于您的环境，但您可能会考虑谁的时间是“正确的”，客户端还是服务器（或者是否重要）？如果所有客户端和所有服务器未同步到同一时间源，则客户端在使用客户端的“当前”时间同步到（或从）服务器时可能会得到意外结果，尽管这种可能性很小。

我们的开发组织实际上在几年前就遇到了一些问题。开发人员计算机并未全部同步到与 SCM 所在服务器相同的时间源（并且可能未同步到任何时间源，因此开发人员计算机时间可能会发生漂移）。几个月后，开发人员的机器可能会停机几分钟。我不记得所有的问题，但似乎构建过程试图自某个时间（上次构建）以来修改所有文件。自上次构建以来，文件可能已被检入，这些文件的修改时间（来自客户端）发生在上次构建之前。

可能是我们的 SCM 程序不太好，或者我们的 SCM 系统或构建过程太容易受到此问题的影响。即使在今天，我们所有的开发机器都应该与装有我们的 SCM 系统的服务器同步时间。

再说一次，这是几年前的事了，我不记得细节了，但我想提一下，以防它对你的情况很重要。