1. The theory of the CAP

CAP theory/theorem originated in 2000 and was proposed by Professor Eric Brewer of University of California Berkeley in the Seminar on Distributed Computing Principles (PODC). Therefore, CAP theorem is also called Brewer’s Theorem.

1.1 introduction

CAP is an acronym for Consistency, Availability and Partition Tolerance.

In theoretical computer science, CAP theorem states that for a distributed system, read and write operations can only be designed to satisfy two of the following three points:

  • Consistence: All nodes access the same latest copy of data
  • Availability: Non-failed nodes return reasonable responses (not error or timeout responses) in a reasonable amount of time.
  • Partition tolerance: Distributed systems can still provide services against network partitions.

1.2 Network Zones

In a distributed system, the network of multiple nodes was originally connected, but due to some faults (such as some node network problems) some nodes are not connected, the whole network is divided into several areas, which is called network partition.

There are three options for distributed CAP theory, which is based on the fact that only ONE of C (consistency) and A (availability) can be met when P (network partition) occurs. It is theoretically impossible for distributed system to choose CA architecture, but CP or AP architecture. If the system does not “partition”, the network connection between nodes communication is normal, there is no P. At this point, we can guarantee both C and A.

Why can’t both C and A be guaranteed when network partitioning occurs?

When a network partition occurs, some nodes are disconnected, and data synchronization will be delayed. If high availability is required, data consistency cannot be guaranteed when access to faulty nodes on the network. In the same way, high availability cannot be guaranteed when data synchronization is required.

1.3 Practical application cases of CAP

I will use the registry to explore the practical application of CAP

The registry is responsible for the registration and lookup of service addresses, which is equivalent to a directory service. Service providers and consumers only interact with the registry at startup, and the registry does not forward requests, which is less stressful.

Common components that can serve as registries are: ZooKeeper, Eureka, and Nacos.

  1. Eureka guarantees AP. Eureka is designed to ensure A (availability) first. There are no Leader nodes in Eureka; each node is equal and equal. So Eureka won’t be unavailable during elections or when more than half of the machines are unavailable, as ZooKeeper is. Eureka guarantees that the failure of most nodes will not affect normal service delivery, as long as only one node is available. It’s just that the data on this node may not be up to date.
  2. Nacos supports both CP and AP.
  3. ZooKeeper guarantees CP. Read requests to ZooKeeper are consistent at any time. However, ZooKeeper does not guarantee the availability of each request. For example, the service is unavailable during the Leader election process or when more than half of the machines are unavailable.

2. The BASE theory

BASE theory originated in 2008 and was published by eBay architect Dan Pritchett at the ACM.

2.1 introduction

BASE is an acronym for Basically Available, soft-state, and Eventually Consistent. BASE theory is the result of balancing consistency C and availability A in CAP. It comes from the summary of distributed practice of large-scale Internet system and is gradually evolved based on CAP theorem, which greatly reduces our requirements on the system.

1.2 Core ideas of BASE theory

Even if strong consistency cannot be achieved, each application can adopt appropriate methods to achieve final consistency according to its own service characteristics.

In other words, the high availability of the system is achieved at the expense of strong data consistency. If some data in the system is unavailable or inconsistent, the system as a whole must be mainly available.

**BASE theory is essentially an extension and supplement to CAP, and more specifically, a supplement to AP scheme in CAP. **AP schemes give up consistency only when partitioning occurs, not forever. After the partition recovers from failure, the system should achieve final consistency. This is actually where the BASE theory extends.

1.3 Three elements of BASE Theory

1.3.1 Basic availability

Basic availability is the ability of a distributed system to allow a partial loss of availability in the event of unforeseen failures. However, this is by no means equivalent to the system being unavailable.

What does it mean to allow partial loss of availability?

  • Loss in response time: Normally, it takes 0.5 seconds to process a user request, but due to a system failure, the time to process a user request becomes 3 seconds.
  • Loss of system functions: Under normal circumstances, users can use all functions of the system, but some non-core functions of the system cannot be used due to the sudden increase of system visits.

1.3.2 soft state

Soft state refers to allowing the existence of intermediate states (data inconsistency in CAP theory) of data in the system, and considering that the existence of such intermediate states will not affect the overall availability of the system, that is, allowing the system to delay the process of data synchronization between data copies of different nodes.

1.3.3 Final Consistency

Final consistency emphasizes that all copies of data in the system can eventually reach a consistent state after a period of synchronization. Therefore, the essence of final consistency is that the system needs to ensure the consistency of the final data, rather than ensuring the strong consistency of the system data in real time.

There are three levels of distributed consistency:

  1. Strong consistency: What the system writes is what it reads.
  2. Weak consistency: It does not guarantee that the latest written value can be read, nor does it guarantee how long it will take to read the latest data. It only ensures that the data is consistent at some point in time.
  3. Final consistency: An improved version of weak consistency. , the system will ensure to achieve data consistency within a certain period of time,

The final consistency level is preferred by the industry, but some scenarios that require very strict data consistency, such as bank transfers, still require strong consistency.