Shulou(Shulou.com)06/01 Report--

How to compare ZooKeeper and Eureka, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Brief introduction

Eureka itself is an open source Netflix product that provides service registration and discovery, and provides the corresponding Java encapsulation. In its implementation, the nodes are equal to each other, and the death of some nodes in the registry will not affect the cluster, even if only one node in the cluster survives, it can provide discovery services normally. Even if all the service registration nodes are down, the service invocation information will be cached on the Eureka Clients (client). This ensures that the invocation between our microservices is robust enough.

Zookeeper mainly provides open source distributed configuration services, synchronization services and naming registration for large-scale distributed computing. Once a subproject of the Hadoop project to control the data in the cluster, it has been upgraded to a stand-alone top-level project. It is also used as a Service discovery service solution in many scenarios.

Contrast

There is a famous CAP theorem in distributed system (C-data consistency; A-service availability; P-service fault tolerance to network partition fault, these three characteristics can not be satisfied at the same time in any distributed system, at most two).

Zookeeper

Zookeeper is designed based on CP, that is, access requests to Zookeeper at any time can get consistent data results, and the system is fault-tolerant to network segmentation, but it can not guarantee the availability of each service request. According to the actual situation, when using Zookeeper to obtain the service list, if zookeeper is selecting the master, or if more than half of the machines in the Zookeeper cluster are unavailable, then the data will not be available. Therefore, Zookeeper cannot guarantee the availability of services.

Admittedly, in most distributed environments, especially when it comes to data storage, data consistency should be guaranteed in the first place, which is why zookeeper is designed to be CP. But for service discovery scenarios, the situation is different: for the same service, even if different nodes in the registry hold different service provider information, it will not cause catastrophic consequences. Because for service consumers, being able to consume is the most important thing-it's better to try to consume after getting the service instance information that may be incorrect, rather than not consuming it because you can't get the instance information. (try to fail quickly, then update the configuration and try again.) so, for service discovery, availability is more important than data consistency-- AP trumps CP.

Eureka

Spring Cloud Netflix adheres to the AP principle when designing Eureka. Eureka Server can also run multiple instances to build a cluster to solve the single point problem, but unlike ZooKeeper's process of electing leader, Eureka Server uses Peer to Peer peer-to-peer communication. This is a decentralized architecture, there is no master/slave distinction, each Peer is equivalent. In this architecture, nodes improve availability by registering with each other, and each node needs to add one or more valid serviceUrl to other nodes. Each node can be treated as a copy of other nodes.

If an Eureka Server goes down, the Eureka Client request will be automatically switched to the new Eureka Server node, and when the down server is restored, Eureka will bring it into the server cluster management again. When a node starts to accept client requests, all operations perform replicateToPeer (inter-node replication) operations, replicating the request to all nodes currently known to other Eureka Server.

After a new Eureka Server node starts, it first attempts to get all the instance registry information from neighboring nodes to complete the initialization. Eureka Server acquires all the nodes through the getEurekaServiceUrls () method and updates them periodically through heartbeat renewal. By default, if Eureka Server does not receive the heartbeat of a service instance within a certain period of time, Eureka Server will log out the instance (default is 90 seconds, configured through eureka.instance.lease-expiration-duration-in-seconds). When an Eureka Server node loses too many heartbeats in a short period of time (such as a network partition failure), then the node will enter self-protection mode.

What is the mode of self-protection? By default, if the number of heartbeat renewals received by Eureka Server per minute falls below a threshold (the number of instance (60 / seconds between heartbeats per instance) self-protection factor, and lasts for 15 minutes, self-protection is triggered. In self-protection mode, Eureka Server protects the information in the service registry and no longer logs out any service instances. When the number of heartbeats it receives returns above the threshold, the Eureka Server node automatically exits self-protection mode. As mentioned earlier in its design philosophy, it is better to keep the wrong service registration information than blindly cancel any potentially healthy service instance. This mode can be disabled by eureka.server.enable-self-preservation = false, while eureka.instance.lease-renewal-interval-in-seconds can be used to change the heartbeat interval, and eureka.server.renewal-percent-threshold can be used to modify the self-protection factor (the default is 0.85).

ZooKeeper is based on CP and does not guarantee high availability. If zookeeper is selecting the master, or if more than half of the machines in the Zookeeper cluster are unavailable, you will not be able to get the data. Based on AP, Eureka ensures high availability and can get locally cached data even if all machines are down. As a registry, in fact, the configuration does not change often, only when the distribution plate and the machine fails. CP is not appropriate for configurations that do not change frequently, while AP can sacrifice consistency to ensure availability when it encounters problems, returning old data and caching data.

So in theory, Eureka is more suitable to be a registry. In the real world, most projects may use ZooKeeper because the cluster is not large enough and there is little chance that more than half of the machines used as registries are down. So it's actually not a big problem.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.