问题标签 [vector-clock]

我想只跟踪最近的数据，并利用矢量时钟的帮助来解决问题，这样我就可以通过 LWW 规则轻松丢弃数据。（最后写入获胜）假设我们有 3 个节点：

然后我们将使用向量时钟来跟踪每个事件/更改的因果关系和并发性。我们最初用

例如 Node1 获得 5 个本地更改，这意味着我们将其时钟增加 5 个增量，这将导致

这通常没问题吧？

那么如果同时 Node2 更新它的本地并增加它的时钟会导致

在某个时刻，Node1 向 Node3 发送一个事件，传递更新并搭载其矢量时钟。因此，具有 VC 的 Node3{Node1:0, Node2:0, Node3:0}很容易合并数据和时钟，因为它还没有更改。

我正在考虑如何处理的问题是，如果 Node2 发送一个事件以更新到 Node3 并传递它自己的 VC 和更新，会发生什么。数据和时钟会发生什么。当从 Node1 写入 Node3 的第一个写入基本上会显示为稍后写入，因为它在自己的时钟上具有更大的 VC 值，我如何在这里应用 Last Write 获胜。合并前Node3的时钟：{Node1: 5, Node2: 0 , Node3: 1} Node3收到的Node2的messagevc：{Node1:0, Node2:1, Node3:0}

如何处理并发 VC 上的解析数据？

我无法理解 Akka 中使用的集群算法。

在 akka Gossip Protocol的描述中，它说：

gossip 状态或 gossip 状态的接收者可以使用 gossip 版本（向量时钟）来确定是否：

1. 它有一个更新版本的 gossip 状态，在这种情况下，它会将它发送回 gossiper
2. 它有一个过时的状态版本，在这种情况下，接收者通过发回它的八卦状态版本来向八卦者请求当前状态
3. 它有相互冲突的八卦版本，在这种情况下，不同的版本被合并并发回

第二步似乎浪费了通信，因为 gossiper 发送了两次它的状态。一次是当它发现它没有最新版本时，再一次是当接收者通过发回自己的过时版本来想要最新版本时。

我认为我对此有误解，因为我对矢量时钟和 CFRD 的理解有限，并且 Akka 文档中给出的描述很短，而维基百科的文章是高级的。就我而言，矢量时钟是 CRDT 的一种实现，但这可能是不正确的。

但最后我不明白为什么八卦节点需要两次传达其状态。请说清楚。

但我想我可能误解了vector Akka Cluster

SQL Server 中是否有一个全局序列号保证定期递增（即使系统时间倒退），并且可以作为插入或更新操作的一部分进行访问？

根据矢量时钟的维基百科页面：

但是，如果我们有以下架构： 单击此处获取图像

现在我们可以看到带有 VC(1,0,1) 和 VC(0,2,2) 的事件，它们满足了条件：

但是这两个事件（VC(1,0,1) 和 VC(0,2,2)）不是随机顺序关系！

有人可以告诉我这里出了什么问题，我错过了什么吗？

我想知道在这种情况下我是否会发生冲突：

换句话说：

首先，我没有1将{"bar":"baz"}值与 http api 的 PUT 放在一起的键的对象。

然后，我用 get 读取了这个值。我将 vclock 存储在变量中。

最后，我{"bar":"foo"}为密钥设置了一个新值1

有没有我可以拿到{"bar":"baz"}钥匙的情况1？如果 Riak 有冲突，它会用 vclock 解决吗？

谢谢 ！

我了解矢量时钟仅提供部分顺序。所以你不能直接对它们进行排序。出于这个原因，您对并发向量使用 tie-breaker，从而产生一个总顺序。

然而，对矢量时钟进行排序，以使结果列表中的每个原因都出现在结果列表中的每个结果之前似乎不起作用，我也不完全明白为什么。

我有大量的测试表明比较两个向量是有效的：

但是，当对向量时钟列表进行排序时，例如一个具有两个向量的向量时钟，该向量具有发生前的关系，而第三个向量与其他两个向量同时发生，可能会发生只有并发的一个向量与其他两个向量进行比较，以及依赖的向量互不相提并论。相反，他们的顺序是（错误地）由决胜局决定的：

打印（并失败）：

造成这种情况的根本原因是什么？这通常是不可能的还是有错误？

我在一次采访中被问到这个问题，无法回答。

FB messenger 如何在两条消息同时出现时对用户侧的消息进行排序，以避免在聊天期间和用户再次访问 Messenger 时出现显示顺序的差异。我认为我们可以为每条消息存储一个时间戳，即服务器接收到消息的时间。但是，这并不能确保客户端消息的正确排序。

假设服务器时间戳无法确定消息的确切顺序，如下所示：

1. 用户 1 向用户 2 的服务器发送消息 M1。
2. 服务器在 T1 收到 M1。
3. 同时，User-2 为 User-1 发送消息 M2 到服务器。
4. 服务器在 T2 接收到消息 M2，使得 T2 > T1。
5. 服务器将消息 M1 发送给 User-2，将 M2 发送给 User-1。
6. 所以 User-1 会先看到 M1 然后是 M2，而 User-2 会先看到 M2 然后是 M1。

我读到解决了这个问题，我们可以使用矢量时钟，但无法理解在聊天期间和用户再次登录时如何为不同用户保留消息顺序。

在上述场景中，user1 将看到 M1 后跟 M2，而 user2 将看到 M2 后跟 M1。现在，如果每个用户还为每个客户端（单独）生成每个消息的序列号或时间戳。然后在上面的场景中，user1 将发送序列为 <1 (user1 seq), 0(user2 seq) > 的消息 M1，而 user2 将发送序列为 <0 (user1 seq), 1(user2 seq) > 的消息 M2。因此，当消息同时到达 user1 和 user2 时，它们将具有： M1 <1, 0> M2 <0, 1>

现在假设 user1 发送更多消息 M3 <2, 1> 和 M4 <3, 1> 那么每个客户端都会有以下消息。M1 <1, 0> M2 <0, 1> M3 <2, 1> M4 <3, 1>

因此，在这种情况下，当用户登录时，用户 1 和用户 2 在聊天期间的显示顺序将分别为 M1、M2、M3、M4 和 M2、M1、M3、M4。现在，我想知道再次登录时如何为用户 1 和用户 2 保留相同的顺序？

谢谢。

对分布式系统非常陌生，刚开始阅读 dynamo 论文4.4 Data Versioning，所以我的理解可能会偏离。

以doc中的例子为例，最后一步是将D3和D4调和到D5，但是如果用户只检索到D3怎么办（IIUC这是可能的，因为系统中有多个版本的数据徘徊，我不保证要检索 D3 和 D4，我什至可以读取 D1/D2），并且在不知道 D4 的存在的情况下，用户将 D3 更新为 D5，巧合的是，D5 也由 Sz（处理 D4）处理。它不是让 D5 看起来像 D4 的后代吗？：

D4([Sx,2],[Sz,1]) 与 D5([Sx,2],[Sy,1],[Sz,1])

但这是错误的，我描述的步骤是不可能的，或者矢量时钟有一些顺序要求？

我看到矢量时钟比线性历史日志携带更少的信息，即 ([Sx,2],[Sy,1]) 没有告诉我发生的动作的顺序，它可以扩展到不同的时间序列像 [Sx,Sy,Sx] 或 [Sy,Sx,Sx] 或 [Sx, Sx, Sy]？

矢量时钟的要点是确定哪个更新首先发生......如果一个密钥被更新两次以用于主从架构。

• 数据总是发送到主站，然后我们从主站发送到从站[所以主站会知道哪个是第一个]

• 但是假设主服务器宕机了，那么其中一个从服务器将成为主服务器，主服务器将获取数据。现在，即使原始 master 在一段时间后 UP，原始 master 总是知道它有较旧的数据。

我认为只有在 Master-Master 架构中，当您使用散列进行复制时，您需要在网络崩溃期间使用矢量时钟。

这是真的？还是我误会了？