"最终一致性"与"强烈最终一致性"与"强一致性"？

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该值已更新; 由于两个值不同,冲突已经出现,但是可以使用某种策略(例如,last-write-wins)来解决,因此nB最终也将其记录更新为"Frank".在冲突解决之前,cliA和cliB将看到不同版本的数据(read()运算结果会有所不同),但最终两者都会再次看到相同的值.

请记住,如果两个节点同时更新其值,则仍然可以进行冲突解决,但更复杂.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()操作应返回相同的值然后.