我已经开始研究在一组同级之间进行数据同步的方法。对等方必须能够以断开连接的方式工作，然后同步在一起以合并其本地更改。
对等方应该能够使用“三种方式合并”来合并本地更新。因此，在同步时，对等方应该知道哪些事实是最新的，但是在没有严格排序的地方，他们应该能够基于公共根将这些事实合并在一起。
当独立的同级进行更改时，他们可以使用“时钟”为它们“打上时间戳”。我使用术语“时钟”和“时间戳”，但我不是在说壁钟。我的意思是某种事件的部分排序，使因果关系清晰明了。事件之间的“先发生”关系形成有向无环图（DAG）。
似乎使用矢量时钟来构建这种部分排序的“通常”方法。但是，这些可能会变得非常大。间隔树时钟等最新发展提供了更紧凑的时间戳存储。
我根本不清楚的是，为什么同步协议显然不会“简单地”显式存储DAG。（或者他们？）
对等方可以通过随机生成UUID（或通过其他方法，例如<peer-name> + <local-monotonically-increasing-counter>）来独立创建时间戳。该时间戳的顺序对于该对等点是完全清楚的。
当两个对等方彼此同步时，他们可以商定新的时间戳。同样，此时间戳的顺序对双方均清晰可见。
现在需要在对等方之间传递DAG之前发生的事件，但是此操作的存储和带宽要求很小。时间点是图顶点。因此，它们具有1个或2个传入边（1个用于客户端上的事件，2个用于客户端之间的同步）。这是有界的，与网络中对等方的数量无关。
要使用单个时间点，您需要导致该时间点的时间图。然而，据我所看到的，任何对即能知道的时间点（它产生它本身，或与其他同行产生的，或者与它同步时已被其他同行告诉它）已经也有有机会了解到那个时间点之前的历史。我认为可能有一个归纳证明。
鉴于显式地存储和同步DAG似乎很简单：在实践中使用了吗？如果不是，为什么首选矢量时钟？
笔记
点对点
与客户端服务器解决方案相比，我更喜欢对等解决方案。
可能的最终拓扑将是许多客户端连接到在彼此之间复制的一小得多的服务器组。但是，最好有一个支持该特定拓扑的通用解决方案，而不是一个需要此特定拓扑的解决方案。