Why I study zookeeper

Session

A "chroot" suffix is supported after the 3.2.0 version, for example: "127.0.0.1:2181/app/a", which is intended to make all subsequent paths become relative paths based on this.

Zookeeper sessions are identified by using a 64-bit integer. When the connection is created, the session ID is sent to the client together with a password created by the server. If the client is disconnected, the client will give the password and session ID when reconnecting to zookeeper, and all servers can verify their correspondence. In this way, security is achieved.

Two concepts are important: Session time-out and tick time. The tick time is typically set to 2000MS, and the session timeout can be set to twice to 20 times times its duration. Zookeeper's client API will help you manage time-out re-connect, and the library is designed to be "self-adapting to surprise clusters".

Monitor

The zookeeper client can set up the monitor on the Znode. If there is a change in the Znode, the corresponding monitor is triggered, the client receives the message, and the monitor is removed. Three read operations: GetData (), GetChildren (), exists (), which can optionally register monitors on Znode-as a side effect of reading data, reading sub-znode lists, and checking for presence. The monitor has three points:

1) trigger only once.

2) Send to the monitor. Zookeeper guarantees that when the Znode changes, the client will not see this change until the monitor it is set on this znode is triggered and the event has arrived at the client. In this way, different clients may see different patterns of znode at the same time. For example, Client_a set Monitor A on Znode, and then Znode update, but this event is lost in the network, then client_a again request to change Znode, will get the most original return results. If another client_b also requests the state of the Znode, the result will be different. Also, if the same client registers watcher with the same znode multiple times, the zookeeper guarantees that the watcher registered first will be delivered first.

3) The GetData and exists two operations are set by the Datawatch,getchildren setting is Childrenwatch. For example, a znode is created that will trigger its own datawatch, as well as the childrenwatch of its parent node.

Monitors are maintained locally only on the server to which the session is connected, which makes the monitor itself very lightweight. When a client connects to a new server, the monitor is triggered by any session event (PS, does this mean that some of the monitors are set to the session?). ）。 When the client is re-connected, all previously set triggers will be reset and triggered as appropriate. Note that there are only 1 cases where the monitor will be lost: When the client is disconnected, the znode it listens to is created, but it is deleted!

Watch semantics: Created event,deleted event,changed event, and child event.

Watch can be removed by calling Removewathes from the client, and of course, if you cannot connect to any server, the client can also set local flag to true to unilaterally eliminate the connection. Java Bindings

The Java API provides functionality through two packages: Org.apache.zookeeper and its data sub-package. The Zookeeper class below abstracts a zookeeper connection, and a view of the zookeeper cluster to which it is connected. It has two constructors, the difference being that one field requires session ID and password two parameters. This allows the session to resume from disk after the process fails. The Zookeeper class object holds two threads: an IO thread and an event thread. All IO operations are carried out via NIO in the IO thread, and the callback function after the listener is triggered is executed in the event thread. Note that data read and write operations such as synchronous GetData () are also done in the IO thread.

Programming examples

Https://github.com/hicqu/zookeeper-learn

Why I study zookeeper