In the Zookeeper client (1)-the native client , we use the native client to operate the Zookeeper node. But in the process of using, we found some drawbacks, such asNative client session connection is asynchronous, So we have to deal with it in the code accordingly, such as using CountDownLatch and Watch mechanisms to determine whether the connection is successful; another point isWatch requires repeated registration, This point we also demonstrated in the code.
Based on the above disadvantages, there are some other clients, such as ZkClient. ZkClient is an open source zk client, which is encapsulated on the basis of the native API and is an easier-to-use Zookeeper client.
First of all, when we use ZkClient, in addition to the dependency of Zookeeper, we also need to introduce ZkClient dependency, as follows:
<dependency>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
<version>0.11</version>
</dependency>
After introducing the relevant dependencies, we can use the following code to connect to Zookeeper. Is it found that it is much simpler than we used the native client before, and we do not need to control it ourselves.
public class ZkClientTest {
public static final String CONNECT_ADDR = "192.168.80.130:2181";
public static void main(String[] args) {
ZkClient zkClient = new ZkClient(CONNECT_ADDR, 5000);
}
}
In addition to the above conveniences, what other benefits does ZkClient have? For example, in the native client, we introduced the creation and deletion of nodes, but we found that when introducing the creation and deletion of nodes, we did not introduce how to create multiple nodes at once, or delete at one time including The node of the child node, and the implementation of the rmr method.
Because this kind of operation is not performed in the native client, does ZkClient support it? Yes, then how to do it, as follows:
In addition to our very simple connection, as well as the above-mentioned methods that can be used to create nodes and delete nodes recursively, ZkClinet also facilitates the use of us in many other methods, such as if we get a Nodes that do not exist must be reported directly as follows:
But the native client also provides methods for us, as follows, we can determine whether the node exists before acquiring the node, as follows:
There is no such trouble in ZkClient, it allows us to get the node directly, we only need to add the allow empty
The remaining ZkClient operation nodes are basically similar to native client users, such as obtaining node data, modifying node data, and obtaining sub-nodes under the node.
One thing we need to pay attention to here is that maybe we will throw an exception when reading the node. For example, here we manually generate a / node2 node on the server, and then we use ZkClient to read, the results are as follows:
This problem is usually caused by serialization. Here we can implement a ZK serialization by ourselves
public class MyZkSerializer implements ZkSerializer {
/**
* 序列化，将对象转化为字节数组
*/
@Override
public byte[] serialize(Object o) throws ZkMarshallingError {
return String.valueOf(o).getBytes(Charsets.UTF_8);
}
/**
* 反序列化，将字节数组转化为UTF-8字符串
*/
@Override
public Object deserialize(byte[] bytes) throws ZkMarshallingError {
return new String(bytes, Charsets.UTF_8);
}
}
Finally, let's take a look at the usage of Watch in ZkClient. The usage of Watch in the native client is very troublesome. It will only be generated once. We must register each time we use it. So how is it used in ZkClient? ZkClient provides us with a more useful Listener, its usage is as follows:
In the above, when we made the node change, it made it sleep for 2 seconds. Here is to allow the Listener enough time to print out the information. If we do not let the thread modify, the program may end directly.
In addition, we also sleep for 2 seconds during the operation writeDatawith the deletenode, otherwise it will be inconsistent with our expectations, you can try it, the results are as follows:
The monitoring node data changes we introduced above, here we can also monitor the node changes, as follows:
Here, when we are operating the node, we also do thread sleep. We also added thread sleep in the middle of adding the node twice. Otherwise, the first modification may not be perceived, and only the final print will be printed out. The last change, that is [n1, n2]
In addition, we registered the node change monitoring on the / node1 node, so the addition and deletion operations of the child nodes under the / node1 node will be sensed, but we will not monitor the child nodes of the child nodes under the / node1 node, and the deletion is also same
From the console, you can find that the / node1 subnode adds a subnode, and the event will not be triggered. Delete the same reason, you can test it yourself.
In addition, we can monitor node data, child node changes, and also monitor the connection status (that is, the native client monitors for connection), etc., which are not introduced one by one.
