The difference between Eureka and zookeeper

as a service registry, Eureka is better than zookeeper. The famous cap theory states that a distributed system cannot meet both C (consistency), a (availability), and p (partition fault tolerance).    Because partition fault tolerance p is a must in a distributed system, we can only trade the tradeoff between A and C.          So the zookeeper guarantees that the CP Eureka is the AP. Zookeeper guarantee CP when querying the registry for a list of services, we can tolerate that the registry returns a few minutes of registration information, but cannot accept that the service is not available for direct down. In other words, the service registration feature requires more availability than consistency. But there is a situation in ZK that
When the master node loses contact with other nodes because of a network failure, the remaining nodes re-leader the election. The problem is that the election leader too long, -~120s, and the entire ZK cluster was unavailable during the election period, which led to the paralysis of registration services during the election period. In the cloud deployment environment, because the network problem causes the ZK cluster to lose the master node is the larger probability will occur,
While the service can eventually be restored, the long election time that has resulted in the registration being unavailable is intolerable. Eureka ensures that Apeureka is aware of this, so the availability is prioritized at design time. Eureka each node is equal, several nodes will not affect the normal node work, the remaining nodes can still provide registration and query services. The Eureka client will automatically switch to the other node if it discovers that the connection fails, and if one of the Eureka is still there, it will ensure that the registration service is available (guaranteed availability), except that the information found may not be up-to-date (strong consistency is not guaranteed). In addition, Eureka also has a self-protection mechanism, if over 15 minutes%nodes do not have a normal heartbeat, then eureka that there is a network failure between the client and the registry, the following situations occur:1. Eureka no longer removes the service from the registration list that should expire because it has not received a heartbeat for a long time2. Eureka is still able to accept registration and query requests for new services, but will not be synchronized to other nodes (that is, ensure that the current node is still available)3when the network is stable, the current instance of the new registration information will be synchronized to the other nodes therefore, Eureka can be good to deal with the network failure caused some nodes to lose contact with the situation, and do not like zookeeper as the entire registration service paralysis. Eureka as a simple service registry is more "professional" than zookeeper, because the registration service is more important to the availability, we can accept short-term to achieve a consistent situation. However, the implementation of the 1.X version of Eureka is a servlet-based Java Web application, and its ultimate performance will certainly be compromised. Looking forward to 2 in development. The X version can be isolated from the servlet and become a separate, deployable execution service. 

The difference between Eureka and zookeeper