1 Overview
ZooKeeper is an application designed for distributed high-availability, high-performance open-source coordination and consistent service, which provides a basic service: distributed lock service. As the open source nature ZooKeeper, then our developers on the basis of a distributed lock, explored the use of other methods: Configure maintenance, service group, distributed message queues, distributed notification / coordination.
Design goals
Simple data structure: the number of shared structure, similar to a file system stored in the memory.
You can build a cluster: avoid single points of failure, 3-5 machines can be clustered, more than half the normal work will be able to provide services.
Sequential access: For each read request, zk is assigned a globally unique incremental number, use of this feature can enable advanced coordination services.
High Performance: Memory-based operation, something to serve the non-request for a read operation based business scene.
2. Install
Quguan network can download a stable version, and then install it: www.apache.org/dyn/closer....
After extracting created under the zookeeper's conf directory profile zoo.cfg, which configuration information is available zoo_sample.cfg files in the directory statistics, we configured here:
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/opt/zookeeper-data/
clientPort=2181
复制代码tickTime: ZooKeeper specified basic time unit (in milliseconds);
initLimit: Specifies the start time zookeeper, zookeeper Example followers instance led to instances of synchronized initialization connection time limit, the time limit expires, the connection fails (in tickTime unit of time);
syncLimit: zookeeper specified normal operation, from the time limit master synchronizing data between nodes exceeds the time limit, it will be discarded followers instance;
dataDir: zookeeper storage directory data;
clientPort: a port for connecting client.
After completed configuring the configuration response, to the next bin directory corresponding operation can be performed directly by the script zkServer.sh bin directory:
1. 启动zk服务sh zkServer.sh start 或者./zkServer.sh start.
2. 查看zk服务状态sh zkServer.sh status
3. 停止当前zk服务sh zkServer.sh stop
4. 重启服务sh zkServer.sh restart
复制代码Clients can use ./zkClient.sh -server 127.0.0.1:2181 zookeeper connect to the current server. Some simple client command-line tool is as follows:
1.ls:获取路径下的节点信息，注意此路径为绝对路径，类似于linux的ls命令。如ls /zookeeper;
2.create:创建节点，其中-s为顺序充点，-e临时节点。如create /zookeeper/node1"test_create";
3.get:获取节点信息，注意节点的路径皆为绝对路径，也就是说必要要从/（根路径）开始。如get /;
4.set:设置节点的数据。如set /zookeeper "hello world";
5.delete:删除节点，不能递归删除，如果存在子节点则删除失败。
6.rmr:递归删除
7.quit:退出客户端
8.help:帮助命令
....
复制代码3.Zookeeper memory model
zookeeper mentoring and structure similar to the standard Unix file system, each node is called "data node" or znode, each can store data simultaneously znode can mount a child node, can be called "tree."
1. In the Zookeeper, znode is a similar path with the Unix file system nodes, this node can be to store or retrieve data
2 may be performed CRUD operations on znode through the client can also monitor changes znode the register watcher.
Znode
1.Znode Zookeeper is the smallest unit of data, the data can be stored on each Znode, but also can mount a child node, as the directory structure of a hierarchical relationship between znode like file system, zookeeper all of the data stored in the memory in order to improve server throughput, the purpose of reducing delays.
2.Znode There are three types, the type of Znode determined and can not be changed upon creation.
Temporary (EPHEMERAL): At the end of creating a temporary Znode client session, the server node will be temporarily removed. Temporary node can not have child nodes (even temporary child nodes). Although each temporary Znode will bind to a specific client session, but they are visible to all clients
Persistent (PERSISTENT): Once a node is created, and will always exist on the server, Zookeeper require all non-leaf nodes must be persistent node
Sequential (SEQUENTIAL): If you set the sequence identity when creating Znode, then after the Znode name will append a value that consists of a monotonically increasing counter (maintained by the parent) added
3. The temporary nodes are removed in both cases
When a timeout or actively closed and terminated (not the TCP connection is disconnected) to create Znode client session when a client (not necessarily a temporary Znode creator) initiative to remove the node
4. Each data node storing the data in addition to the content, further stores a number of status information of the data node itself. The state Znode (Stat) Information
| No. | Attributes | Node data structure | description |
| 1 | czxid | long | Zxid node value is created |
| 2 | mzxid | long | Modified node value Zxid |
| 3 | pzxid | long | Most have a transaction ID is modified when a child node |
| 4 | ctime | long | Node time to be created |
| 5 | mtime | long | Node was last modified time |
| 6 | versoin | long | Node version number is modified |
| 7 | cversion | long | The node has a version number of the child node is modified |
| 8 | aversion | long | ACL node is a modified version number |
| 9 | emphemeralOwner | long | If this node is a temporary node, then its value is the node owner of a session ID; otherwise, it is 0 |
| 10 | dataLength | int | Node data length field |
| 11 | numChildren | int | The number of child nodes owned |
For persistent and temporary node node, under the same znode, node name is unique! - the underlying implementation of distributed lock
4.Watch sensing mechanism
Clients can set the watcher on znode, monitor the changes znode. Znode changes (Znode own additions, deletions, modifications, and variations of the sub Znode) can be notified to the client through Watch mechanism.
· Two types of watch
1.dara watch monitor data changes
2.child watch monitor child node change
·trigger event
Created event:
Enabled with a call to exists.
Deleted event:
Enabled with a call to exists, getData, and getChildren.
Changed event:
Enabled with a call to exists and getData.
Child event:
Enabled with a call to getChildren.
复制代码·characteristic
1. one-time triggering. When the client Znode set Watch, if Znode content is changed, then the client will get Watch event. For example: Client Settings getData ( "/ znode1", true) If, after / znode1 changed or deleted, then the client will get a Watch Event / znode1, but / znode1 change again, and that the client is unable to close to Watch event, unless the client sets a new Watch.
2. orderliness. Watch the event is sent asynchronously to the Client. Zookeeper can ensure that the client sends the last update sequence is ordered. For example: a Znode not set watcher, then the client before this Znode Watcher sent to the cluster setup, the client is not aware of any change in the situation of Znode. Another point to explain: Due to Watch characteristic trigger a one-time, so the server does not Watcher in the case, any change Znode will not notice to the client. However, even if a Znode set Watcher, and notice there is a change in the Znode case to the client, but the client receives this event change, but have not set again before Watcher, if other clients do the Znode modification, in this case, znode second change is the client can not receive notification. This may be due to network delays or other factors, so we can not expect to be able to monitor the use of Zookeeper changes to each node. Zookeeper can only ensure that the final agreement, but can not guarantee strong consistency.
Reproduced in: https: //juejin.im/post/5d034ce3e51d454f71439cbc