here will talk about the skeleton model of zookeeper,so the details of implemention are recommanded to dig into sources.
I startup
1.1 client side
1.2 server side
------
I startup
1.1 client side
as u can see,through the client shell entry,the zkCli.sh states that the class 'ZooKeeperMain' is the real client command side interacted with server,and the class 'ZooKeeper' is an ensucapsuated client tools which is more closed to server .
here is a simple client side handling model
so u will know that there are two components in ZooKeeper instance:
1.SendThread--used to interact wth server,include send packet to and receive result response from server.in general the ClientCnxnSocketNIO is the implemented class of cnxn.so this is a 'flow controller class'
2.EventThread--delivers events from the queue which has been put in element in the reponse of SendThread to user register watcher.
so here are some questions to ask normally:
q1:if i do some heavy tasks in Watcher#process() ,will it affect the server?
no,as this process is stayed in client side,so if u want to issue some CRUD ops about zk or ther io heavy ops ,please go ahead.
q2:if more than one clients registered watchers at the same znode(path) ,which one will will be notified first,certain order?
the notification order is not guaranteed,as the server will send back a notification to all clients whcih have registerd the znode concurrently ,so the order will be caslled as 'randomly'.see 1.2 server side(also,FinalReqeustProcessor#process() & NIOServerCnxn#processWatch())
q3:issue a 'delete' op on zookeeper client,which one will come first,this result response or event triggers registered before?
same as q2,as all reponses will be sent concurrently,so no order is guaranteed.
1.2 server side
from the zkServer.sh we know that the 'QuorumPeerMain' is the entry of server side.
1.2.1 standalone mode
note:the WorkerThread will not exist if the # of workers is undefined or set to 0.and the NIOServerCnxn is resonsible for communicating with clients to read data from or write data to.
client A--a client that issue certain CRUD ops.
clients B--certain clients registered wathchers on that znode,so they will be nodified when client A ops are complete.
and the request processor chains are below(only for standalone mode):
for example,client B commit a 'getData' op on a znode with a watcher,then server will keep in mind this cnxn;then when client A post a 'delete' op on the same znode,the server will know who has registered this znode,so after the znode has been removed in server,than a 'notification' will be sent to client B immediately.
but one thing i want to know is:for a 'read' op,the client will get 2 times(two selected keys) to complete the reading;but only one selected-key for server to do that,why?(preliminarily suggest that this is a nio mechanism,right?) give me a clue if you have any thinkings,please
something to keep in mind:
A.the client will adjust sessionTimeout against the server's bounds
in ZooKeeper(x,x),we will pass a sessionTimeout param,and generate two sessionTimeout values against it:
connectTimeout = sessionTimeout / num-zk-servers-client-want-to-connect readTimeout = sessionTimeout * 2 / 3
but after the first connect to server,the server will fix it by apply bouds:
minSessionTimeout < sessionTimeout-in-cient < maxSessionTimeout
and the maxSessionTimeout bound will be applied after the min.
minSessionTimeout = 2*tick;maxSessionTimeout = 20 * tick
of course the sub values 'connectTimeout' and 'readTimeout' will be recomputed also.
B.there is a sesssion expiry thread called 'SessionTrackerImpl' to expire those
this thread will use a bucket to remove batch expired threads by using fixed sessionTimeout described in A above,so the real expiry time is not absoulte exact,but it's not important.so the param 'sessionTimeout' sent from client is used only by server for checking expiry period,but no anywhere fro client.
if u want to introduce a timeout concept in client,u can check in 高并发下NIO socket消息超时机制的探讨 or use a new nio framework,e.g mina
1.2.2 ensemble mode
zookeeper-3.5--2 ensemble work flow
ref:
相关推荐
apache-zookeeper-3.5.7-bin.tar.gz 。
apache-zookeeper-3.6.0.tar.gz
zookeeper-3.4.9.tar.gz
zookeeper-3.4.14,包含添加系统服务插件及添加bat. 1. zookeeper-3.4.14源包 2. commons-daemon-1.1.0-bin-windows.zip 插件 3. 配置好插件的zookeeper-3.4.14包,右键管理员权限执行zk-server-install.bat
apache-zookeeper-3.5.5.tar.gz,zookeeper的安装文件,解压后配置集群即可
放在压缩包里了, 在windows下解压出"zookeeper-3.4.14.tar.gz"之后上传至虚拟机即可
apache-zookeeper-3.7.0-bin.tar.gz
zookeeper-3.4.10.tar.gz 安装包
apache-zookeeper分布式框架,压缩包内容:(apache-zookeeper-3.7.1-bin.tar.gz、apache-zookeeper-3.7.1.tar.gz、apache-zookeeper-3.6.4-bin.tar.gz、apache-zookeeper-3.6.4.tar.gz、apache-zookeeper-3.5.10-...
zookeeper-3.4.5.jar; zookeeper-3.4.5.jar; zookeeper-3.4.5.jar;
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调...ZooKeeper代码版本中,提供了分布式独享锁、选举、队列的接口,代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本,选举只有Java版本。
zookeeper-3.4.5-cdh5.16.2.tar.gz 资源包,之前的原网站上无法下载,后经多种途径下载到该资源包,上传到博客上供大家使用。
zookeeper-3.4.8.jar
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是以Fast Paxos算法为基础,实现同步服务,配置维护和命名服务等分布式应用。而使用kafka前必须安装zookeeper。...(文件全称:zookeeper-3.4.13.tar.gz)
zookeeper-3.4.6.tar,
最新版linux apache-zookeeper-3.7.0-bin.tar.gz最新版linux apache-zookeeper-3.7.0-bin.tar.gz
zookeeper-3.5.8 版本, ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。
zookeeper-3.4.12--.rar
zookeeper-3.5.7.zip文件 zookeeper-3.5.7.zip文件 zookeeper-3.5.7.zip文件 zookeeper-3.5.7.zip文件 zookeeper-3.5.7.zip文件 zookeeper-3.5.7.zip文件 zookeeper-3.5.7.zip文件 zookeeper-3.5.7.zip文件 ...
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性...window下先解压为apache-zookeeper-3.6.1-bin.tar.gz