CAP

CAP theory is a commonplace theory in distributed systems. It was first proposed by Eric Brewer in a lecture. In this lecture, the analogy between the traditional ACID theory and the popular but abstract design guiding theory BASE theory (at that time BASE theory was still very abstract, until several years later a more authoritative and widely accepted BASE theory complete explanation and design) was put forward

  • C(Consistency) : In a distributed system, whether all backups of the same data have the same value at the same time. That is, if you read and write the same data, you immediately see consistent results for all copies. A common strong consistency implementation is where write requests are not returned and read requests block or time out until a consistent result is seen.
  • A: When some nodes in the cluster fail, the cluster can still respond to read and write requests.
  • P(partition-tolerance) : A distributed system has multiple nodes. If the network between nodes is interrupted, partitioning will occur.

Moreover, it is pointed out that CAP can not satisfy all, but generally choose two

Later, In a Notes article, Seth Gilbert and Nancy Lynch showed that CAP cannot be all at once. In addition, CAP should be defined more clearly:

  • C: Atomic consistency is required, that is, any read and write is atomic, that is, for the same data written after the read, must be able to read the value, that is, the latest value
  • A: For all successful requests, they need to be returned within A limited time, that is, the successful request is valid and terminable.
  • P: Some messages may be lost during transmission between nodes.

The CA system

A system that does not allow partitioning is not a distributed system, but a stand-alone system. For example, a single-server database, ora shared storage database, such as the Aurora DB, is designed to share the same storage. Different MySQL processes are created on it. One MySQL reads and writes, and the other reads only. Meeting the transaction characteristics of ACID ensures strong consistency, as well as availability.

The CP system

That is, a system that does not require high availability but requires strong consistency does not allow data inconsistency to occur even if services are unavailable. Also, if the transmission between nodes is lost and the synchronization is not successful, either retry or return the update failed and roll back the update request.

A practical application of CP is distributed locking. In general, if a lock is not acquired or fails to be acquired, we will choose to block and wait, or directly fail, rather than run the risk of concurrency. In addition, the distributed lock must keep the lock status of all nodes consistent. Otherwise, it is considered that the lock acquisition fails.

At the same time, most distributed databases are CP systems, but their conformance protocol schemes are different, common examples are Paxos, 2PC, 3PC, RAFT, etc.

The AP system

That is, requiring high availability, but not a strongly consistent system. In this case, once partitioning occurs, data may be inconsistent between nodes, and each node continues to provide services with its own local data. In this case, data inconsistency may occur, and the system will generally achieve final consistency. That is, after the partition is over, the data is synchronized through some mechanism.

Basically has the multilayer cache system, is the AP system design. Examples include DNS, client caching, browser caching, and in-process caching.

A CP versus an AP system

A classic example is Zookeeper as a registry and Eureka as a registry.

Suppose the registry has two interfaces, one for registering instances and one for reading instances.

If Zookeeper is used as the registry, half write and 2 PC synchronization are used for registered instance requests, that is, update requests.

The registration request succeeds only if more than half of the 2PCS are updated, in which case each node read the update request, otherwise the updated nodes will be rolled back. And the data is consistent for each node. If more than half of the nodes are unavailable, the entire cluster cannot process requests to register an instance or to read an instance. This ensures strong consistency, but reduces availability.

If Eureka is used as the registry, a registration request is sent to an Instance of Eureka, which is then forwarded to other Eureka nodes in the cluster.

Updates will not be rolled back even if some nodes fail. In addition, no matter which Eureka in the cluster is down, other normal Eureka services will not be affected, although the old data may be read, and some data inconsistency.

Current CAP theory

As the technology continues to evolve and the theory continues to improve, we find that partitioning is not always the case, and in most cases, if we ignore P, it is actually the case that CA can coexist. If the partition is perceived, we can plan responses ahead of time, such as limiting certain operations by entering service degradation and correcting data inconsistencies with recovery compensation logic.

The PACELC theory, which evolved from the CAP, is a more practical guide to this situation. In the case of zoning, take the first half, which is still CAP theory. If partitioning does not occur, which is most of the time, we consider the trade-off between L (Latency) and C (Consistency).

Wechat search “my programming cat” to follow the public account, every day, easy to improve technology, win a variety of offers