Go Analysis of strong consistency between cap principle and final consistency

In a football match, a player scored three goals in a game called a hat-trick (Hat-trick). In the distributed Data system, there is also a hat principle (cap theorem), but this hat is not a hat. There are three elements in the CAP principle:

• Consistency (Consistency)
• Availability (Availability)
• Partition tolerance (Partition tolerance)

The CAP principle means that these three elements can achieve at most two points at the same time, it is impossible to balance the three. Therefore, in the design of distributed architectures, trade-offs must be made. for distributed Data Systems, partition tolerance is the basic requirement , otherwise it loses its value. So designing a distributed Data system is a balance between consistency and usability. For most Web applications, there is no need for strong consistency, so sacrificing consistency for high availability is the direction of most distributed database products today.

Of course, at the expense of consistency, not completely regardless of data consistency, otherwise the data is chaotic, then the system availability is high distributed no good also no value. Sacrificing consistency, just no longer requires strong consistency in the relational database, but as long as the system can achieve final consistency , taking into account the customer experience, this final consistent time window, as far as possible to the user transparent, that is, the need to ensure "user-perceived consistency." Typically, with multiple asynchronous replication of data to achieve high system availability and eventual consistency of data, the time window for "user-perceived consistency" depends on when the data is replicated to a consistent state.

Final consistency (eventually consistent)

For consistency, it can be divided into two different perspectives from the client and server side. From the client side, consistency mainly refers to the problem of how the updated data gets when multiple concurrent accesses are being accessed. From the server side, it is how updates replicate across the system to ensure that the data is ultimately consistent. Consistency is due to the problem of concurrent read and write, so in understanding the consistency of the problem, it is important to consider the combination of concurrent read and write scenarios.

From the client's perspective, when multi-process concurrent access, the updated data in different processes how to obtain different policies, determine the different consistency. For relational databases, it is strong consistency to require that the updated data be visible to subsequent accesses. If you can tolerate any subsequent partial or full access, it is weak consistency . If the updated data is required after a period of time, it is final consistency.

The final consistency is based on the time and manner in which each process accesses data after the data has been updated, and can be divided into:

• Causal Coherence . If process a notifies process B that it has updated a data item, subsequent accesses to process B will return the updated value, and one write will guarantee the substitution of the previous write. Access to process C, which is non-causal to process a, adheres to the general final consistency rule.
• "Read your own written (read-your-writes)" Consistency . When process a updates a data item itself, it always accesses the updated value and never sees the old value. This is a special case of the causal consistency model.
• session Consistency . This is a useful version of the previous model, which places the process that accesses the storage system into the context of the session. As long as the session still exists, the system guarantees "read what you write" consistency. If a session is terminated due to some failure conditions, a new session is established and the system's guarantee does not continue to the new session.
• monotonic (monotonic) read consistency . If a process has already seen a value for a data object, any subsequent accesses will not return a value before that value.
• monotonic Write consistency . The system guarantees that the write sequence from the same process executes. If the system does not guarantee this degree of consistency, it is very difficult to program.

The different ways of final consistency above can be combined, for example, monotonic read consistency and read-write consistency can be implemented together. And from a practical point of view, the combination of the two, read their own updated data, and once read to the latest version will no longer read the old version, for the program development on this architecture, there will be a lot less extra trouble.

From the point of view of the server, how to distribute the updated data to the whole system as soon as possible, and reduce the time window to achieve the final consistency, is an important aspect to improve the usability and user experience of the system. For distributed Data Systems:

• Number of copies of n-data replication
• W-Update data is the number of nodes that need to guarantee write completion
• R the number of nodes to read when reading the data

If w+r>n, the write node overlaps with the Read node, then it is strong consistency. For example, a typical one-to-one synchronous replication of a relational database, n=2,w=2,r=1, is consistent regardless of whether the master or repository data is being read.

If w+r<=n, it is weak consistency. For example, for a primary and standby asynchronous replication of the relational database, n=2,w=1,r=1, if you read a standby, you may not be able to read the main library has been updated data, it is weak consistency.

For distributed systems, in order to ensure high availability, general settings are n>=3. Different n,w,r combinations are a balance between usability and consistency to suit different scenarios.

• If n=w,r=1, any one of the write nodes fails, it will result in write failure, so availability will be reduced, but because the data distribution of n nodes is synchronous write, it can guarantee strong consistency.
• If n=r,w=1, only one node is required to write successfully, write performance and availability are relatively high. However, processes that read other nodes may not be able to obtain the updated data and are therefore weakly consistent. In this case, if w< (n+1)/2 and the nodes that are written do not overlap, there will be a write conflict

Transferred from: http://www.blogjava.net/hello-yun/archive/2012/04/27/376744.html

See also: http://www.infoq.com/cn/news/2008/01/consistency-vs-availability

Go Analysis of strong consistency between cap principle and final consistency