我遇到了“强烈最终一致性”的概念。 它应该比“最终一致性”强，但弱于“强一致性”吗？有人可以用适用的例子解释这三个概念之间的差异吗？
http://en.wikipedia.org/wiki/Eventual_consistency#Strong_Eventual_Consistency http://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
非常感谢。
答案 0 :(得分：111)
免责声明：下面的文字应该让您大致了解最终一致性，强烈最终一致性和强一致性之间的差异。但它们在某种程度上过于简化了。所以带上一粒盐;）
首先要做的事情是：当我们谈论一致性时，我们指的是不同实体（节点）拥有自己的某些数据对象副本的场景。现在，冲突的出现是因为每个节点都可以更新自己的副本（例如，因为有客户端，每个都连接到某个节点，要求他们这样做），所以如果我从不同的节点读取数据，我会看到不同的值。这就是最终一致性（EC），强烈最终一致性（SEC）和强一致性（SC）发挥作用的地方。
最终一致性 可能会出现冲突，但节点会相互通信以解决这些冲突，因此他们会及时就最终价值达成一致。因此，如果在一段时间内没有对数据进行更多更改，那么所有节点都会在数据值中达成一致（即它们最终会同意），因此数据读者最终会看到相同的值。
示例：两个节点A和B（ nA 和 nB ）每个都有一个字符串副本，使用操作read()和{{进行更新1}}。假设每个人都有自己的客户端（ cliA 和 cliB ）。假设最初两个节点都存储相同的值“Joe”，但在某些时刻 nA 将其更新为“Frank”（调用write(string)）。然后 nA 将告诉 nB 该值已更新;由于两个值不同，冲突已经出现，但可以使用某些策略（例如last-write-wins）解决，因此 nB 最终也将其记录更新为“Frank”。在解决冲突之前 cliA 和 cliB 会看到不同版本的数据（write("Frank")操作结果会有所不同），但最终两者都会看到相同的值试。
请记住，如果两个节点同时更新其值，则仍然可以进行冲突解决，但更复杂。这就是SEC闪耀的地方。
强烈的最终一致性 这是EC的一个特例，仅对某些数据类型有效。
假设共享的数据对象是计数器，并且read()和add(int value)操作进行更新。在这种情况下，我们应用更新的顺序无关紧要！因此，如果 nA 和 nB 都以计数器值0开始，如果nA运行substract(int value)且 nB 运行{{ 1}}（同时），他们只需要在不关心冲突解决的情况下相互发送更新操作，最终确保它们将达到相同的值（请记住，相比之下，在前面的示例中针对EC的一些冲突可能需要解决方案）！
不幸的是，SEC仅适用于具有特定属性（交换性和其他）的某些数据类型和操作。此类数据类型表示为无冲突复制数据类型（CRDT）。
一致性强
与其他两个完全不同。这里要求在更新操作之后，在使新值对客户端可见之前，所有节点都同意新值。这样，所有客户端同时都可以看到更新，因此他们将始终读取相同的值。现在，这引入了对更新操作中的一些阻塞的要求。在EC和SEC中，一旦更新本地副本（然后将操作广播到其他节点），更新操作就结束了。这里客户端更新不会返回，直到所有节点都同意数据值，并且在完成此操作时，对该数据的任何副本的所有访问都被“锁定”（因此阻止其他客户端读取）。在我们的EC示例中，如果 cliA 运行add(10)， cliA 将被阻止，直到 nA 和< em> nB ，然后它会同时显示 cliA 和 cliB ，即substract(5)操作应该返回相同的从那时起的价值。