关于“Designing Data-Intensive Applications - CHAPTER 5 Replication - Leaderless Replication”的疑问

[JasonLaw]

在“Designing Data-Intensive Applications - CHAPTER 5 Replication - Leaderless Replication - Limitations of Quorum Consistency”中，它说：

However, even with w + r > n, there are likely to be edge cases where stale values are returned. These depend on the implementation, but possible scenarios include:

• ...
• If a write succeeded on some replicas but failed on others (for example because the disks on some nodes are full), and overall succeeded on fewer than w replicas, it is not rolled back on the replicas where it succeeded. This means that if a write was reported as failed, subsequent reads may or may not return the value from that write.
• ...

它说后续的读可能会返回写入失败的值，是类似下面这样的情况吗？

假设 n 为 5，w 和 r 都是 3 。键 k 的初始化值为 1 。

client 1 执行 set k = k + 1 写，这个写只在两个副本（ replica 1 和 replica 2 ）成功，所以是失败的。

client 2 读取键 k 的值，它在 replica 1 和 replica 2 中读取到 2，而在 replica 3 读取到 1，所以 client 2 会被告知键 k 的值为 2 。

我的疑问

1. 上面的理解对吗？如果是这样子，不就相当于读取到了错误的值吗？
2. 复制是怎么操作的呢？按照道理最后所有副本里面的值应该是 1 才对，但是具体是怎么操作的呢？ replica 1 和 replica 2 是怎么知道应该使用 1 来覆写 2 的呢？ replica 3-5 又是怎么知道 2 是失败的写，从而继续保留 1 的呢？

[limboMu]

我刚刚看完本书，我来说说我的理解吧，首先我认为复制并不是单纯的值复制，而是一个操作事件的全序列复制，这样就可以在同一个 replica 中知道使用哪个值来来覆盖，至于 replica3-5 有可能是就没收到写入。也有可能是因为延迟，总之集群返回了一个统一的值。可能这也是 leaderless replication 没法保证强一致性的原因之一。还有就是有的 leaderless replication 是有一个错值回改的操作。

[JasonLaw]

@limboMu #1 可以具体解释一下以下两点吗？我不太明白你想表达的意思。

1. 这样就可以在同一个 replica 中知道使用哪个值来来覆盖，至于 replica3-5 有可能是就没收到写入。也有可能是因为延迟，总之集群返回了一个统一的值。可能这也是 leaderless replication 没法保证强一致性的原因之一。（具体解释这一整段，可以的话，用例子描述一下）
2. 还有就是有的 leaderless replication 是有一个错值回改的操作。（可以具体解释以下错值回改吗？）

[limboMu]

首先说，你的问题两种情况都是要看具体实现的。我查了一下错值回改的学名叫 Read repair&Anti-entropy process 是说因为故障原因落后的副本会在连接后去更新自身的数据。用你的例子来说吧，你的例子实际上是仲裁一致性的边缘情况，client1 写成功了 replica1 -2，replica 3-5 还是维持原值 但是后续 client2 再次读取的时候如果是 5 个 replica 都是好的，就可以仲裁一直为 1 。如果其中的 replica4-5 没有响应 read 请求，这是你例子的情况，这种情况具体能不能算作仲裁一致，就完全看实现了，无主复制的边缘情况时候导致错误值的出现。 出处你可以参考一下无主复制仲裁一致的局限性那一节