The well-known CAP theory requires that P (partition fault tolerance) must be guaranteed in a distributed system . Since the CAP theory cannot guarantee that the three are satisfied at the same time, it can really weigh the remaining C (consistency) and A (availability) .
It's not CP, it's AP.
Zookeeper satisfies CP . In a distributed environment, network failures are inevitable. When a failure occurs, zookeeper, in order to ensure node data consistency, when a master node goes down, the remaining nodes will conduct leader elections.
In this process, it is not possible to provide services to other nodes, and can only serve after the node data is consistent. This cannot satisfy the availability of services in the microservice cluster.
Eureka satisfies the AP . When a node in the microservice cluster fails , it will automatically switch to the available service when the client requests the service to ensure that the service can proceed normally. Guaranteed service availability. But the data of each node in a short time
Consistency cannot be guaranteed, there will be a short time lag, and a certain moment will be used to access the faulty service.
Based on the above difference.
Springcloud's support for eureka is greater than that of zookeeper.
To sum up the difference, springcloud chooses eureka as the component when choosing the service registry.