distributed-computing - "Eventual Consistency"对比 "Strong Eventual Consistency"对比 "Strong Consistency"?

Question

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

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

非常感谢。

Answer 1

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

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

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

示例:两个节点 A 和 B(nA 和 nB)各有一个字符串副本，该字符串通过操作 read() 更新和 write(string) .假设每个人都有自己的客户端(cliA 和 cliB)。假设最初两个节点存储相同的值“Joe”，但在某个时刻 nA 将其更新为“Frank”(调用 write("Frank"))。然后nA会告诉nB值已经更新了；由于两个值不同，因此出现了冲突，但可以使用某些策略(例如最后写入获胜)来解决，因此 nB 最终也将其记录更新为“弗兰克”。在冲突解决之前，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()从那时起，操作应该返回相同的值。