“最终一致性”与“强最终一致性”与“强一致性”？

Posted 2023-02-16

【中文标题】“最终一致性”与“强最终一致性”与“强一致性”？

【英文标题】："Eventual Consistency" vs "Strong Eventual Consistency" vs "Strong Consistency"?

【发布时间】：2015-06-05 13:09:22

【问题描述】：

我遇到了“强最终一致性”的概念。 它是否应该比“最终一致性”强但比“强一致性”弱？有人可以用适用的例子解释这三个概念之间的区别吗？

http://en.wikipedia.org/wiki/Eventual_consistency#Strong_Eventual_Consistency http://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

非常感谢。

【参考方案1】：

免责声明：下面的文字应该让您大致了解最终一致性、强最终一致性和强一致性之间的区别。但它们在某种程度上过于简单化了。所以带上一粒盐吧;)

---

第一件事：当我们谈论一致性时，我们指的是不同实体（节点）拥有自己的某些数据对象副本的场景。现在，冲突出现是因为每个节点都可以更新自己的副本（例如，因为有客户端，每个客户端都连接到某个节点，要求他们这样做），所以如果我从不同节点读取数据，我会看到不同的值。这就是最终一致性 (EC)、强最终一致性 (SEC) 和强一致性 (SC) 发挥作用的地方。

最终一致性 可能会出现冲突，但节点会相互交流他们的更改以解决这些冲突，因此它们及时就最终值达成一致。因此，如果在一段时间内不再对数据应用任何更改，那么所有节点将在数据值上达成一致（即它们最终会达成一致），因此数据的读者最终将看到相同的值。

示例：两个节点 A 和 B（nA 和 nB）各有一个字符串副本，通过操作 read() 和 write(string) 进行更新。假设每个人都有自己的客户端（cliA 和 cliB）。假设最初两个节点存储相同的值“Joe”，但在某个时刻 nA 将其更新为“Frank”（调用 write("Frank")）。然后nA会告诉nB这个值已经更新了；由于两个值不同，因此出现了冲突，但可以使用某些策略（例如 last-write-wins）解决，因此 nB 最终也将其记录更新为“Frank”。在冲突解决之前，cliA 和 cliB 将看到不同版本的数据（read() op 结果会有所不同），但最终两者都会再次看到相同的值。

请记住，如果两个节点同时更新它们的值，那么冲突解决仍然是可能的，但更复杂。这就是 SEC 大放异彩的地方。

强大的最终一致性 这是 EC 的一种特殊情况，仅对某些数据类型有效。

假设共享的数据对象是一个计数器，更新由add(int value) 和substract(int value) 操作进行。在这种情况下，我们应用更新的顺序无关紧要！因此，如果 nA 和 nB 都以计数器值 0 开始，然后如果 nA 运行 add(10) 并且 nB 运行 substract(5) (同时），他们只需要相互发送更新操作而不关心冲突解决，最终确保它们达到相同的值（请记住，相比之下，在前面的 EC 示例中，可能需要一些冲突解决)！

不幸的是，SEC 仅适用于具有特定属性（交换性和其他）的某些数据类型和操作。此类数据类型表示为无冲突复制数据类型 (CRDT)。

一致性强 和另外两个完全不同。这里要求在更新操作时，所有节点在新值对客户端可见之前就新值达成一致。这样，所有客户端“同时”都可以看到更新，因此它们将始终读取相同的值。现在这引入了对更新操作中的一些阻塞的要求。在 EC 和 SEC 中，更新操作在本地副本更新后立即结束（然后该操作被广播到其他节点）。在所有节点都同意数据值之前，客户端更新不会返回，并且在完成此操作时，对该数据的任何副本的所有访问都被“锁定”（因此其他客户端读取被阻止）。在我们的 EC 示例中，如果 cliA 运行 write("Frank")，则 cliA 将被阻止，直到 nA 和 都同意更新nB，然后它将同时对 cliA 和 cliB 可见，即read() 操作应该从那时起返回相同的值.

【讨论】：

解释清楚，谢谢！

一个很好的描述，漂亮！

澄清一下，强一致性只需要所有节点都同意当前值。在写入发生时节点阻止读取并不是必需的，它们反而会导致写入延迟。基本上，写入将处于挂起状态，直到所有节点都同意一致地使用新值。

我是否理解正确，如果副本节点关闭，则无法实现强一致性 - 根据定义？也就是说分布式系统不能同时保证容错和强一致性？

嗨，阿列克谢。即使一个节点宕机了，如果剩下的节点还能达成一致，那么仍然认为是强一致性。不幸的是，如果可能发生崩溃（即现实世界），那么一致性就很棘手。我建议看看这些幻灯片：cs.princeton.edu/courses/archive/spr11/cos461/docs/… 最后一张幻灯片展示了分布式系统中实际可能发生的事情。可以看到 Paxos alg 允许强一致性 + 分区容错。只要 F+1 个节点仍在运行，它最多可以处理 F 个崩溃的节点。