[Java] Distributed CAP principle

Introduction to CAP principles

  The CAP principle, also known as the CAP theorem, refers to consistency, availability, and partition tolerance in a distributed system. The CAP principle means that these three elements can only achieve two points at the same time, and it is impossible to balance the three.

Three indicators of CAP

  

  Consistency

  "All nodes see the same data at the same time", that is, after the update operation is successful and returns to the client, the data of all nodes at the same time is completely consistent, which is distributed consistency. The problem of consistency is inevitable in concurrent systems. For clients, consistency refers to the problem of how to obtain updated data during concurrent access. From the perspective of the server, it is how to update the distribution to the entire system to ensure that the data is eventually consistent

  Availability

  Availability refers to "Reads and writes always succeed", that is, the service is always available and the normal response time. Good usability mainly refers to that the system can serve users well, and there is no user experience failure such as user operation failure or access timeout.

  Partition tolerance

  That is, when a distributed system encounters a node or network partition failure, it can still provide services that meet consistency or availability.

Proof of CAP theorem

  The following explains why the three elements of the CAP principle can only achieve at most two points at the same time, and it is impossible to balance the three.

  Suppose there is a client C, user A, and two servers. Two identical service nodes S1 and S2 are deployed, and the stored data are all V0. The network between them can communicate with each other, which is equivalent to two of the distributed system. Sections.

  

  Operating procedures

  1. Client A updated the data V1 to S1

  2. This message from the S1 node tells the S2 node that the S2 page wants to update the data, but a network failure has occurred, and the V2 is still saved in S2.

  3. The client requests data from S2, and S2 returns V0 data

  analysis

  (1) The system network fails, but the system is still accessible, so it is fault-tolerant.

  (2) When client A accesses node S1, V0 to V1 is changed. When client A accesses node S2, it is V1. Therefore, it is necessary to wait for the network failure to recover and update the data of S2 node.

  (3) It is impossible for the system to meet the availability during the period of network failure recovery. Because the availability requirements are correct and effective to access the system anytime, anywhere. This is a contradiction.

  It is this contradiction that the three characteristics of CAP must not be satisfied at the same time. Since we are not satisfied, then we will make a choice.  

  There are two options:

    First, sacrifice data consistency and respond to the old data V0 to the client;

    Second, at the expense of availability, blocking and waiting until the network connection is restored, and after the data update operation is completed, the user is responded to the latest data V1.

Trade-off strategy

  CA without P : If P (partitioning is not allowed) is not required, C (strong consistency) and A (availability) can be guaranteed. But giving up P at the same time means giving up the scalability of the system, that is, the distributed nodes are limited, and there is no way to deploy child nodes, which is contrary to the original intention of the distributed system design.

  CP without A : If A (available) is not required, it means that each request needs to be strongly consistent between servers, and P (partition) will cause the synchronization time to be infinitely extended (that is, wait for the data synchronization to complete normal access to the service) Once a network failure or message loss occurs, you must sacrifice the user's experience and wait for all data to be consistent before allowing users to access the system. There are actually many systems designed as CPs. The most typical ones are distributed databases such as Redis and HBase. For these distributed databases, data consistency is the most basic requirement, because if even this standard is not met, then it is good to directly use a relational database, and there is no need to waste resources to deploy distributed databases.

  AP wihtout C : To be highly available and allow partitioning, you need to give up consistency. Once partitioning occurs, the nodes may lose contact. For high availability, each node can only use local data to provide services, and this will lead to inconsistencies in global data. A typical application is like a rush-purchase mobile phone scenario of a certain meter. You may be prompted to have inventory when you browse the product a few seconds ago. When you have selected the product and ready to place an order, the system will prompt you that the order has failed and the product has been sold . This is actually to ensure the normal service of the system in A (availability), and then make some sacrifices in data consistency. Although it will affect some user experience, it will not cause serious blockage of the user's shopping process.

  Generally speaking, partition fault tolerance cannot be avoided, so it can be considered that P of CAP always holds. The CAP theorem tells us that the remaining C and A cannot be done at the same time.

Guess you like

Origin www.cnblogs.com/h--d/p/12678118.html