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

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最终也将其记录更新为"Frank“。在冲突解决之前，cliA和cliB将看到不同版本的数据( read()操作结果将不同)，但最终两者将再次看到相同的值。

请记住，如果两个节点同时更新它们的值，那么冲突解决仍然是可能的，但会更加复杂。这就是SEC的闪光点。

强最终一致性这是EC的一个特例，仅对某些数据类型有效。

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

不幸的是，SEC仅适用于具有特定属性(交换性等)的特定数据类型和操作。这样的数据类型被表示为无冲突复制数据类型()。

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