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

It takes about five minutes to read the text.

Everyone says that this year is a cold winter on the Internet, but some time ago, a reader was very happy to chat with me that he had gone to JD.com. I asked him what questions he asked. He said he asked a lot of microservices, one of which is: it is also a registry, which do you think is better, zookeeper or eureka?

I happen to be looking at things related to microservices recently, so just to solve this problem, I briefly summarize the difference between zookeeper and eureka, hoping that readers can get something useful from it.

0. CAP theory

Before summarizing the difference between the two, let's take a look at a CAP theory. What is CAP theory? CAP theory, proposed by Professor Eric Brewer, is an important concept in distributed systems. CAP is as follows:

C (Consistency): data consistency. As we all know, in a distributed system, there are copies of data. Due to network or machine failure and other factors, some copies of the data may be written correctly, while others may be written incorrectly or failed, which leads to data inconsistency. To meet the rules of data consistency is to ensure that all data is synchronized.

A (Availability): availability. When we need to get any data, we can get the data we want normally (of course, allow network delay within an acceptable range), that is, to ensure that the requested data can respond normally at any time.

P (Partition Tolerance): partition fault tolerance. When the network communication fails, the cluster is still available, and the normal operation of the whole system will not be affected because a node is down or there is a problem.

For distributed systems, the emergence of network partitions is inevitable, so partition fault tolerance is necessary, that is to say, the three CAP, P is necessary, is an objective fact, inevitable, and can not be bypassed.

1. Zookeeper's CP principle

For zookeeper, it is CP. In other words, zookeeper ensures data consistency, but it is also important to note here that zookeeper is not strongly consistent. What does that mean? For example, now client A submits a write operation, and zookeeper can return after more than half of the node operations are successful. But at this time, the read operation of client B requests the node to which the A write operation has not been synchronized, so the data newly submitted by An is not read.

So how to ensure strong consistency? We can first perform the sync operation when reading the data, that is, synchronize the data with the leader node before fetching it, so as to ensure the strong consistency of the data.

But zookeeper also has a flaw, just mentioned the leader node, when the master node lost contact with other nodes due to network failure, the remaining nodes will be re-elected leader. The problem is that the election time of the leader is too long, 30 ~ 120s, and the entire zookeeper cluster is not available during the election, which leads to the paralysis of the registration service during the election.

In the cloud deployment environment, it is highly likely that the zookeeper cluster will lose its master node due to network problems. Although the service can eventually be restored, the long-term unavailability of registration caused by a long election time cannot be tolerated. For example, on the day of Singles Day, it was catastrophic.

2. Eureka's AP principle

Failure is inevitable in large-scale network deployment, so we can't avoid this problem. When querying the list of services from the registry, we can tolerate that the registry returns the registration information from a few minutes ago, but we cannot accept that the service is directly down unavailable.

Eureka takes this into account when it is designed, so it gives priority to usability at design time, which is the principle of AP. All the nodes in Eureka are equal, the failure of several nodes will not affect the work of normal nodes, and the remaining nodes can still provide registration and query services. On the other hand, if the client of Eureka finds that the connection fails when registering with an Eureka, it will automatically switch to another node. As long as there is an Eureka, the registration service can be guaranteed (that is, principle An is guaranteed), but the information found may not be up-to-date (principle C is not guaranteed).

Precisely because the registration information of the application instance is not strongly consistent among all the nodes in the cluster, the client needs to be able to support load balancing and failed retry. In the ecology of Netflix, ribbon can provide this function.

Therefore, Eureka can well deal with the situation that some nodes lose contact due to network failure, and it will not paralyze the whole registration service like zookeeper.

3. Yuanfang, what do you think?

As a service registry, the most important thing is to ensure availability and accept data inconsistencies in a short period of time. Personally, I think Eureka as a simple service registry is a little more "professional" than zookeeper.

However, the eureka2.x branch is no longer maintained, but eureka1.x is still officially under maintenance, and the latest RELEASE version is 1.9.9, so it's not like the eureka is cold or something.

Eureka is known as Spring Cloud, but Spring Cloud supports the ability to implement service discovery using eureka, zookeeper, and consul. To switch from eureka to zookeeper, you only need to change the dependency and change a few lines of configuration. It is more important to know more about their principles and differences.

Yuanfang, what do you think?

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.