Which is better Zookeeper or Eureka？

Which is better, Zookeeper or Eureka?

1. CAP Theory

A distributed system cannot satisfy the three requirements of 1 consistency, availability, and partition fault tolerance at the same time

C: Data 1 Consistency: Ensure all data is synchronized

A: Availability: To ensure that the requested data responds properly at any time

P: Partition fault tolerance: When network communication fails, the cluster is still available and will not affect the normal operation of the entire system because a node is hanging or has problems

Network partitioning is unavoidable for distributed systems, so partition fault tolerance is required, that is, for CAP3, P is required

2. Zookeeper guarantees the CP principle

When we query the registry for the list of services, we can tolerate the registration information returned by the registry a few minutes ago, but we can't accept that the service down is not available directly.That is, the service registration function requires more than 1 consistency for availability.However, there is a case with zookeeper where the remaining master nodes will be re-elected for leader when they lose contact with other nodes due to network failure.The problem is that it took too long to elect leader, 30-120 s, and the entire zookeeper cluster was unavailable during the election, which resulted in paralysis of service during the election.In a cloud deployment environment, it is more likely that zookeeper clusters will lose their master nodes due to network problems. Although services can ultimately be restored, the long-term unavailability of registration due to long election times is intolerable.

3. Eureka guarantees AP principle

Eureka guarantees availability first.Each node of Eureka is equal. Hanging a few nodes will not affect the normal work of the node. The remaining nodes can still provide registration and query services.Eureka's client will automatically switch to another node if it registers with an Eureka or discovers a connection failure. As long as one Eureka is still available, the registration service will be available (guaranteed to be highly available), although the information queried may not be up-to-date (strong 1 consistency is not guaranteed).In addition, Eureka has a self-protection mechanism. If more than 85% of the nodes do not have a normal heartbeat within 15 minutes, Eureka assumes that there is a network failure between the client and the registry. The following situations occur:

1.Eureka no longer removes services from the registration list that should expire due to prolonged heartbeat confiscation

2.Eureka will still be able to accept registration and query requests for new services, 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, new registration information for the current instance will be synchronized to other nodes

Therefore, Eureka can cope well with network failures that cause some nodes to lose contact without paralysing the entire registration service as zookeeper does.

summary