Analysis of zookeeper Java API programming example
In this example, we use Java 3 Version 4.6, examples are convenient for everyone. If you don't understand after learning, you can discuss it in the message area.
Zookeeper Java binding for developing applications is mainly composed of two Java packages:
org. apache. zookeeper
org. apache. zookeeper. data
org. apache. The zookeeper package consists of the interface definition monitored by zookeeper and various callback handlers of zookeeper. It defines the main classes of zookeeper client class library and static definitions of many zookeeper event types and states. org. apache. zookeeper. The data package defines features related to data registers (also known as znode), such as access control lists (ACLS), IDS, stats, etc.
Org.org in zookeeper Java API apache. zookeeper. server，org. apache. zookeeper. server. Quorum and org apache. zookeeper. server. The upgrade package is part of the server implementation. org. apache. zookeeper. The client package is used to query the status of the zookeeper server.
I. prepare the development environment
Apache zookeeper is a complex software, so it needs to run many other class libraries. The dependency library is included in the Lib directory as a jar file in the zookeeper distribution. The name of the core zookeeper jar file is zookeeper-3.4 6. Jar, located in the main directory.
To develop a Java zookeeper application, we must set the classpath to the zookeeper jar and all third-party libraries that zookeeper depends on. There is a zkenv in the bin directory SH file, which can be used to set classpath.
We need to set the script as follows and execute the following statements on the command line:
Shell variable ZK_ Home is set as the path to install zookeeper. In my setting, it is / usr / share / zookeeper. After that, the classpath variable is set correctly. In my system, it is as follows:
In the windows operating system, zkenv.com needs to be run CMD script. You can now use the classpath variable to compile and run Java programs written using the zookeeper API. It can be in the main directory of uni / Linux Zkenv. Is found in the bashrc file SH script to avoid using it every time you start a shell session.
Second, the first zookeeper program
In order to introduce the zookeeper Java API, let's start with a very simple program. It can connect to the zookeeper instance in localhost. If the connection is successful, it will print the list of znodes under the root path of the zookeeper namespace.
The code of this program is as follows:
Before building and executing the previous code snippet, let's see what it does. The code starts with the import statement. Using these statements, we imported the packages required by each component of the program. As mentioned earlier, org apache. The zookeeper package contains all the classes and interfaces required for the client to interact with the zookeeper server. After importing the package, a class named hellozookeeper is defined. Since we want to connect to the zookeeper instance running on the same system, define the host and port string as localhost: 2181 in the main method. The code line ZK = new zookeeper (hostport, null) calls the zookeeper constructor, which attempts to connect to the zookeeper server and returns a reference. For client programs that connect to the zookeeper server instance and maintain the connection, a real-time session needs to be maintained. In this example, the reference returned by the ZK object instantiated by the constructor represents the session. The zookeeper API is built around this reference, and each method call needs a reference to execute.
The construction method of the zookeeper class uses the following code to create a reference to the zookeeper instance:
The parameters used have the following meanings:
Connectstring: comma separated list of host port numbers, each corresponding to a zookeeper server. For example, 10.0 0.1:2001，10.0. 0.2:2002 and 10.0 0.3:2003 indicates the effective host port matching of zookeeper sensor of three nodes. Sessiontimeout: This is the session timeout in milliseconds. This is the time when zookeeper did not get the heartbeat from the client before announcing the end of the session. Watcher: a watcher object. If it is created, it will be notified when the state changes and node events occur. This watcher object needs to be created separately through a user-defined class. It implements the watcher interface and passes the instantiated object to the zookeeper constructor. Client applications can receive notifications of various types of events, such as connection loss, session expiration, and so on.
The zookeeper Java API defines another constructor with three parameters to specify higher-level operations. The code is as follows:
In the above construction method of zookeeper class, if set to true, the Boolean canberereadonly parameter allows the created client to enter the read-only mode in the case of network partition. Read only mode is a scenario where the client cannot find most servers, but has a reachable partition server and connects to it in read-only mode, which allows read requests to the server, while write requests are not. The client continues to try to connect to most servers in the background while still maintaining read-only mode. The partition server is only a subset of the zookeeper group, which is formed due to the network allocation in the cluster. Most servers make up most quorums in ensembles.
The following construction method shows the definition of two additional parameters:
This constructor allows the zookeeper client object to create two additional parameters:
Sessionid: when the client reconnects to the zookeeper server, you can use a specific session ID to refer to the previously connected session sessionpasswd: if the specified session requires a password, you can specify it here
The following constructor is a combination of the first two calls:
This constructor is a combination of the first two calls and allows reconnection to the specified session with read-only mode enabled.
The detailed Java API documentation for the note zookeeper class can be found in http://zookeeper.apache.org/doc/r3.4.6/api/index.html Query on.
Now, back to our zookeeper program. After calling the construction method, if the connection is successful, we will get the reference of zookeeper server. We pass the reference to the getchildren method through the following code:
The getchildren (string path, Boolean watch) method of zookeeper class returns the list of children of znode on the given path. We just iterate over the list returned by this method and print the string to the console.
Name the program Hello zookeeper Java and compile our program as follows:
Before we run the program, we need to use the following command to start the zookeeper server instance:
The operation procedure is as follows:
The executing program will print log messages on the console to display the zookeeper version, java version, Java classpath, server architecture, etc. Some of these log messages are shown here:
The log messages generated by the zookeeper Java API are very useful for debugging. It provides us with background information about the client connecting to the zookeeper server and establishing a session. The last three log messages shown above tell us how the client starts the connection using the parameters specified in the program, and how the server assigns a session ID to the client after a successful connection.
Finally, the program executes and outputs the following in the console:
We can use the zookeeper shell to verify the correctness of the program:
congratulations! We have just successfully written our first zookeeper client program.
II. Implement watcher interface
Zookeeper watcher monitoring enables clients to receive notifications from zookeeper servers and handle these events when they occur. The zookeeper Java API provides a public interface called watcher. The client event handler class must implement this interface to receive event notifications from the zookeeper server. Programmatically, applications that use this client handle these events by registering callback objects with the client.
We will implement the watcher interface to handle the events generated by zookeeper when the data associated with znode changes.
The watcher interface is at org apache. The zookeeper package declares the following:
To demonstrate the znode data monitor (watcher), there are two Java classes: datawatcher and dataupdater. Datawatcher will always run and listen for nodedatachange events from zookeeper server in the znode path specified by / myconfig. Dataupdater class will regularly update the data fields in this znode path, which will generate events, and datawatcher class will print the changed data after receiving these events To the console.
Here is datawatcher Code of Java class:
Let's take a look at datawatcher Java class to understand the implementation of a zookeeper monitor. The datawatcher public class implements the watcher interface and runnable interface, and intends to run the monitor as a thread. The main method creates an instance of the datawatcher class. In the previous code, the datawatcher constructor tried to connect to a zookeeper instance running on the local host. If the connection is successful, we use the following code to check whether the znode path / myconfig exists:
If the znode does not exist in the zookeeper namespace, the exists method call will return null and try to create it as a persistent znode with code, as follows:
Next is the process method, which is located at org apache. Zookeeper is declared in the watcher interface and implemented by the datawatcher class with the following code:
For simplicity, in the process method, print the events received from the zookeeper instance and further process only the events of nodedatachanged type, as shown below:
When an event of nodedatachanged type is received due to any update or change of the data field of znode path / myconfig, the printdata method is called to print the current content of znode. When a GetData call is executed on znode, we set a monitor again, which is the second parameter of the method, as shown in the following code:
Monitoring event is a one-time trigger sent to the client setting monitoring. In order to continuously receive further event notifications, the client should reset the monitor.
DataUpdater. Java is a simple class that connects to the zookeeper instance running the local host and updates the data field of znode path / myconfig with a random string. Here, we choose to update znode with a universal unique identifier (UUID) string, because subsequent UUID generator calls will ensure that a unique string is generated.
DataUpdater. The Java class code is as follows:
The above code causes the zookeeper server to trigger a nodedatachanged event. Since datawatcher has monitoring set up for this znode path, it receives notifications of data change events. It then retrieves the updated data, resets the monitoring, and prints the data on the console.
Compile the datawatcher and dataupdater classes with the following command:
To execute the monitor and update program, you need to open two terminal windows. I want to run the monitor first because it creates the znode of / myconfig (if not already created in the zookeeper namespace). Before running the monitor, make sure that the zookeeper server is running on the local host.
In one of the terminal windows, execute the watcher class by running the following command:
The output is similar to the message shown in the following screenshot:
As shown in the previous screenshot, the znode path / myconfig is created by the datawatcher class. It also prints the contents of the znode, but it does not print in the console because we did not set any data when we created the znode. When the znode is created, the monitor in the class receives an event notification of type nodecheated, which is printed in the console. The datawatcher class continues to run and listens for events on the / myconfig node from the zookeeper server.
Let's run the dataupdater class in another terminal window:
After the initial zookeeper specific log message is recorded to the console, the dataupdater class does not prompt when running. It sets a new UUID string to the data field of zookeeper path / myconfig. Therefore, you can see that the output displayed in the following screenshot is printed in the terminal window running datawatch every 5 seconds:
Datawatcher can also be tested using the zookeeper shell. Continue to run the DataWatcher class in the terminal as before, and invoke ZooKeeper shell in another terminal and run the commands shown in the following screenshots:
In the terminal where datawatcher is running, the following message will be printed:
Example 3 - cluster monitor
Popular services provided through the Internet, such as e-mail, file service platform, online games, etc., are served by hundreds of highly available servers across multiple data centers, which are usually separated geographically. In this cluster, some dedicated server nodes are set up to monitor the activity of the servers hosting services or applications in the production network. In the cloud computing environment, this monitoring node, which is also used to manage the cloud environment, is called a cloud controller. An important task of these controller nodes is to detect the failure of the production server in real time, notify the administrator accordingly, and take necessary measures, such as failover the application on the failed server to another server, so as to ensure fault tolerance and high availability.
In this section, we will use the zookeeper java client API to develop a simple distributed cluster monitor model. Using zookeeper's ephemeral znode concept to build this monitoring model is quite simple and elegant, as described in the following steps:
Each production server runs a zookeeper client as a daemon. This process connects to the zookeeper server, And create a file with a name under the predefined path of the / zookeeper namespace (such as / members) (preferably its network name or host name). The cloud controller node runs the zookeeper monitor process, which monitors the path / members and listens for events of nodechildrenchanged type. The monitor process runs as a service or daemon, sets or resets monitoring on the path, and implements its logic to call appropriate modules to monitor events Take the necessary action. Now, if the production server shuts down due to hardware failure or software crash, the zookeeper client process will be terminated, resulting in the termination of the session between the server and the zookeeper service. Because the attribute of ephemeral znode is unique, the zookeeper service will automatically delete the znode in the path / members whenever the client connection is closed. The deletion of znode in the path raises the nodechildrenchanged event, so the observer process in the cloud controller will be notified. By calling the getchildren method in the path / members, you can determine which server node has been shut down. Then, the controller node can take appropriate measures, such as executing recovery logic to restart the failed service in another server. This logic can be built to work in real time, ensuring near zero downtime and highly available services.
To implement this cluster monitoring model, we will develop two Java classes. The clustermonitor class will continue to run the monitor to monitor the paths / members in the zookeeper tree. After handling the raise event, we will print the znode list in the console and reset the monitoring. Another class, clusterclient, will start the connection to the zookeeper server and create an ephemeral znode under / members.
To simulate a cluster with multiple nodes, we start multiple clients on the same computer and create ephemeral znode with the process ID of the client process. By viewing the process ID, the clustermonitor class can determine which client processes have been closed and which processes are still running. In practice, the client process usually creates an ephemeral znode with the hostname of the currently running server. The source code of these two classes is shown below.
ClusterMonitor. The Java class is defined as follows:
ClusterClient. The Java class is defined as follows:
Compile the two classes with the following command:
To execute the cluster monitoring model, open both terminals. In one of the terminals, run the clustermonitor class. In another terminal, execute multiple instances by running the clusterclient class in the background.
In the first terminal, execute the clustermonitor class:
As shown in the previous example, you can see the debug log message from the client API. Finally, the clustermonitor class starts monitoring events, and enter the following:
Now, execute five instances of the clusterclient class to simulate the five nodes of a cluster. Clusterclient creates ephemeral znode with its own process ID in the / members path of zookeeper tree:
Correspondingly, you will observe that the clustermonitor class detects these new instances of the clusterclient class because it is monitoring events on the / members path of the zookeeper tree. This simulates a node join event in a real cluster. You can see the output in the terminal of the clustermonitor class, which is similar to that shown in the following screenshot:
Now, if you kill a clusterclient Java process, the session it maintains with the zookeeper server will be terminated. Therefore, the ephemeral znode created by the client will be deleted. Deleting will trigger the nodechildrenchanged event, which will be captured by the clustermonitor class. This simulates a scenario in which a node leaves the cluster.
Let's terminate the clusterclient process with ID 4084:
The following screenshot shows the output in the terminal of the clustermonitor class. It lists the currently available processes and their process IDs, which simulate the real-time server:
The example implementation of the simple and elegant cluster monitoring model above shows the real power of zookeeper. Without zookeeper, developing such a model that can monitor node activity in real time will be a real arduous task.