Zookeeper main usage Scenarios

　　

Scenario One : There is a set of servers to provide a service to the client, we hope that the client can find a server in the service-side cluster on each request, so that the service side can provide clients with the services required by the client. For this scenario, there must be a list of these servers in our program, and each time the client requests it, it reads the list of servers from this table. Then this table clearly cannot be stored on a single node of the server, otherwise this node hangs, the entire cluster will fail, we hope this list is highly available. The highly available solution is that the list is distributed storage, which is managed by the server that stores the list, and if one of the servers in the table is broken, the other server can immediately replace the broken server, and the broken server can be removed from the table, leaving the failed server out of the cluster , and all of this is not done by the failed server, but the normal server in the cluster. This is an active distributed data structure that can proactively modify the state of data items when external conditions change. This service is provided by the zookeeper framework. The service name is the unified naming service, which resembles the Jndi service in Java EE.

　　Scenario two : Distributed lock service. When the distributed system operates data, for example: reading data, analyzing data, and finally modifying data. In the distributed system, these operations may be dispersed to different nodes in the cluster, then there is the problem of consistency in the data operation process, if not consistent, we will get a wrong result, in a single process program, the consistency of the problem is very good solution, but to the distributed system is more difficult, Because the operation of the different servers in the distributed system is in the independent process, the intermediate result and the process of the operation also pass through the network, so it is more difficult to achieve the consistency of data operation. Zookeeper provides a lock service that solves this problem and allows us to ensure the consistency of data operations when doing distributed data operations.

　　Scenario Three : Configuration management. In the distributed system, we will deploy a service application to n servers, the configuration files are the same (for example: I designed the distributed site framework, the server has 4 servers, 4 servers are the same, the configuration files are the same), If configuration options change, then we have to change each of these configuration files, if we need to change the number of servers less, these operations are not too cumbersome, if we have more distributed servers, such as some large internet companies Hadoop cluster has thousands of servers, Changing configuration options is a cumbersome and dangerous thing to do. This time zookeeper can come in handy, we can use zookeeper as a high-availability configuration memory, to the zookeeper to manage such things, we copy the cluster configuration file to a node of the zookeeper file system, Then use zookeeper to monitor the status of the configuration files in all distributed systems, once the configuration files have been found to change, each server will receive zookeeper notifications, each server to synchronize the zookeeper configuration files, The Zookeeper service also guarantees the atomicity of the synchronization operation, ensuring that each server's configuration file is updated correctly.

　　Scenario Four : provides fault-repair functionality for distributed systems. Cluster management is very difficult, in the distributed system to join the zookeeper service, can make it easy for us to manage the cluster. Cluster management The most troublesome thing is node fault management, zookeeper can let the cluster choose a healthy node as the Master,master node will know the current cluster of each server health, once a node fails, Master will notify the other servers in the cluster to redistribute the compute tasks for the different nodes. Zookeeper not only can find fault, but also the fault of the server screening, see what the fault server is the fault, if the fault can be repaired, zookeeper can automatically repair or tell the system administrator the cause of the error to let the administrator quickly locate the problem, repair the fault of the node. We may have a question, master fault, then how to do? Zookeeper also considered this, zookeeper has an "election leader algorithm", master can be dynamically selected, when master failure, zookeeper can immediately select a new master to manage the cluster.

Zookeeper main usage Scenarios