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

This article mainly introduces "what is the principle of eureka and zookeeper". In daily operation, I believe many people have doubts about what is the principle of eureka and zookeeper. I have consulted all kinds of materials and sorted out simple and easy operation methods. I hope to help you answer the doubts about "what is the principle of eureka and zookeeper"! Next, please follow the small series to learn together!

CAP theorem

What is CAP theory? CAP theory, proposed by Professor Eric Brewer, is an important concept in distributed systems. The details are as follows:

C (Consistency): Consistency of data. We all know that in distributed systems, there are copies of data. Due to network or machine failures, some copies may be written correctly, while others may be written incorrectly or fail, resulting in inconsistent data. Satisfying data consistency rules means ensuring that all data is synchronized.

A (Availability): Availability. When we need to obtain what data, we can normally obtain the desired data (of course, acceptable network delay is allowed), that is, we must ensure that the requested data can be properly responded to at any time.

P (Partition Tolerance): partition 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 certain node is down or there is a problem.

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

1. Zookeeper CP Principles

For zookeeper, it's CP's. That is to say, zookeeper is to ensure the consistency of data, but there is also a point to note here, zookeeper it is not strongly consistent, what does it mean?

For example, now client A submits a write operation, zookeeper can return after more than half of the node operations are successful, but at this time, client B's read operation request is A's write Cao Cao has not synchronized to the node, then read is not A's latest submitted data.

How to ensure consistency? We can perform a sync operation when reading data, that is, synchronize the data with the leader node first, and then fetch it, so as to ensure strong consistency of the data.

However, zookeeper also has a flaw. Just mentioned the leader node. When the master node loses contact with other nodes due to network failure, the remaining nodes will re-elect the leader node. The problem is that it takes too long to elect a leader, 30 ~ 120s, and the entire zookeeper cluster is unavailable during the election, which leads to a crash in the registration service during the election.

In a cloud deployment environment, it is highly probable that the zookeeper cluster will lose its master node due to network problems. Although the service can be restored eventually, the registration unavailability caused by long election time is intolerable. For example, on the day of Double Eleven, it was disastrous.

2. Eureka's AP Principles

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

Eureka was designed with this in mind, so availability is a priority when designing, which is the AP principle. Each node of Eureka is equal. The suspension of several nodes will not affect the normal work of nodes, and the remaining nodes can still provide registration and query services.

Eureka's client will automatically switch to other nodes if it finds that the connection fails when registering with an Eureka. As long as there is an Eureka, the registration service can be guaranteed to be available (i.e., principle A is guaranteed), but the information found may not be the latest (principle C is not guaranteed).

Because the registration information of application instances is not strongly consistent across all nodes of the cluster, clients need to be able to support Load Balancer and failure retry. In Netflix's ecosystem, ribbon can provide this function.

As a result, Eureka can cope well with the situation where some nodes lose contact due to network failure, without causing the entire registration service to crash like zookeeper.

3. results

As a service registry, the most important thing is to ensure availability and can receive inconsistent data over time. Personally, I think Eureka is a little more suitable as a pure service registry than zookeeper.

At this point, the study of "what is the principle of eureka and zookeeper" is over, hoping to solve everyone's doubts. Theory and practice can better match to help everyone learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

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.