NOTE

1.7 CAP

1. Why CAP Exists - A distributed system has multiple nodes, and state needs to be synchronized among the nodes. This requires support from CAP theory. 2. What Is CAP - Only two of the three can be chosen. 2.1. C (Consistency) - Consistency. - A read after a write must return that value. When data is distributed across multiple nodes, the data read from any node must be that value.

Distributed SystemsCreated Updated 2 min readhistorical

This is a historical learning note and may contain outdated or incomplete understanding.

1. Why Does CAP Exist?

A distributed system has multiple nodes, and state needs to be synchronized among the nodes. This requires support from CAP theory.

2. What Is CAP?

Only two of the three can be chosen.

2.1. C (Consistency)

Consistency.

A read after a write must return that value. When data is distributed across multiple nodes, the data read from any node must be that value.

2.1.1. Example

The value of data X in regions A and B is v0. A user writes v1 for X in region A. At this point, if the user reads X from region B, the value must also be v1.

2.1.2. Implementation

  1. When writing to the primary database, it needs to synchronize to the replica database.
  2. Locking is required during synchronization to prevent old data from being read.

2.1.3. Characteristics

  1. Because there is a data-synchronization process, write operations have latency.
  2. Resources are locked and access is not allowed.

2.1.4. Consistency Model

Distributed Consistency Models

2.2. A (Availability)

Availability.

As long as a user request is received, a response must be given. There will be no timeout or error.

2.2.1. Example

2.2.2. Implementation

  1. When writing to the primary database, it needs to synchronize to the replica database.
  2. Locking cannot be used during synchronization; access is allowed and old data can be obtained.

2.2.3. Characteristics

  1. Old data may be read.
  2. Request timeouts or errors will not occur.

2.2.4. Availability Model

Distributed-System Replication

2.3. P (Partition Tolerance)

Partition tolerance.

The nodes of a distributed system are distributed across multiple subnetworks, and each subnetwork is called a partition. Partition tolerance means that communication between network partitions may fail.

From the definition of P, it can be seen that it always holds, or in other words, it cannot be avoided.

2.3.1. Example

One server is placed in China and another server is placed in the United States. These are two partitions, and they may be unable to communicate with each other.

2.3.2. Implementation

  1. Use asynchronous processing instead of synchronous processing.
  2. Add replica nodes.

2.3.3. Partitioning Model

Distributed-System Partitioning

3. Why CA Conflicts

To maintain consistency, when region A performs a write, reads and writes in region B must be locked until data synchronization finishes.

To maintain availability, when region A performs a write, region B cannot be locked.

4. Choosing Two of the Three in CAP

4.1. AP

Give up consistency and pursue partition tolerance and availability.

Eventual consistency is generally implemented (the extension of AP, BASE theory). For example, an order refund succeeds today and the funds arrive in the account tomorrow.

4.2. CP

Give up availability and pursue consistency and partition tolerance.

For example, in an interbank transfer, when one side is debited, the other side must be credited.

4.3. CA

Give up partition tolerance and pursue consistency and availability.

This is equivalent to having only one machine and is not a distributed system. For example, a database.

5. References

Discussion

Sign in with GitHub to comment. Discussions are stored as GitHub Issues.View on GitHub