“最终一致性”；与“强大的最终一致性”与“强一致性”？ [英] "Eventual Consistency" vs "Strong Eventual Consistency" vs "Strong Consistency"?

问题描述

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

I came across the concept of "Strong Eventual Consistency" . Is it supposed to be stronger than "Eventual Consistency" but weaker than "Strong Consistency"? Could someone explain the differences among these three concepts with applicable examples?

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

非常感谢。

推荐答案

免责声明：以下文字应让您大致了解最终一致性，强最终一致性和强一致性之间的区别。但是它们在某种程度上过于简化了。因此，请带上一粒盐；）

DISCLAIMER: The text below should give you a rough idea about the differences among Eventual Consistency, Strong Eventual Consistency and Strong Consistency. But they are in some way an over-simplification. So take them with a grain of salt ;)

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

First things first: when we talk about consistency we refer to an scenario where different entities (nodes) have their own copy of some data object. Now, conflicts arise because each node can update its own copy (e.g. because there are clients, each one connected to some node, asking them to do so), so if I read the data from different nodes I'll see different values. This is where Eventual Consistency (EC), Strong Eventual Consistency (SEC) and Strong Consistency (SC) come into play.

最终一致性
可能会发生冲突，但是节点相互交流自己的更改以解决这些冲突，因此他们及时就确定的价值达成了共识。因此，如果在一定时期内没有对数据进行任何更改，则所有节点将在数据值上达成一致（即，他们最终将达成一致），因此数据的读取者最终将看到相同的值。

Eventual Consistency Conflicts can arise, but nodes communicate each other their changes to solve those conflicts, so in time they agree upon the definitive value. Thus, if no more changes are applied to the data for a certain period, then all nodes will agree in the data value (i.e. they will eventually agree) so readers of data will eventually see the same value.

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

Example: two nodes A and B (nA and nB) have each one copy of a string, which is update with operations read() and write(string). Let's say each one has its own client (cliA and cliB). Let's say that initially both nodes store the same value "Joe", but at some moment nA updates it to "Frank" (calls write("Frank")). Then nA will tell nB that the value has been updated; as both values differ a conflict has arisen but in can be solved using some policy (for example last-write-wins) so nB finally updates its record also to "Frank". Before the conflict is resolved cliA and cliB will see different versions of the data (the read() op result will differ), but eventually both will see the same value again.

请记住，如果两个节点同时更新其值，则仍然可以解决冲突，但更为复杂。

Keep in mind that if both nodes update their value simultaneously then conflict resolution is still possible but more complicated. This is where SEC shines.

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

Strong Eventual Consistency This is a special case of EC, that is valid only for certain data types.

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

Let's assume that the data object shared is a counter, and updates are made by add(int value) and substract(int value) operations. In this case, the order in which we apply updates does not matter! So if both nA and nB start with a counter value of 0, and if then nA runs add(10) and nB runs substract(5) (simultaneosly), they only need to send the update operation to each other without caring for conflict resolution, eventually it is ensured that they will reach the same value (remember that, in contrast, in the previous example for EC some conflict resolution could be required)!

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

Unfortunately SEC is only applicable in certain data types and operations that have specific properties (commutativity and others). Such data types are denoted Conflict-free Replicated Data Type (CRDT) .

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

Strong consistency Quite different to the other two. Here it is a requirement that upon update operations all nodes agree on the new value before making the new value visible to clients. That way updates are visible to all clients 'at the same time', so they will read the same value at all times. Now this introduces the requirement for some blocking in update operations. Both in EC and SEC an update operation was over as soon as the local copy was updated (then the operation was broadcasted to the other nodes). Here a client update does not return until all nodes have agreed upon the data value, and while this is done all accesses to any copy of that data are 'locked' (so other clients reads are blocked). In our example for EC, if cliA runs write("Frank"), cliA will be blocked until the update is agreed by both nA and nB, and then it will made visible for both cliA and cliB at the same time, i.e. the read() operation should return the same value from then on.

这篇关于“最终一致性”；与“强大的最终一致性”与“强一致性”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！