Theory of CAP
What is the CAP?
- C stands for Consistency. Consistency means that data on all service nodes is consistent at the same time
- A stands for Availability means that all requests must be responded to
- Fault tolerance refers to the ability of a service node in a distributed system to provide satisfactory services even if the network Partition fails
In any distributed system, CAP cannot be met at the same time, and fault tolerance of partition must be guaranteed, so C and A can only be chosen
CA: Single-point clustering, satisfying consistency and availability, but not very scalable. CP(Zookeeper/ Consul) : a system that meets the requirements of consistency and partition tolerance has low performance. AP(Eureka) : a system that meets the requirements of consistency and partition tolerance, usually with low performance.
CAP theory focuses on the granularity of data rather than the overall design strategy of the system
Why can’t both C and A satisfy?
If to ensure the consistency, a service node to write operation, one of the data to other data is locked, speaking, reading and writing, such as only write operation is finished, complete the data synchronization, to let go, during the lock, the data for other service node is not available, so there is no guarantee that the data availability
On the other hand, if availability is to be guaranteed, other nodes cannot be locked when a node is writing. At this time, another node may request to obtain the data, so other nodes may read the old data, so consistency cannot be guaranteed
- Zookeeper ensures CP
- Eureka can guarantee AP
- Nacos supports switching between CP and AP modes
Comparison of service registries
Spring Cloud supports registries such as ZooKeeper, Eureka, Nacos, Consul.
