CAP theory: c strong consistency a availability p partition fault tolerance
ZooKeeper follows CP, Eureka is AP.
Zookeeper guarantees CP
When querying the registry for the list of services, we can tolerate that the registry returns the registration information a few minutes ago, but we cannot accept the service directly down and unavailable . In other words, the service registration function has higher requirements for availability than consistency. But zk will have such a situation, when the master node loses contact with other nodes due to a network failure, the remaining nodes will re-elect the leader. The problem is that the leader election time is too long, 30 ~ 120s, and the entire zk cluster is unavailable during the election, which leads to the paralysis of the registration service during the election. In a cloud deployment environment, it is a high probability that the zk cluster will lose the master node due to network problems. Although the service can eventually be restored, the long-term unavailability of registration caused by the long election time is intolerable.
3. Eureka guarantees AP
Eureka understands this, so we prioritize usability during design. Each node of Eureka is equal, and the failure of several nodes will not affect the work of normal nodes, and the remaining nodes can still provide registration and query services. The Eureka client is registering with an Eureka or if it finds that the connection fails, it will automatically switch to another node. As long as one Eureka is still there, the registration service can be guaranteed to be available (guaranteed availability), but the information found may be Not up to date (strong consistency is not guaranteed). In addition, Eureka also has a self-protection mechanism. If more than 85% of the nodes do not have a normal heartbeat within 15 minutes, then Eureka believes that there is a network failure between the client and the registry, and the following will occur at this time Situation:
1. Eureka no longer removes from the registration list the services that should expire because they have not received a heartbeat for a long time
2. Eureka is still able to accept registration and inquiries for new services Request, but will not be synchronized to other nodes (that is, to ensure that the current node is still available)
3. When the network is stable, the new registration information of the current instance will be synchronized to other nodes
Therefore, Eureka can deal with the situation that some nodes lose contact due to network failures, without paralyzing the entire registration service like zookeeper.