Distributed Transaction --- CAP theory

Section of this article from Resources! ! Original half

Outline

       CAP introduced the theory, and simply to prove existence of three two inconclusive.

CAP theory

       In 1998, a computer scientist at the University of California, Eric Brewer proposed a distributed system has three indicators. They are as follows:

    • Consistency (Consistency)
    • Availability (availability)
    • Partition tolerance (partitions fault tolerance)

       These three elements will not be satisfied at the same time. The following figure shows the two functions now have many implementations of distributed transactions.

CAP theory

     Here we will introduce these three elements, we first look at a simple distributed system.

 

cap1

     The client is connected to two servers, G1, and G2, while the two server maintains a vo of this variable, the client can initiate functions to read and write to the server. For example read

cap_write

     Also wrote:

CAP_read

      Let's check the three principles.

Fault-tolerant partition

       Partitions fault tolerance, specific meanings are as follows:

the network will be allowed to lose arbitrarily many messages sent from one node to another

      Nguyen teacher's article cited such examples.

Most distributed systems are distributed across multiple sub-networks. Each subnetwork is called a zone (partition). Fault-tolerant partition mean, range communication may fail. For example, a server in China, another server in the United States, which is the two areas could not communicate between them.

      Fault-tolerant partition scenes like this.

p

consistency

         Consistency is well understood, we know Mysql read and write separation, in many cases is a main library service writes from multiple synchronized from the library, then there is access to the replication process of synchronization from the library, the user from the library, which had written into numerical inconsistent, then there is no guarantee consistency. Here it is to ensure the consistency of the situation. 

cap_a

Availability

          As long as the user's request is received, the server must be given a response. Users can choose to G1 or G2 initiate a read operation. No matter which server, as long as the request is received, it must tell the user, in the end it is v0 or v1, or do not meet the availability.

prove

Excerpt from teacher logical proof Ruan Yifeng article, see reference source article

      Consistency and availability, why can not simultaneously set up? The answer is simple, because there may be a communication failure (fault-tolerant partition appears).

      If ensure consistency G2, then G1 must be on a write lock G2 read and write operations. Only after data synchronization, to re-open to read and write. During the lock, G2 can not read and write, there is no availability is not.

      If you ensure the availability of G2, it is bound G2 can not be locked, so consistency is not established.

      In summary, G2 consistency and availability can not be done at the same time. You can only select a target system design. If the pursuit of consistency, we can not guarantee the availability of all nodes; if the pursuit of availability of all nodes, it can not do consistency.

 

Many cases

Sacrifice consistency

        Availability and fault tolerance reserved partition, such as publishing a page to the CDN, multiple servers have a copy of this page. Later found an error and needs to update the page, then each server can only update again. In general, the page is not updated with special emphasis on consistency. Short period of time, some users get older, some users get the new version, the problem is not particularly large. Of course, everyone will eventually see the new version. So, on this occasion is the availability of higher consistency.

Sacrificing usability

       Reserved partition consistency and fault tolerance, from the above proof we can also know that in order to maintain consistency, data requirements must be accurate scene, you can see MonoDB and redis is at the expense of usability, thus ensuring consistency and partitions fault tolerance .

Availability sacrifice partition

        Give up partitions fault tolerance, greater consistency and usability, in fact, it is to choose the traditional stand-alone database.

to sum up

      Through the above study we know that the CAP theory, know the distributed transaction can only be guaranteed in most cases there are two elements, but due to network delay and other reasons, fault-tolerant partition is an objective fact that can not be avoided, so people pay more efforts towards consistency and availability.

Reference material

Guess you like

Origin www.cnblogs.com/Benjious/p/11266874.html