什么情况下使用向量时钟而不是版本向量？

Question

我一直在努力寻找适用于向量时钟和版本向量的用例示例，以及它们可能有何不同。我知道它们的工作方式基本相同，向量时钟使用receive和send函数，而版本向量则使用sync函数，但我不理解这两种选择之间的区别。它们只是表达同一事物的两种不同方式，还是在使用案例上存在真正的区别？我只能找到一个相关问题："何时使用像Paxos这样的共识算法，而不是使用像向量时钟这样的东西?"。尽管链接答案陈述了以下内容，并引用了一篇简短文章，但这些差异仍然不清楚。

如果您想要在无领导分布式存储中使用版本向量，则可以使用它。您也可以使用向量时钟（尽管不太适合；该文章还建议您将其用于一般分布式系统中的一致快照、实现因果排序等）。

- arabellel

---

这篇文章提供了一个相当不错的概述：https://haslab.wordpress.com/2011/07/08/version-vectors-are-not-vector-clocks/ - Pedro Lopes

这是一本关于分布式系统概念的最佳书籍之一 - https://pdfs.semanticscholar.org/24f1/4e3b30012c2bc7e3abbdb16e2b3365d6f920.pdf，它详细解释了分布式系统中机器之间的时间/时钟差异如何会给人留下错误印象。 - Bishnu

@Bishnu 的链接已经失效。从 Web 存档中检查，它是有关设计数据密集型应用程序的内容。 - wlnirvana

Answer 1

同样的问题在这里，对我来说仍然不是完全清楚的，但我发现 版本向量 更适合确定分布式系统中复制节点网络中事件因果关系，其中你只关心发生的先后顺序。

相比之下，向量时钟 确定了分布式系统中未确定事件序列的事件顺序。

从版本向量的角度来看，使用整数过于复杂，因为如果我们只想确定哪个节点 A 或 B 更更新，在最初 A[2,2] 和 B[2,2]（因此同步）的情况下。

A[3,2] > B[2,2] 的版本向量意味着与 A[10,2] > B[2,2] 相同。这就解释了为什么我们可以使用一组固定的值进行版本向量，并且唯一重要的操作只是同步版本。

从向量时钟的角度来看，A [10,2]和A [3,2]之间存在差异。这意味着在其间发生了+7个事件。这就解释了为什么我们需要跟踪所有事件，并且有发送和接收操作以同步网络中的所有向量时钟。

总之，我像你一样缺少清晰的文档，可以清楚地解释一个与另一个的区别和用法。

- Luis

---

我和你一样，都缺少一份清晰的文档，能够明确解释这两者之间的区别和用法。你是否找到了这样的文档，或者是关于版本向量的实践教程？谢谢！ - tonix

Answer 2

这两个机制由于相同的合并方式而令人困惑，但用例不同。

• 向量时钟 用于确定分布式系统中事件的部分排序。它将检测因果关系的违规和并发事件。它使用 receive 和 send 来检查每个节点的顺序，但不会sync状态。

• 版本向量 用于比较多个（数据库）副本中项目的状态。这就是为什么它使用sync函数，它试图在所有副本之间同步状态。

在向量时钟中，我们知道事件E_a 和 E_b没有被排序，我们可以通过它们的版本找出事件的顺序。

 ┌──┐                 ┌──┐  ┌──┐
 │A0│                 │A1│  │A2│
 │  │      ...        │B2│  │B2│ <- E_a
 │  │                 │C1│  │C1│
 └──┘                 └──┘  └──┘
---------------INDEPENDENT---------------
 ┌──┐      ┌──┐  ┌──┐       ┌──┐
 │  │      │  │  │  │       │  │
 │B0│ ...  │B1│  │B2│       │B3│ <- E_b
 │  │      │C1│  │C1│       │C1│
 └──┘      └──┘  └──┘       └──┘
---------------INDEPENDENT---------------
 ┌──┐  ┌──┐
 │  │  │  │
 │  │  │  │
 │C0│  │C1│
 └──┘  └──┘

A0 表示项目 A 的版本为 0

在 版本向量 中，当我们从多个 DB 实例读取数据时，我们会发现存在不同的版本数据并合并冲突。这可以帮助状态达到 最终一致性。

                                                 Final state
User A  │ +Egg v1              +Milk +Ham v3    │Egg+Ham+Milk, v3
        │  │   ^                  │   ^         │
        │  V   │                  V   │ Ham v3  │
Cart DB │  ok,v1    ok,v2         ok,v3         │
        │           ^   │ Egg v2                │
        │           │   V                       │
User B  │        +Ham  +Egg v2                  │Egg+Ham, v2
-------------- Time ----------->

在这种情况下，只有一个DB实例可以使说明更容易，但您可以将其视为具有它们之间的复制延迟的DB实例。当您读取数据时，您将获得版本向量并使用每个版本向量解决在复制延迟期间发生在不同副本上的写入冲突。

引用来源：

• 版本向量不是向量时钟
• 设计数据密集型应用程序Ch.5-4-4
• 向量时钟 - 维基百科

- 呂學洲

Answer 3

它们基本上是相同的东西。

事实上，sync 是一个高级抽象，应该使用 send 和 receive 来实现。

为了更清楚地说明，想象一种情况，对于同一个对象（或键，如果它是键值存储），两个副本现在具有所谓的版本向量 [1,0] 和 [0,1]。现在它们应该如何同步？

除非您明确实现合并策略来处理冲突，否则它们无法同步。因此，sync 不是无中生有的。它是一个高级 API，内部包含合并策略以及对 send 和 receive 的调用。

现在，如果您从 send 和 receive 的角度考虑向量时钟和版本向量，它们之间的区别大多是概念性的。

向量时钟是用于在分布式系统中排序事件的时钟。每次节点发送、接收甚至在内部更新某些内容时，都会发生事件。

版本向量顺序版本是分布式数据存储中副本的特定种类，需要注意的是，并非所有事件都会改变副本的版本-只有写入请求/事件才会。因此，与其关注事件，更好的概念性关注重点是副本的版本，这些版本是事件的结果。

请参见为什么逻辑时钟容易，了解相关概念的初步介绍。

- wlnirvana