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

This article mainly explains "how to understand Zookeeper cluster management and election". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let Xiaobian take you to learn how to understand Zookeeper cluster management and election.

1. Cluster machine monitoring

This is usually used in scenarios where there are high requirements for machine status and machine availability in the cluster, and it is able to respond quickly to changes in machines in the cluster. In such scenarios, there is often a monitoring system that detects whether the cluster machine is alive in real time. In the past, it was common for the monitoring system to periodically check each machine by some means (such as ping), or for each machine to periodically report to the monitoring system that "I am alive." This works, but there are two obvious problems:

When there are changes in the machines in the cluster, there are more things involved in modification.

There is a certain delay.

ZooKeeper has two features that allow you to monitor another cluster machine survivability system in real time:

The client registers a Watcher on node x, then if x? If the child node changes, the client will be notified.

Create an EPHEMERAL type node that disappears once the client and server session ends or expires.

For example, the monitoring system registers a Watcher on the/clusterServers node, and every time a machine is dynamically added in the future, a node of type EPHEMERAL is created under/clusterServers: /clusterServers/{hostname}. In this way, the monitoring system can know the increase or decrease of the machine in real time, and the subsequent processing is the business of the monitoring system.

2. Master Election

In a distributed environment, the same business application is distributed on different machines, and some business logic (such as some time-consuming calculations and network I/O processing) often only needs to be executed by one machine in the entire cluster, and the rest of the machines can share this result, which can greatly reduce duplication of labor and improve performance.

ZooKeeper's strong consistency can ensure the global uniqueness of node creation under distributed high concurrency conditions, that is, there are multiple client requests to create/currentMaster nodes at the same time, and only one client request must be created successfully. With this feature, cluster selection can be easily performed in a distributed environment.

In addition, this scenario evolves into a dynamic Master election. Is that what you need? Properties of EPHEMERAL_SEQUENTIAL type nodes are changed.

As mentioned above, out of all client creation requests, only one will succeed. A slight variation here is to allow all requests to be created successfully, but there must be an order of creation, so that all requests eventually create results on ZK. One possibility is: /currentMaster/{sessionId}-1,?/ currentMaster/{sessionId}-2 ,?/ currentMaster/{sessionId}-3 ….. Each time the machine with the smallest serial number is selected as the Master, if this machine dies, because the node he created will be small immediately, then the smallest machine is the Master.

3. search system

In a search system, if each machine in the cluster generates a full index, it is not only time-consuming, but also does not guarantee that the index data is consistent with each other. So let the Master in the cluster do the full index generation and then synchronize to the other machines in the cluster. In addition, the disaster recovery measure of Master election is that master can be manually designated at any time, that is to say, when master information cannot be obtained in zk, master can be obtained from a place through http for example.

In Hbase, ZooKeeper is also used to implement dynamic HMaster elections. In the Hbase implementation, some ROOT table addresses and HMaster addresses will be stored in ZK. HRegionServer will also register itself in Zookeeper as an ephemeral node, so that HMaster can sense the survival status of each HRegionServer at any time. At the same time, once HMaster has a problem, it will elect a new HMaster to run, thus avoiding the single point problem of HMaster.

At this point, I believe everyone has a deeper understanding of "Zookeeper cluster management and election". Let's do it in practice! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

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.