zookeeper study notes - basic usage advanced

Data node
Data node Znode:
– means machine
– data node in zk tree structure, used to store data
– once a persistent node (PERSISTENT) is created, it will always be stored on zk unless a delete operation is actively called
– temporary node ( EPHEMERAL): Binding with the client's session, once the client session is invalid, all temporary nodes created with the client will be removed
- PERSISTENT _SEQUENTIAL When creating a child node, if the attribute SEQUENTIAL is not set, it will be automatically followed by the node name Append an integer number, the upper limit is the maximum value of the integer

Create sequential node 1, node data is test1
Create sequential node 2, node data content is test2
View all created sequential child nodes
Create sequential node with prefix




zk-watcher
problem
– cluster There are multiple machines. When a general configuration changes, how to make the configuration of all servers take effect uniformly?
– When a cluster node goes down, how do other nodes know?

Watcher composition
– client
– ​​client watchManager
– zk server
Watcher mechanism
– when the client registers the watcher with the zk server, it will store the watcher object in the
client ’s watchManager
– after the Zk server triggers the watcher event, it
will send a notification to the client, client thread from
Watcher is invoked in watchManager to execute

Watcher interface
– public class ZLock implements Watcher
– public void process(WatchedEvent event)
Watcher event
– ​​notification status: org.apache.zookeeper.Watcher.Event.KeeperState
– event type: org.apache.zookeeper.Watcher .Event.EventType

NodeDataChanged event
– ​​fires regardless of whether the node data changes or the data version changes
– even if the data is updated, the data version will change
NodeChildrenChanged
– add a node or delete a node
AuthFailed
– the point is not that the client session has no permissions Instead, the authorization fails (detailed later)
to register when the zk client object instance is created
– ZooKeeper(String connectString, int sessionTimeout, Watcher watcher)
– ZooKeeper(String connectString, int sessionTimeout, Watcher watcher, boolean canBeReadOnly)
– ZooKeeper(String connectString, int sessionTimeout, Watcher watcher, long sessionId, byte[] sessionPasswd)
– ZooKeeper(String connectString, int sessionTimeout, Watcher watcher, long sessionId, byte[] sessionPasswd, boolean
canBeReadOnly) watchers
registered in this way It will be used as the default watcher during the entire zk session and will always be
saved in the defaultWatcher of the client ZKWatchManager. If there are other configuration settings, this
watcher will be overwritten.
Other registration api
– getChildren(String path, Watcher watcher)
– getChildren (String path, boolean watch)
• Boolean watch indicates whether to use the default watcher in the context, that is, the watcher set when the zk instance is created
– getData(String path, boolean watch, Stat stat)
• Boolean watch indicates whether to use the default watcher in the context , that is, the watcher set when the zk instance is created
– getData(String path, Watcher watcher, AsyncCallback.DataCallback cb, Object ctx)
– exists(String path, boolean watch)
• Boolean watch indicates whether to use the default watcher in the context, that is, the watcher set when the zk instance is created
– exists(String path, Watcher watcher)

client can only receive relevant event notifications, but cannot obtain the original data content of the corresponding data node
and the new data content that has been changed; therefore, if the business needs to know the data before the change or after the change For new data, you
need to save the data before the change and call the interface to get the new data. The deletion and addition

of child nodes will trigger an event. The registration can only be triggered once (very important), and it will be invalid if it is triggered once.

Determine whether the call needs to register a watcher


If registration is required, pass in the object cnxn
ServerCnxn class and cnxn object
– tcp connection between Zk client and server
– implements watcher interface
– summary: both connection information and watcher information are included
watchManager
– the management of watcher on the Zk server side watcher
– maintain watcher from two dimensions
• watchTable: maintain from data node granularity
• watch2Paths maintain from watcher granularity
– Responsible for triggering watcher events

Watcher triggering
– DataTree class
• Maintain the data structure of the node directory

tree Client callback watcher steps
– Deserialization, convert byte stream into WatcherEvent object
– Process chrootPath
– Original watchedEvent: Convert WatcherEvent object to WatchedEvent
– Call back Watcher: hand the WatchedEvent object to the EventThread thread
EventThread
– Take out the Watcher from the client’s ZKWatchManager and put it into the waitingEvents queue to


form Acl
– Scheme:id:permission such as: world:anyone:crdwa
– Scheme: used in the verification process Inspection strategy
– Id: the object to which the permission is granted, such as ip or a user
– Permission: permission, the above crdwa, represents a combination of five permissions
– Set the permission of the node through the setAcl command
– The acl of the node does not have an inheritance relationship
– getAcl can View the Acl information of the node

Scheme type --world
– Scheme:id:permission
– Id:fixed value:anyone, which means any user
– world:anyone:crdwa means that any user has crdwa permission


Scheme type---auth
– Scheme:id:permission, for example: auth:username:password:crdwa
– means to set acl permissions for all users who pass the authentication
– can be added when Multiple users
– add authenticated users through the addauth command.
addauth digest <username>:<password>
– The essence of the Auth policy is digest
– if multiple groups of users and passwords are created through addauth, when using setAcl to modify permissions, all users The permissions and passwords will
be modified
accordingly – the newly created users and password groups through addauth need to call setAcl again before they can be added to the permission group.

Scheme type---auth

Scheme type---digest
– Scheme:id:permission, such as :digest:username:password:crdwa
– specifies that a user and its password can be accessed
– username:password must be SHA-1 and BASE64 encoded
BASE64(SHA1(username:password))
– authenticate the user through the addauth command Additions
• addauth digest <username>:<password>
Scheme type---digest

Scheme type---IP
– Scheme:id:permission, for example: ip:127.0.0.1:crdwa
– Specify a certain ip address to access


Scheme type---super

client passes super level user admin
Authorized to access any node